Websphere code on Wildfly

Question

I am trying to incorporate a library into my JSF2 application running on Wildfly. The library was developed in house by a team that uses websphere. They don't support wildfly, only websphere. I would really like to use their library as it allows me to access data natively through my java app.

When I add the required libraries to my POM and I deploy the app, I get these errors

07:41:28,672 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 1) WELD-001125: Illegal bean type javax.ws.rs.ext.MessageBodyWriter<javax.ws.rs.core.MultivaluedMap<java.lang.String, ?>> ignored on [EnhancedAnnotatedTypeImpl] public @ApplicationScoped @Consumes @Provider @Produces class org.apache.wink.common.internal.providers.entity.FormMultivaluedMapProvider
07:41:28,672 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) WELD-001125: Illegal bean type javax.ws.rs.ext.MessageBodyReader<javax.xml.bind.JAXBElement<?>> ignored on [EnhancedAnnotatedTypeImpl] public @ApplicationScoped @Consumes @Provider @Produces class org.apache.wink.common.internal.providers.entity.xml.JAXBElementXmlProvider
07:41:28,672 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) WELD-001125: Illegal bean type javax.ws.rs.ext.MessageBodyWriter<javax.xml.bind.JAXBElement<?>> ignored on [EnhancedAnnotatedTypeImpl] public @ApplicationScoped @Consumes @Provider @Produces class org.apache.wink.common.internal.providers.entity.xml.JAXBElementXmlProvider
07:41:29,000 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ond4.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."ond4.war".WeldStartService: Failed to start service
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071: Managed bean with a parameterized bean class must be @Dependent: class org.apache.wink.common.internal.providers.entity.csv.CsvDeserializerProvider
    at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:208)
    at org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:107)
    at org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:122)
    at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
    at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
    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)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)

I have no idea what this means or whether I have any hope of being able to fix it. Can anyone point me in the right direction? or just tell me to forget about being able to make this work?

score 1 · Answer 1 · answered Jul 03 '17 at 07:09

Looking at the exception,

Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071: Managed bean with a parameterized bean class must be @Dependent: class org.apache.wink.common.internal.providers.entity.csv.CsvDeserializerProvider

there is somewhere a parameterized bean (e.g. Foo<Bar>) which has scope other than @Dependent. This is against specification requirement.

Quote from chapter 3.1 in CDI specification:

If the managed bean class is a generic type, it must have scope @Dependent. If a managed bean with a parameterized bean class declares any scope other than @Dependent, the container automatically detects the problem and treats it as a definition error.

Now, if this bean comes from the library, they might have been using older version of WebSphere which means there was OWB as CDI impl (on newer versions and on all other AS except TomEE there is Weld instead). OWB might have some unportable configuration allowing this (pure guess), but from CDI point of view this is just plain incorrect setup and should not work.

If it's your bean, you should make it @Dependent and that would make the error go away.

As a last, hacky, resort, you could in theory add an extension and override their scope with dependent one, but in such case you are very likely to break whole library.

It's not my bean. I think I'm out of luck. And as we work for the federal govt it is highly likely they developed this library with older version of websphere. I think I'm out of luck with this. Thanks. They have a webservice we can use as a workaround. — april26, Jul 03 '17 at 11:30
It is still strange that they have it this way. I suggest you reach out and tell them about this bug. If they just correct this to make it accordingly to specification, it should work for you too. Then again, it might not be easily achievable. — Siliarus, Jul 03 '17 at 11:47
I reached out prior to posting here, and they said "sorry we only support websphere". I'll try the new version in 6 months and maybe it will be fixed. — april26, Jul 03 '17 at 16:37

Websphere code on Wildfly

1 Answers1