-
15. Re: Packing WAR to EAR fails to deploy
Hi,
you need the JNDI-pattern for Seam to find the different beans. The way you state is not correct, because Seam is not looking in those directories for the properties-file.
Just add the following in the file components.xml
<core:init jndi-pattern="YOUREARNAME/#{ejbName}/local" />Where YOUREARNAME must be replaced with the final EAR-name. So if you have a name MYEAR1.0.0 that is exactly what should be put there.
Example:<core:init jndi-pattern="MYEAR1.0.0/#{ejbName}/local" />Leo
-
16. Re: Packing WAR to EAR fails to deploy
Hi,
small addition:
You already have such a tag in components.xml, so the existing one should be edited to:
<core:init jndi-pattern="MYEAR1.0.0/#{ejbName}/local" debug="true"/>Leo
-
17. Re: Packing WAR to EAR fails to deploy
Leo van den Berg wrote on Apr 05, 2011 09:34:
Hi,
small addition:
You already have such a tag in components.xml, so the existing one should be edited to:<core:init jndi-pattern="MYEAR1.0.0/#{ejbName}/local" debug="true"/>
LeoLeo, you are right, I've modified my existent core:init tag.
My ear file named my.app.ear andmy.app
is a value of display-name tag of my application.xml so I got a following line in components.xml<core:init debug="true" jndi-pattern="my.app/\#{ejbName}/local" />But unfortunately nothing is changed (((
-
18. Re: Packing WAR to EAR fails to deploy
Hi,
just to be sure:
<core:init debug="true" jndi-pattern="my.app/#{ejbName}/local" />(remove the additional backslash)
And if that doesn't work. Send the stack-trace of the error, because you didn't answer my question about WHAT componet is not loaded. Is that Seam or one of your own beans.
Leo
-
19. Re: Packing WAR to EAR fails to deploy
Leo van den Berg wrote on Apr 05, 2011 10:15:
Hi,
just to be sure:<core:init debug="true" jndi-pattern="my.app/#{ejbName}/local" />
(remove the additional backslash)
And if that doesn't work. Send the stack-trace of the error, because you didn't answer my question about WHAT componet is not loaded. Is that Seam or one of your own beans.
LeoLeo, removing the backslash doesn't helps.
I've answered you at 8:00 that it throws error when trying to create my own component annotated with @Name.
Here is a stacktrace:2011-04-05 18:23:23,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/mobimoney.csdm.web]] (main) Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener java.lang.RuntimeException: Could not create Component: checkableRecordHome at org.jboss.seam.init.Initialization.addComponent(Initialization.java:1202) at org.jboss.seam.init.Initialization.installComponents(Initialization.java:1118) at org.jboss.seam.init.Initialization.init(Initialization.java:733) at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:36) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142) at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) at org.jboss.web.deployers.WebModule.start(WebModule.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) at $Proxy38.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.ServiceController.doChange(ServiceController.java:688) at org.jboss.system.ServiceController.start(ServiceController.java:460) at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461) at org.jboss.Main.boot(Main.java:221) at org.jboss.Main$1.run(Main.java:556) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NoClassDefFoundError: com/mobimoney/csdm/domain/DomainElement at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63) at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572) at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507) at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134) at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131) at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452) at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251) at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798) at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.jboss.classloader.plugins.loader.ClassLoaderToLoaderAdapter.loadClass(ClassLoaderToLoaderAdapter.java:172) at org.jboss.classloader.spi.ClassLoaderDomain.loadClassFromParent(ClassLoaderDomain.java:352) at org.jboss.classloader.spi.ClassLoaderDomain.loadClassAfter(ClassLoaderDomain.java:323) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:275) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798) at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.privateGetPublicMethods(Class.java:2547) at java.lang.Class.getMethods(Class.java:1410) at org.jboss.seam.Component.hasAnnotation(Component.java:1158) at org.jboss.seam.Component.<init>(Component.java:218) at org.jboss.seam.Component.<init>(Component.java:205) at org.jboss.seam.init.Initialization.addComponent(Initialization.java:1186) ... 73 more Caused by: java.lang.ClassNotFoundException: com.mobimoney.csdm.domain.DomainElement at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:292) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798) at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441) at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
But
com.mobimoney.csdm.domain.DomainElement
class file is in war/WEB-INF/lib. I've checked this multiple times.
The seam component itself that cannot be created are also in this (the same) war in classes subdir. -
20. Re: Packing WAR to EAR fails to deploy
Hi,
look in this thread, but this is the first time you send the stacktrace. I need something more than just the first line.
What I see now, is that you're trying to use domain-model classes from within the WAR, If these classes are (for instance) used by your EJB they can't be located, because the WAR-lib directory is not a
class-path
dir, Place these classes (inside a JAR) in the root-lib.Leo
-
21. Re: Packing WAR to EAR fails to deploy
Leo van den Berg wrote on Apr 05, 2011 11:01:
Hi,
look in this thread, but this is the first time you send the stacktrace. I need something more than just the first line.
What I see now, is that you're trying to use domain-model classes from within the WAR, If these classes are (for instance) used by your EJB they can't be located, because the WAR-lib directory is not aclass-path
dir, Place these classes (inside a JAR) in the root-lib.
LeoI didn't understand what you mean saying that this is a first line. This is a complete error message with full stacktrace in server.log. The previous line is:
18:23:16,957 INFO [ServletContextListener] Welcome to Seam 2.2.0.GA
My war is a complete seam application. As I mentioned earlier it works fine when it is deployed as war. This is why all domain-model classes are is in war/web-inf/lib. But now I've developed a stateless ejb (exposed as web service) which is not used libraries from existent seam war. But I want to deploy my war and new ejb as a single ear application. After I packed it all in ear I've discovered the problem described in this topic.
-
22. Re: Packing WAR to EAR fails to deploy
Hi,
I think we are miscommunicating now. When you send an error, it is very helpful that you send the complete error, and not only the first line. An error can have various reasons, so you need to scroll through the
cause by
. The error is VERY clear to me. The application can't find the classes. So you need to re-consider your packaging. Changing from WAR to EAR is not only the change of an extension.The application server handles and EAR differently. If the web-service uses the entity mentioned in the Stack-trace (just assuming now) , it COULD be the cause of your problem. Again, I am only assuming, because I can't guess what's your application is all about, what it supposed to do and what beans you have.
I also assume that you don't have much experience in this EAR-applications, so it's wise to dig in that first. Most important tip for development: DON't trust your IDE. So if you build your application with ECLIPSE, UNZIP the final EAR to see if everything is there. You would be surprised how often that goes wrong.
Furthermore (if the mentioned class is not for your Webservice), see where the mentioned class is used, if it is used by a Seam-managed bean check that relation. Again WAR deployment is not the same as EAR deployment.
Leo
-
23. Re: Packing WAR to EAR fails to deploy
Leo van den Berg wrote on Apr 06, 2011 03:39:
Hi,
I think we are miscommunicating now. When you send an error, it is very helpful that you send the complete error, and not only the first line. An error can have various reasons, so you need to scroll through thecause by
. The error is VERY clear to me. The application can't find the classes. So you need to re-consider your packaging. Changing from WAR to EAR is not only the change of an extension.
The application server handles and EAR differently. If the web-service uses the entity mentioned in the Stack-trace (just assuming now) , it COULD be the cause of your problem. Again, I am only assuming, because I can't guess what's your application is all about, what it supposed to do and what beans you have.
I also assume that you don't have much experience in this EAR-applications, so it's wise to dig in that first. Most important tip for development: DON't trust your IDE. So if you build your application with ECLIPSE, UNZIP the final EAR to see if everything is there. You would be surprised how often that goes wrong.
Furthermore (if the mentioned class is not for your Webservice), see where the mentioned class is used, if it is used by a Seam-managed bean check that relation. Again WAR deployment is not the same as EAR deployment.
LeoLeo, you are right, this application is new to me. I'm trying to dig in it. Of course I'm operating with ear entrails and doesn't rely on eclipse builder.
Now I'm glad to anounce that problem is solved. This was my fault. I've moved one common library referenced from the seam component to ear root, but what I've missed that this class indirectly references some classes that stays in war - that was the problem.
Leo - very very much thanks to you. Your advises was very right and helpfull!