Page 1 of 1

deploy fail with JBoss 5.1

Posted: Thu Dec 09, 2010 1:35 am
by nick_tan
hi, folks,

i encounter a problem while trying to deploy broadleaf into JBoss 5.1
i got the following exception stack trace
i also googling for to fix it, but hope you guys can give a quick answer:)

thanks & best regards

Code: Select all

2010-12-09 14:26:29,170 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Start: name=persistence.unit:unitName=#blPU state=Create
java.lang.RuntimeException: Specification violation [EJB3 JPA 6.2.1.2] - You have not defined a non-jta-data-source for a RESOURCE_LOCAL enabled persistence context named: blPU
   at org.jboss.jpa.deployment.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:124)
   at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:275)
   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.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
   at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
   at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
   at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
   at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
   at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
   at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
   at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
   at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
   at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
   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.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.install(AbstractController.java:774)
   at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
   at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
   at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
   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.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.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:263)
   at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:177)
   at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
   at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
   at org.jboss.remoting.Client.invoke(Client.java:1724)
   at org.jboss.remoting.Client.invoke(Client.java:629)
   at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:305)
   at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:190)
   at org.jboss.profileservice.management.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:231)
   at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:88)
   at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:120)
   at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:103)
   at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:400)
   at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:211)
   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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)

Re: deploy fail with JBoss 5.1

Posted: Thu Dec 09, 2010 8:50 am
by jefffischer
Spring apps have a lot of problems of this nature on JBOSS. It results from the container and spring both battling for control of JPA in the environment. The best answer is to cause JBOSS to not participate at this level, since it's the intention of the broadleaf application design that spring handle this. This Jira post (although for an unrelated piece of software) appears to suggest a possible solution:

https://issues.jboss.org/browse/JBSEAM-3587

Unfortunately, the persistence.xml rename portion of the solution may be more invasive than what you want to take on, as it will require you to rename persistence.xml in the broadleaf core jars and alter the persistence unit manager configuration in the spring application contexts to reference the new name.

This is something I'll look into further for future releases. Also, I would be curious on the outcome of just trying the web.xml change they mention without the persistence.xml changes.

Re: deploy fail with JBoss 5.1

Posted: Sat Dec 11, 2010 12:36 am
by nick_tan
thanks, jefffischer

i tried this suggested by Allen in thread: https://issues.jboss.org/browse/JBSEAM-3587

Code: Select all

1. You're persistence unit descriptor must not be named persistence.xml (for instance, you can name it persistence-spring.xml)
2. The metadata-complete attribute of <web-app> must be set to true in web.xml


which bypass the "non-jta-data-source" issue, but new problem raised with compass 2.2.0:

Code: Select all

Caused by: org.compass.core.config.ConfigurationException: Failed to create scan factory for basePackage [org/broadleafcommerce/catalog/domain] and url [vfszip:/D:/dev/springsource/workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_Runtime_Server1291873919775/deploy/broadleafdemo.war/WEB-INF/lib/broadleaf-framework.jar/org/broadleafcommerce/catalog/domain/]; nested exception is java.io.IOException: Protocol [vfszip] is not supported by scanner
   at org.compass.core.config.CompassConfiguration.addScan(CompassConfiguration.java:587)
   at org.compass.core.config.builder.SchemaConfigurationBuilder.bindMappings(SchemaConfigurationBuilder.java:761)
   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.compass.core.config.builder.SchemaConfigurationBuilder.processCompass(SchemaConfigurationBuilder.java:85)
   ... 86 more
Caused by: java.io.IOException: Protocol [vfszip] is not supported by scanner
   at org.compass.core.config.binding.scanner.ScannerFactoy.create(ScannerFactoy.java:48)
   at org.compass.core.config.CompassConfiguration.addScan(CompassConfiguration.java:585)
   ... 92 more


according to the compass issue tracking,
ScannerFactory issue with Jboss AS 5.0 : Protocol [vfszip] is not supported http://issues.compass-project.org/browse/CMP-869
it got fixed in compass 2.3.0 beta1, but no jar available yet

Re: deploy fail with JBoss 5.1

Posted: Sat Dec 11, 2010 1:52 am
by nick_tan
well, the compass issue gone, by downloading compass 2.3.0 beta1 from other project (or guess that it works as well if build from compass svn trunk)

but new problem raised agsin, about hibernate validator

Code: Select all

Caused by: java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(java.lang.Class, java.util.ResourceBundle, org.hibernate.validator.MessageInterpolator, java.util.Map, org.hibernate.annotations.common.reflection.ReflectionManager)
   at java.lang.Class.getConstructor0(Class.java:2706)
   at java.lang.Class.getDeclaredConstructor(Class.java:1985)
   at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:362)
   ... 151 more


though i tried this:
http://forum.springsource.org/showthread.php?t=73879

but not work for me:(

Re: deploy fail with JBoss 5.1

Posted: Sat Dec 11, 2010 9:33 am
by jefffischer
If you look at the third post on this page, it looks like they've had some luck with some additional hibernate properties being set. These should go in one of the persistence.xml files (preferrably the one in your own broadleaf utilizing application if you've defined one there).

http://community.jboss.org/thread/153894

Re: deploy fail with JBoss 5.1

Posted: Sat Dec 11, 2010 9:45 am
by jefffischer
Also - a side note. JBOSS makes the assumption that you'll be using ejb3 for your application design, and as a result, they don't put in much effort to mitigate these kinds of clashes when you exit their happy path. Since you're not using ejb3 (broadleaf is a spring/hibernate app), I wonder what you're gaining by using JBOSS. You would probably be better off with a more agnostic container like Tomcat.