I'm starting a new JSF (2) project. I realize that pure JSF has some limitation and I'm planning to drop in spring. JSF is a relatively new approach in spring (there is not even a tag spring-faces in stackoverflow :-) ), jsp being the classic way. I need the best available adjustment of the technology stack.
1) do i need to use spring web flow too?
2) is it viable to use just spring faces (that seems to come as a part of web flow) + spring mvc+ JPA?
3) is there any good example of such a configuration?
I'm using JSF 2 together with Spring 3 for Dependency Injection etc.
I'm not familiar with Web Flow and I don't use it.
In your faces-config.xml you can register the Spring SpringBeanFacesELResolver.
<el-resolver>
org.springframework.web.jsf.el.SpringBeanFacesELResolver
</el-resolver>
Then you can access Spring managed beans in your JSF code!
Have a look at the Spring documentation and the API docs.
If you do not have heavy wizard-specific views in your application, I doubt you'll actually need to use SWF.
The easiest solution is actually the one Sebi told you - register the Spring EL Resolver and mark your controller classes with appropriate stereotype (most usually, #Controller) and desired scope. From there on you should be able to get references to Spring-managed beans via manual- or autowiring. And that's all there is to it - no faces-config.xml bean managment and no "double IoC" overhead. Once it's in Spring context, the managed controller is dereferenced easily from facelet via #{} EL-notation.
For example:
TestController.java:
#Controller("myController")
#Scope("request")
public class TestController {
#Autowired
private SomeSpringManagedBean someBean;
private String someViewProperty;
public String getSomeViewProperty() {
return someViewProperty;
}
public void setSomeViewProperty(String arg) {
this.someViewProperty = arg;
}
......
}
TestView.jspx:
<p:inputText value="#{myController.someViewProperty}" />
We've lost about 2 weeks trying to tie in SWF together with JSF 1.2 - only to discover that once we actually got it working with the latest version of the IceFaces that support JSF 1.2, the IceFaces had a feature/bug so nasty that it simply wouldn't render the view and had gotten stuck in Phase 5 without throwing any exception or reporting anything useful (the issue became fixed in a 1.8.2-GA version of IceFaces that isn't obtainable without purchasing the license).
EDIT: I noticed basically a similar SO-thread here.
Related
Ok, so here's something I've been googling for for hours with no success... Finally i can only hope some Spring-magician reads and answers this question. :)
I'm upgrading an old web application (Spring 2.x-based) to Spring 4.2.x and while adding new features I've decided to completely move away from XML-based config. (Again: i don't want to have any Spring XML files in the project!)
I've converted pretty much everything, but the last thing i can't resolve is finding the correct Java-config counterpart of:
<ws:service id="MySoapService" bean="#ServiceImpl" />
<wss:binding service="#MySoapService" url="/1.0/soap" />
ws/wss namespaces come from:
xmlns:ws="http://jax-ws.dev.java.net/spring/core"
xmlns:wss="http://jax-ws.dev.java.net/spring/servlet"
So what i'm trying to do is exporting #WebService annotated classes, but with Java-config instead of XML.
Additional infos:
I've tried using SimpleJaxWsServiceExporter, but that one leaves me with a "java.net.BindException: Address already in use: bind", regardless of what port i'm using...
The application has two servlets: one is a normal Spring MVC Dispatcher for the new REST API and another com.sun.xml.ws.transport.http.servlet.WSSpringServlet which should make the above mentioned JAX-WS service available.
I'm trying to resolve things with pure JAX-WS RI, no CXF or any other library. The application is huge enough already... :(
You can achieve this by injecting your endpoint and the following helper method (note that my approach uses a base class BaseEndpoint for each endpoint):
#Configuration
public WebserviceConfiguration {
#Inject
private FooEndpoint fooEndpoint;
#Bean
public SpringBinding fooEndpoint() throws Exception {
return bind(fooEndpoint, "ws/bar");
}
private SpringBinding bind(BaseEndpoint endpoint, String url) throws Exception {
SpringService springService = new SpringService();
springService.setBean(endpoint);
SpringBinding binding = new SpringBinding();
binding.setService(springService.getObject());
binding.setUrl(url);
return binding;
}
}
Apparently there's no solution (yet?) - after quite a few more hours of googling around, i've found only this ticket:
https://java.net/jira/browse/JAX_WS_COMMONS-134
Looking at its date and status (and by noting the fact that devs didn't even respond to it, even a year has passed), i assume it's safe to state that JAX-WS Commons spring integration will not support Java config in the foreseeable future.
Env:
Wildfly 8.2.0 Final
JDK 8
Java EE 7
Please note that by 'POJO' i am referring to the classes that serve the other classes i.e other than value objects, entities.
This question was on back of my head for some time. Just wanted to put it out.
Based on CDI and Managed Beans specs and various other books/articles, its pretty clear that CDI injection starts with a 'managed' bean instance. By 'managed' i mean servlet, EJBs etc. which are managed by a container. From there, it injects POJOs (kind of crawl through layers) till every bean gets its dependencies. This all makes very sense to me and i see very little reason why developers ever need to use "new" to create an instance of their dependent POJO's.
One scenario that comes to my mind is when developer would like to have logic similar to
if(something) {
use-heavy-weight-A-instance
} else {
use-heavy-weight-B-instance
}
But, that also can be achieved via #Produces.
Here is one scenario that i verified to be true in wildfly 8.2.0 Final i.e. CDI is not able to inject bean when the JSP has
<%!
#Inject
BeanIntf bean;
%>
But, the alternative to use a servlet works fine.
That said, would like to know if there is any scenario(s) where a developer has to use 'new'. As i understand, by using 'new', developer owns the responsibility of fulfilling dependencies into that bean and all its dependent beans, and their dependent beans etc..
Thanks in advance,
Rakesh
When using CDI or other container you don't use new, because you expect a bunch of service coming from the container.
For CDI these main services are:
Injection of dependent beans (get existing instance or create a new
instance)
Lifecycle callback management (#PostConstruct and
#PreDestroy)
Lifecycle management of your instance (a #RequestScoped bean will make container produce an instance leaving until the end of request)
Applying interceptors and decorators on your instance
Registering and managing observers methods
Registering and managing producers methods
Now, on some rare occasion, you may want to add a part of these services to a class you instantiate yourself (or that another framework like JPA instantiate for you).
BeanManager bm = CDI.current().getBeanManager();
AnnotatedType<MyClass> type = bm.createAnnotatedType(MyClass.class);
InjectionTarget<MyClass> it = bm.getInjectionTargetFactory(type).createInjectionTarget(null);
CreationalContext<MyClass> ctx = bm.createCreationalContext(null);
MyClass pojo = new MyClass();
injectionTarget.inject(instance, ctx); // will try to satisfied injection points
injectionTarget.postConstruct(instance); // will call #PostConstruct
With this code you can instantiate your own MyClass containing injection points (#Inject) and lifecycle callbacks (#PostConstruct) and having these two services honored by the container.
This feature is used by 3rd party frameworks needing a basic integration with CDI.
The Unmanaged class handle this for you, but still prevent you to do the instantiation ;).
We're building a framework on top of Spring & Spring MVC. Our framework is quite mature at this point - about 2 years old and is used widely within our organization. Our framework is very modular (much like spring itself is). There are various modules that can be used independently or together. When used together they provide many benefits to the end user. We have built a handful custom spring XML namespaces (NamespaceHandlers, BeanDefinitionParsers, etc). Each module provides their own which brings in its own set of XML configuration elements. This is all working great for us and has been a really big win for us.
What we'd like to do now is move away from XML-based configuration and into java config. My idea/thought is for each module to introduce a set of java config annotations that can be used (something similar to the #EnableCaching, #EnableMBeanExport annotations). My question is this - even if I create my annotations - how do I "wire" them in so that if they are present I can do "stuff"? This would be similar conceptually to the NamespaceHandlers & BeanDefinitionParsers. I can't find any documentation anywhere as to how to get started.
I've thought about creating some custom abstract base classes which do what I need them to do - but the problem is when it comes to the end user's application - they can only extend a single class. I need a flexible way for each module in my framework to expose its own custom configuration that end user applications can use, just like they use our XML namespace elements.
Here's a glimpse as to what we do in XML (not full application context file - just a blurb from it pertaining to our custom XML namespaces):
<atom-web:web/>
<atom-web:logging/>
<atom-web:security entitlementsProvider="XML" xmlRefreshInterval="${cache.refresh.interval.ms}"/>
<atom-profile:profile caching="IN_MEMORY" entryExpiryDelay="${cache.refresh.interval.ms}"/>
<atom-prefs:preferences backingStoreUrl="${pref.backingStore.url}"/>
<atom-content:content contentServerBaseUrl="${content.server.url}" contentServerFileUrl="${content.server.file.url}" site="${site.name}" contentTaskExecutor="contentTaskExecutor" snippetCaching="IN_MEMORY" cacheRefreshInterval="${cache.refresh.interval.ms}"/>
<bean id="contentTaskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor" p:corePoolSize="3" p:maxPoolSize="20"/>
What I'm envisioning is some kind of set of annotations - something like this:
#EnableAtomWebApplication
#EnableAtomWebLogging
#EnableAtomWebSecurity(entitlementsProvider=EntitlementsProvider.XML, xmlRefreshDelay=120000)
#EnableAtomProfile(caching=CachingType.IN_MEMORY, expiryDelay=120000)
// Other annotations for rest of modules
#Configuration
public class ConfigurationClass {
// Rest of configuration in here
}
Any help here would be greatly appreciated. I'm not quite sure where to start and can't really find any documentation anywhere to help me get started.
So after thinking about this a bit I think I've found the correct starting point. I wanted to throw this out there for anyone who might be able to say "yeah thats the right place" or "no you aren't looking in the correct place".
Using my example above
#EnableAtomProfile(caching=CachingType.IN_MEMORY, expiryDelay=120000)
I would create an annotation for the #EnableAtomProfile annotation like this:
#Retention(value=java.lang.annotation.RetentionPolicy.RUNTIME)
#Target(value={java.lang.annotation.ElementType.TYPE})
#Documented
#Import({AtomProfileBeanDefinitionRegistrar.class})
public #interface EnableAtomProfile {
CachingType caching() default CachingType.NONE;
long expiryDelay default 0;
}
The AtomProfileBeanDefinitionRegistrar class would implement org.springframework.context.annotation.ImportBeanDefinitionRegistrar and do any of the necessary stuff that I'm currently doing in my BeanDefinitionParser
You can have a BeanPostProcessor defined, which would basically:
inspect every single bean created
with reflection check if the object's class is annotated with #YourAnnotation
and if it is, then apply some custom logic - e.g. package the object into some other class or something
Reference:
Spring docs on BeanPostProcessors
source code for RequiredAnnotationBeanPostProcessor, which is a BeanPostProcessor which analyzes annotations
Right now I'm exposing the service layer of my application using spring remoting's RMI/SOAP/JMS/Hessian/Burlap/HttpInvoker exporters. What I'd like is to allow the user to somehow define which of these remoting mechanisms they'd like enabled (rather than enabling all of them), then only create those exporter beans.
I was hoping that spring's application context xml's had support for putting in conditional blocks around portions of the xml. However, from what I've seen so far there's nothing in the standard spring distribution that allows you to do something like this.
Are there any other ways to achieve what I'm trying to do?
I am going to assume that you are looking to configure your application based on your environment, as in... for production I want to use this beans, in dev these other ...
As Ralph is saying, since Spring 3.1 you have profiles... But the key, is that you understand that you should put your environment based beans in different configuration files... so you could have something like dev-beans.xml, prod-beans.xml... Then in your main spring file, then you just invoke the appropriate one based on the environment that you are using... So profiles are only technique to do so... But you can also use other techniques, like have a system environmental variable, or pass a parameter in your build to decide which beans you want to use
You could realize this by using a Spring #Configuration bean, so you can construct your beans in java code. (see http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/beans.html#beans-java)
#Configuration
public class AppConfig {
#Bean
public MyService myService() {
if ( userSettingIshessian ) {
return new HessianExporter();
}else {
return new BurlapExporter();
}
}
}
Of course you need to get the user setting from somewhere, a system parameter would be easy, or config file, or something else.
Spring 3.1 has the concept of Profiles. My you can use them.
I'd like to test my gwt client using the gwt-test-utils library (http://code.google.com/p/gwt-test-utils/). While the standard implementation already delivers a GwtCreateHandler (used to mimic GWT.create on RemoteService) that handles / mappings, it does nothing to handle the Guice servlet extension (GuiceFilter / GuiceServletContextListener).
Basically I need to find the servlet, or the servlet class that handles a specific url, that I know:
String url = ... // I know this.
// I know everything else (Injector, GuiceServletContextListener, etc).
Class<?> servletClazz = ... // How to get this?
Is this even possible?
Of course, running a GWTTestCase would work, but:
it is too slow
gwt-test-utils is pure java, so I don't see why it would not be possible
Thanks,
Alex D.
Checkout Tadedon:
Bind application configuration in Guice module.
Support #PostConstruct and #PreDestroy annotations (JSR 250) in
Guice application. incject slf4j loggers.
annotate your methods with #Transactional annotation.
Support guice stage in your web application.
test your guice managed servlets and filters without need of real
servlet container.
use guice Matchers for matching super class, interface and type
literal annotations