Trying to get WorkManagers working with CommonJ in a Spring Boot app, hosted in TomEE.
Currently have the following configuration:
Tomcat context.xml
<Context>
<Resource name="myWorkManager"
auth="Container"
type="commonj.work.WorkManager"
factory="de.myfoo.commonj.work.FooWorkManagerFactory"
maxThreads="5" />
<ResourceLink
name="myWorkManager"
global="myWorkManager"
type="commonj.work.WorkManager" />
</Context>
Spring app web.xml
<resource-ref>
<res-ref-name>myWorkManager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
</resource-ref>
This is currently throwing the following exception when the app loads:
Caused by: org.springframework.jndi.TypeMismatchNamingException: Object of type [class de.myfoo.commonj.work.FooWorkManager] available at JNDI location [java:comp/env/myWorkManager] is not assignable to [commonj.work.WorkManager]
at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:182)
at org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:95)
at org.springframework.scheduling.commonj.WorkManagerTaskExecutor.afterPropertiesSet(WorkManagerTaskExecutor.java:110)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
... 53 more
I have the CommonJ jars downloaded from http://commonj.myfoo.de/install.shtml in my Tomcat lib directory.
I feel like I'm getting pretty close but slightly puzzled by this exception.
Any help would be much appreciated.
UPDATE
If I remove the two CommonJ jars from TomEE lib folder, I get this exception
Caused by: java.lang.ClassNotFoundException: commonj.work.WorkManager
Which is what I would expect.
If I remove the factory property from the resource element I get:
Caused by: org.springframework.jndi.TypeMismatchNamingException:
Object of type [class org.apache.openejb.core.ivm.naming.IvmContext]
available at JNDI location [java:comp/env/wm/default] is not
assignable to [commonj.work.WorkManager]
Im encounter with same issue, when try to start my app locally in maven-jetty-plugin. M. Deinum comment was very helpful. This error happens if you have lib jar in shared lib of your Application Server and in your WEB-INF/lib folder of web application, because server use one jar to create resource (parent classloader), but application use self jar(child classloader) and it two different classes hierarchy, so FooWorkManager cant be cast to WorkManager.
Related
I am migrating an old application running on java 1.5 and jboss 4.3 to java 1.8 and jboss 7.2. While deploying on jboss 7.2, I am getting error related to resource-ref defined under ejb-ref in jboss-web.xml.
I was able to transform other parts of the application like moving libraries to modules and changes in EJB lookup jndi however I am not able to find a solution to make resource-ref work with ejb-ref
<jboss-web>
...
<ejb-ref>
<ejb-ref-name>ejb/CA_ProductEJBHome</ejb-ref-name>
<ejb-link>ProductEJB.jar#CA_ProductEJB</ejb-link>
<jndi-name>CA_ProductEJB</jndi-name>
<resource-ref>
<description>Product Database</description>
<res-ref-name>jdbc/productDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<jndi-name>java:jboss/datasources/CA_productDB</jndi-name>
<res-auth>Container</res-auth>
</resource-ref>
</ejb-ref>
...
</jboss-web>
Error Trace :
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[127,3]
Message: Unexpected element 'resource-ref' encountered
at org.jboss.metadata.parser.util.MetaDataElementParser.unexpectedElement(MetaDataElementParser.java:115)
at org.jboss.metadata.parser.ee.EJBReferenceMetaDataParser.parse(EJBReferenceMetaDataParser.java:90)
at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parseRemote(EnvironmentRefsGroupMetaDataParser.java:108)
Very interesting question.
Issue below:
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[127,3]
Message: Unexpected element 'resource-ref' encountered
at org.jboss.metadata.parser.util.MetaDataElementParser.unexpectedElement(MetaDataElementParser.java:115)
So in for EAP 6/7 we needed to modify the JNDI names, following a name convention.
JNDI name convention
Following the migration guide in 3.2.14.2.3. Application Changes Required to Run EJB 2.x
We go to: Modify the JBoss-web.xml File Descriptor, which describes that you must modify the for each for 'new JNDI fully qualified' lookup format: either java:global, or java:module, or java:app.
Exception
My guess is that the parser, while reading the tag, was expecting this standard and since it didn't find the exception was thrown. Pay attention also on the parenting since is at the same level as
Regards
Trying to get my jee ear deployed to wildfly 15 or 16.
I get this error:
"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"test.ear\".\"web.war\".INSTALL" => "WFLYSRV0153: Failed to process phase INSTALL of subdeployment \"web.war\" of deployment
\"test.ear\"
Caused by: java.lang.IllegalArgumentException: Cannot both require and provide same dependency:service jboss.naming.context.java.module.test.web.env.mainDB"},
mainDB is a postgresql datasource configured in standalone.xml.
Any pointers in how I might track the source of the problem would be helpful.
Thanks!
The same exact ear deploys without any problems on wildfly versions prior 14.0.1. Tested on 14.0.1, 10.0.1, 9 and 8.
The jboss-web.xml in web.war/WEB-INF had this:
<jboss-web>
<resource-ref>
<res-ref-name>mainDB</res-ref-name>
<jndi-name>mainDB</jndi-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</jboss-web>
Once I removed this, the ear deployed without any problems on both wildfly 15 and 16.
Apparently, this was used to alias a datasource while migrating code a while back.
What is resource-ref in web.xml used for?
Since then, the code has been updated and the alias was no longer used, which resulted in the alias being the same as the jndi-name, this is no longer necessary and caused the deployment to fail.
I am deploying a WAR to JBoss EAP 7. In my WAR's META-INF/context.xml file I have the following:
<Context unloadDelay="500000">
<Resource name="jdbc/sybase/somedb"
auth="Container"
type="javax.sql.DataSource"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sybase://localhost:12501/somedb"
username="username" password="secret"
validationQuery="select 1"
maxActive="2" maxIdle="0" maxWait="-1"/>
...
From my Java code I try to obtain the DataSource doing a:
InitialContext cxt = new InitialContext();
DataSource ds = (DataSource) cxt.lookup( "java:/comp/env/jdbc/sybase/somedb" );
The exact above code works and the name is found in the context when I deploy to Tomcat 8 but not when I deploy to JBoss EAP 7. In the latter case I get:
Caused by: javax.naming.NameNotFoundException: comp/env/jdbc/sybase/somedb -- service jboss.naming.context.java.comp.env.jdbc.sybase.somedb
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
What am I doing wrong and how can I fix the above problem?
Your META-INF/context.xml file is a Tomcat deployment descriptor (not defined by the Java EE specification) so it is not seen or parsed by JBoss EAP 7.
There are many alternatives to this including the solution to is there a standard way to define a JDBC Datasource for Java EE containers.
If you were to ask RedHat support they would likely recommend that you create the datasource using server administration tools such as the admin console or jboss-cli.sh. This decouples your application from the datasource definition so that you can specify environment specific settings (such as pool sizes and hostnames) without repackaging your WAR.file. This method also requires you to deploy the JDBC driver jar separately from your application.
I have one application using CDI with weld 2.2.9.Final and embedded Tomcat 7.0.57 and everything works fine.
After upgrading to embedded Tomcat 7.0.59, when I'm starting my application I got the following exception:
Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-001201: Error loading beans.xml jndi:/localhost/WEB-INF/beans.xml
at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:124)
at org.jboss.weld.bootstrap.WeldBootstrap.parse(WeldBootstrap.java:131)
at org.jboss.weld.environment.servlet.deployment.WebAppBeanArchiveScanner.scan(WebAppBeanArchiveScanner.java:78)
at org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.performDiscovery(AbstractDiscoveryStrategy.java:83)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.createDeployment(WeldServletLifecycle.java:230)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:120)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:61)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5513)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 6 more
Caused by: java.io.FileNotFoundException: jndi:/localhost/WEB-INF/beans.xml
at org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:384)
at java.net.URL.openStream(URL.java:1037)
at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:101)
... 14 more
The problem is java.io.FileNotFoundException: jndi:/localhost/WEB-INF/beans.xml
I just bumped into something similar today. Either the file can't be found, or you are trying to include it from your web.xml with an ENTITY declaration. If you are trying to load beans.xml with an ENTITY declaration, then the problem is caused by a new security policy in Tomcat 7.0.59 -- blocking the loading of external entities is now the default. Context parameter xmlBlockExternal is now set to "true" by default.
You have to override this in a your context: either the main context in ~Tomcat/conf/context.xml or in your application-level context file. To override, add the param like this:
<Context xmlBlockExternal="false">
I'm getting a weird problem in GlassFish 2.1 - I'm a beginner with this container and I'm having trouble pinning this down.
I have a new install of GlassFish 2.1 with a JDBC connection pool defined called testDerbyPool. I then have a resource defined called jdbc/testDerbyPool pointing at that pool. The resource type is javax.sql.DataSource and I can successfully ping the pool.
I then have a single class in a webapp with this declaration:
#Resource(name="jdbc/testDerbyPool")
private javax.sql.DataSource source;
This declaration in my web.xml:
<resource-ref>
<res-ref-name>jdbc/testDerbyPool</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
When I try to deploy the application, I get this error:
[#|2009-09-09T21:40:47.582+0100|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=24;_ThreadName=Thread-32;_RequestID=1ca4ab80-ae39-4920-be18-f535b025bb51;|WebModule[/cptest1]PWC1275: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener
and a huge stack trace, starting:
java.lang.NoClassDefFoundError: LDataSource;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
with root cause:
Caused by: java.lang.ClassNotFoundException: DataSource
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1498)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
I don't understand how DataSource can be 'not found'! Any ideas?
Next time I went back after asking the question, I noticed a build error in Eclipse, somehow gotten an extra JRE in the path marked 'unbound'. Looking around my system, I got a JVM point release update automatically between starting Eclipse up and doing the build/deploy.
Anyway, removed it, tried again, worked.
So check for build errors and build path problems if you see this problem.