Omnifaces 2.5.1 and multiple WARs inside EAR - cdi

I have an application that works fine runing Omnifaces 2.5.1 Mojarra under Wildfly 10. This application have a multiple WARs but only one uses Omnifaces.
Today I tried to add Omnifaces to use in a second WAR inside the EAR. And I'm getting this exception:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Long with qualifiers #Param
at injection point [BackedAnnotatedField] #Inject #Param private siscom.web.jsf.controller.PartnerDetailsController.id
at siscom.web.jsf.controller.PartnerDetailsController.id(PartnerDetailsController.java:0)
WELD-001475: The following beans match by type, but none have matching qualifiers:
- Producer Method [Long] with qualifiers [#BatchProperty #Any] declared as [[UnbackedAnnotatedMethod] #Produces #BatchProperty public org.jberet.creation.BatchBeanProducer.getLong(InjectionPoint)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
My controller is:
#ViewScoped #Named
public class PartnerDetailsController implements Serializable {
#Inject
#Param
private Long id;
}
Note: Sometimes work fine, sometimes doesn't. When I restart the application works. If I restart again, not works.

You can't use #Param with multiple WARs containing Omnifaces packaged in an EAR. This is an interaction bug between CDI and OF.
Related blog post: http://balusc.omnifaces.org/2013/10/cdi-behaved-unexpectedly-in-ear-so.html
I have not tested it lately if it works in the latest version.

Related

injectionPoint.getBean() returns null if bean is an EJB bean in Java EE 7 (CDI 1.1)

I want to get bean from producer method in order to read its properties. In some scenarios the bean is a EJB Singleton bean.
I've simplified my code to focus on the problem.
My simple qualifier:
#Qualifier
#Retention(RUNTIME)
#Target({TYPE, METHOD, FIELD, PARAMETER})
public #interface InjectMe {}
Simple producer:
#Dependent
public class SimpleProducer {
#Produces
#InjectMe
public String getInjectMe(InjectionPoint ip) {
// ip.getBean() returns null for some reason
return "ip=" + ip + ", bean=" + ip.getBean();
}
}
EJB (Singleton):
#Singleton
#Startup
public class SimpleSingleton {
#Inject
#InjectMe
private String injectMe;
#PostConstruct
public void init() {
System.out.println(injectMe);
}
}
Console output:
Info: ip=[BackedAnnotatedField] #Inject #InjectMe private com.test.ejb.SimpleSingleton.injectMe, bean=null
When I change Singleton bean to CDI bean everything works fine (ip.getBean() returns not null). It also worked in Java EE 6 even with Singleton bean but it does not in Java EE 7. I am using Glassfish 4 application server.
Is this behavior specified somewhere?
Using
injectionPoint.getMember().getDeclaringClass()
works for me in WildFly 10.1.0 and I also quickly tested it in Payara Server 4.1.1.162 #badassfish (build 116). I also did a test on brand new Payara Server 4.1.1.164 #badassfish (build 28). However,I had to change the scope of the producer bean to #ApplicationScoped. Default scope did not work. In my case, it even makes sense :)
The
injectionPoint.getBean().getBeanClass()
method worked for me in the old Payara, but not in the new WildFly 10.1.0.Final and new Payara Server 4.1.1.164 #badassfish (build 28).
If you have a look at Payara, the current new version 164 contains Weld 2.4.0.Final and WildFly 10.1.0Final uses version 2.3.5.Final. In both versions, the classical code does not work !
The conclusion is, on older CDI implementations (Weld), it works. In some newer Weld (introduced in Payara 161), the behavior changed. I do not know if this is intentional or not.
However, the solution is to use
injectionPoint.getMember().getDeclaringClass()
and annotate the producer bean with
#javax.enterprise.context.ApplicationScoped
annotation.

JSF Mojarra 2.2 on Websphere 8.x

We have been running a JSF 1.2 application on Websphere 7 and 8 for years. We build our war with JSF bundled in it, and always set the classloader as PARENT LAST.
Having now upgraded to JSF 2.2 (and RF4 and PF4 - until migration is complete ), we are now facing issues deploying on the same server (WAS 8.0 as well as WAS 8.5).
We've now done a similar approach (with bundling JSF and PARENT LAST classloading). The application does start, it mentions initialization of Mojarra 2.2.11 , but on first page request, we get below error:
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy34.markResourceRendered(Unknown Source)
at org.richfaces.resource.ResourceFactoryImpl.createMappedResource(ResourceFactoryImpl.java:366)
at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:343)
at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:266)
at javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:137)
at org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.createResource(CAPTCHAResourceHandlerWrapper.java:83)
at org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:109)
at org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:61)
at com.sun.faces.renderkit.html_basic.ScriptRenderer.encodeEnd(ScriptRenderer.java:104)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:919)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1863)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.richfaces.application.ServiceTracker$1.invoke(ServiceTracker.java:153)
... 52 more
Caused by: java.lang.ExceptionInInitializerError
at org.richfaces.resource.external.ResourceTrackerForMyFaces.<init>(ResourceTrackerForMyFaces.java:58)
at org.richfaces.resource.external.ResourceTrackerImpl.getImplementation(ResourceTrackerImpl.java:86)
at org.richfaces.resource.external.ResourceTrackerImpl.markResourceRendered(ResourceTrackerImpl.java:67)
... 57 more
Caused by: java.lang.NoSuchMethodException: org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtils.isRenderedStylesheet(javax.faces.context.FacesContext, java.lang.String, java.lang.String)
at java.lang.Class.throwNoSuchMethodException(Class.java:356)
at java.lang.Class.getMethod(Class.java:1018)
at org.richfaces.resource.external.ResourceTrackerForMyFaces.<init>(ResourceTrackerForMyFaces.java:49)
... 59 more
I have obviously seen many suggestions of using a shared library, but I have similarly found that CDI is not supported when not using the default JSF implementation provided by websphere.
The preferred solution would obviously be to have a single deployment war, but I'm wondering if that's possible in websphere?
Also note that this application runs fine on weblogic and tomcat7
I've tracked this down to a bug in Richfaces, present in the most recent version 4.5.9, in class org.richfaces.resource.external.ResourceTrackerImpl.
That class determines which ResourceTracker to use (there are different classes for either Mojarra and Myfaces), but simply checks if some class from MyFaces is on the classpath. That is the case, but JSF has initialized as Mojarra.
Here's the new method, in which I prevent a class lookup of MyFaces if the used JSF implementation is Mojarra.
private ResourceTracker getImplementation() {
ResourceTracker tracker = externalResourceTracker.get();
if (tracker == null) {
Class<?> myfacesResUtilClass = null;
if (!MOJARRA_IMPLTITLE.equals(FacesContext.class.getPackage().getImplementationTitle())) {
for (String myFacesResourceUtilsClass : MYFACES_RESOURCE_UTILS_CLASSES) {
try {
myfacesResUtilClass = this.getClass().getClassLoader().loadClass(myFacesResourceUtilsClass);
break;
} catch (Exception e) {
LOG.debug("could not load myfaces resource utils class: " + myFacesResourceUtilsClass, e);
}
}
}
if (myfacesResUtilClass != null) {
externalResourceTracker.compareAndSet(null, new ResourceTrackerForMyFaces(myfacesResUtilClass));
} else {
externalResourceTracker.compareAndSet(null, new ResourceTrackerForMojarra());
}
tracker = externalResourceTracker.get();
}
return tracker;
}
It's solved, but it disturbs me quite a lot that, apart from the bug, this class even checks on a websphere specific class, showing how MyFaces has actually been adapted to work on Websphere, instead of the other way around.

CDI :: Deployment error with #Inject & Qualifier across multiple maven projects

I have peculiar issue with CDI. Application deployed on glassFish 3.0.1
The scenario is as below
Maven proj1 :: My jax-rs code has EJB(through interface) injection along with Qualifier
class A_jaxrs{
#Inject #Demo
DemoManager demoManager;
}
Maven proj2 :: All the interface are defined in project2 along with the qualifier
class interface DemoManager{
}
#Qualifier
public #interface Demo{
}
Maven proj3 :: Stateless bean is defined
#Demo
#Stateless
class DemoManagerBean implements DemoManager{
#Override
public void demoString() {
System.out.println("Year 2014");
}
}
Empty beans.xml is included in all the projects
All the projects(as jars) are packaged within the ear
But my ear deployment fails with injection failure.....
Netbeans also reports Unsatisfied dependency error at injection point
Any help ? However the same scenario works with #Ejb("...")
At first, why do you use so old version of Glassfish? It has a lot of bugs. Couldn't you use more recent one? Like 4.0?
Secondly your qualifier annotation is wrong, it should be:
#Qualifier
#Retention(RetentionPolicy.RUNTIME)
#Target({ ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER })
public #interface Demo{
}

Weld 1.1 + Solder causing unsatisfied dependencies?

I was experiencing weird occurences of "WELD-001408 Unsatisfied dependencies".
By all rules and docs, the dependency should be resolved. It was normal #Produces method and #Inject in some other bean.
#Produces #ApplicationScoped public Properties getEntityManagerFactoryProperties(){
...
}
#Inject
private Properties emfProperties;
Now I tried to upgrade from Weld 1.1.13 to 2.0.1, and started getting "WELD-001332 BeanManager method getBeans() is not available during application initialization", which is described in SOLDER-339.
Is it possible that solder is the culprit of the weird unsatisfied dependencies?
Probably. We haven't been doing anything with Solder for over a year. Is there something you need from it which isn't in DeltaSpike?
EDIT: Yes, Solder does not work with Weld 2.0, there hasn't been any serious work on it for over a year. Efforts from the Seam team are being put into DeltaSpike. The vast majority of what you were using in Solder is now in DeltaSpike Core.

Accessing an EJB3 bean in a jar from an independently deployed war (not packaged in ear)

For some reasons, I would like to deploy my application as two separate artifacts: Users-ejb.jar and Users-war.war, not packaged in the same ear (but still, deployed in the same JBoss AS 7.1 instance). In the Users-war.war I have a backing bean (annotated as a JSF managed bean) where I wish to inject an EJB3 packaged in the Users-ejb.jar. The simple #EJB injection that worked when everything was packaged in a single ear no longer works when the Users-ejb.jar and the Users-war.war are deployed seperately.
A narrowed-down simplified example of my setup follows:
EJB3 bean
import javax.ejb.*;
(...)
#Stateless(name="userFacade")
#Local(IUserFacadeLocal.class)
#Remote(IUserFacadeRemote.class)
public class UserFacade extends AbstractFacade<User> implements IUserFacadeLocal, IUserFacadeRemote {
Backing bean
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.ejb.EJB;
import entities.User;
import facades.IUserFacadeRemote;
import facades.IUserFacadeLocal;
#ManagedBean(name="indexBackingBean")
#SessionScoped
public class IndexBackingBean implements Serializable {
#EJB(beanName="userFacade")
private IUserFacadeLocal userFacade;
I've tried various combinations like declaring the type of the EJB3 bean in the backing bean as IUserFacadeRemote (as opposed to IUserFacadeLocal) but they all fail with the same exception when the Users-war.war module is deployed:
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException:
JBAS014543: No EJB found with interface of type 'facades.IUserFacadeLocal' and
name 'userFacade' for binding controllers.IndexBackingBean/userFacade
The Users-ejb.jar is deployed to JBoss AS 7.1 without any complains but when the Users-war.war is deployed, JBoss complains that it can't find the bean he's supposed to inject.
However, I am able to obtain a reference to the EJB3 bean using JNDI using:
String jndiName = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote";
this.userFacade = (IUserFacadeRemote) new InitialContext().lookup(jndiName);
Despite that, the #EJB injection doesn't seem to work.
UPDATE:
I followed the suggestion give below by Tom Anderson and the injection that does work is the:
#EJB(mappedName = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote")
which if I understand correctly uses the vendor-specific mappedName attribute. I couldn't get the injection to work in a vendor-independent way.
I wish i understood this area of the EE spec well enough to give you a definitive answer, but i don't.
The JBoss EJB documentation has this to say:
The #EJB annotation also has a mappedName() attribute. The specification leaves this a vendor specific metadata, but JBoss recognizes mappedName() as the global JNDI name of the EJB you are referencing. If you have specified a mappedName(), then all other attributes are ignored and this global JNDI name is used for binding.
If you specify #EJB with no attributes defined [...] Then the following rules apply:
The EJB jar of the referencing bean is searched for an EJB with the interface, used in for #EJB injection. If there are more than one EJB that publishes same business interface, then an exception is thrown. If there is only one bean with that interface then that one is used.
Search the EAR for EJBs that publish that interface. If there are duplicates, then an exception is thrown. Otherwise the matching bean is returned.
Search globally in JBoss for an EJB of that interface. Again, if duplicates, an exception is thrown.
#EJB.beanName() corresponds to . If the beanName() is defined, then use the same algorithm as #EJB with no attributes defined except use the beanName() as a key in the search. An exception to this rule is if you use the ejb-link '#' syntax. The '#' syntax allows you to put a relative path to a jar in the EAR where the EJB you are referencing lives. See spec for more details
The "Search globally in JBoss for an EJB of that interface" certainly suggests that an injection like the one you wrote should work. Indeed, that it should work without the beanName. However, my suspicion is that from the point of view of a component in the WAR, a component in the EJB-JAR is remote, and therefore you will need to use the remote interface.
So, the first thing i'd try is:
#EJB
private IUserFacadeRemote userFacade;
Without a beanName, in case that's making trouble. It sounds like you've tried that, though.
If the normal approach to injection doesn't work, i might fall back to trying an injection via a mappedName, which in JBoss is a global JNDI name. So:
#EJB(mappedName = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote")
private IUserFacadeRemote userFacade;
This is obviously rather ugly.
Anyway, good luck!
EDIT: Something else you could try is to use a qualified relative beanName which explicitly names the EJB-JAR:
#EJB(beanName = "Users-ejb.jar#userFacade")
private IUserFacadeRemote userFacade;
Because the WAR and EJB-JAR are not packaged in an EAR, this might need to be:
#EJB(beanName = "../Users-ejb.jar#userFacade")
private IUserFacadeRemote userFacade;
But by this point i'm just guessing.
EDIT STRIKES BACK: We may have overlooked something very simple. The lookup attribute of the #EJB annotation lets you specify "A portable lookup string containing the JNDI name for the target EJB component", hence:
#EJB(lookup = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote")
private IUserFacadeRemote userFacade;
Might work. This is essentially a portable version of the JBoss-specific use of mappedName.
I have been testing this scenario in Wildfly and found that it will work with local interfaces as described above if there is a jboss-deployment-structure.xml inside of the war pointing to the ejb. Otherwise a ClassNotFoundException is thrown as the war above can't really "know" about the ejbs classes due to the modular class loading in JBoss and Wildfly. The content of the file should be:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="deployment.Users-ejb.jar" />
</dependencies>
</deployment>
</jboss-deployment-structure>
And then the JSF bean can use:
#EJB(lookup = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote")
private IUserFacadeLocal userFacade;
As #TomAnderson said, the standard way to achieve cross-artifact lookup is the lookup attribute of the #EJB annotation.
Here's a complete Maven project to illustrate how this works:
https://github.com/mrts/remote-ejb-injection
You don't need to use the name attribute of the EJB class, providing the class name in lookup is sufficient. Quoting from the example above:
// in API JAR
#Remote
public interface HelloService { ... }
// in EJB JAR
#Stateless
public class HelloServiceImpl implements HelloService { ... }
// in WAR
#WebServlet("/hello")
public class HelloServlet extends HttpServlet {
#EJB(lookup = "java:global/service-ear/service-ejb-impl/HelloServiceImpl!" +
"ee.mrts.service.HelloService")
private HelloService helloService;
...
}
(So, using HelloServiceImpl directly in lookup Just Works™.)

Resources