[JCA/JBoss] - Jboss4.2.2 hang up after tx rollback
by born_free
we are using jboss 4.2.2 and we are seeing jboss sever unresponsive after a transaction rollback.
| 2009-01-27 04:23:04,280 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-10.90.4.177-8080-31) TransactionRolledbackLocalException in method: public abstract com.comp.Types.ejb.interfaces.Types com.comp.Type.ejb.interfaces.TypesHome.findByType(java.lang.Long,java.lang.Long,java.lang.Long) throws javax.ejb.FinderException, causedBy:
| java.lang.UnsupportedOperationException
| at org.jboss.ejb.GlobalTxEntityMap$1.invokeEjbStore(GlobalTxEntityMap.java:113)
| at org.jboss.ejb.GlobalTxEntityMap$GlobalTxSynchronization.synchronize(GlobalTxEntityMap.java:300)
| at org.jboss.ejb.GlobalTxEntityMap.synchronizeEntities(GlobalTxEntityMap.java:227)
| at org.jboss.ejb.EntityContainer.synchronizeEntitiesWithinTransaction(EntityContainer.java:136)
| at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1096)
| at org.jboss.ejb.EntityContainer.findLocal(EntityContainer.java:676)
| at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
| at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
| at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
| at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
| at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
| at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
| at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:136)
| at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
| at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:45)
| at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
| at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
| at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
| at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
| at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
| at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
| at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
| at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
| at org.jboss.ejb.Container.invoke(Container.java:981)
| at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:359)
| at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
|
we are using Oracle 11g as our database. Any idea whats is going wrong here. Any pointer/reference is helpfull.
-- born
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204873#4204873
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204873
17 years, 2 months
[Installation, Configuration & DEPLOYMENT] - Configuration Issues when trying to use Alternative Database
by gbsendhil
I am trying to Use Alternative Databases ( MS SQL) with JBoss AS. I placed sqljdbc.jar in server/default /lib as i am using default configuration
I am getting this error.
10:15:52,115 ERROR [AbstractKernelController] Error installing to ClassLoader: name=vfsfile:/C:/jboss-5.0.0.GA/server/default/conf/jboss-service.xml state=Describe mode=Manual requiredState=ClassLoader
org.jboss.deployers.spi.DeploymentException: Error creating classloader for vfsfile:/C:/jboss-5.0.0.GA/server/default/conf/jboss-service.xml
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.createClassLoader(AbstractDeploymentContext.java:576)
at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.createClassLoader(AbstractDeploymentUnit.java:159)
at org.jboss.deployers.spi.deployer.helpers.AbstractClassLoaderDeployer.deploy(AbstractClassLoaderDeployer.java:53)
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.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
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:545)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:274)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
at org.jboss.Main.boot(Main.java:209)
at org.jboss.Main$1.run(Main.java:547)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.Error: Error visiting DelegatingHandler(a)18734604[path=sqljdbc.jar context=file:/C:/jboss-5.0.0.GA/server/default/lib/ real=file:/C:/jboss-5.0.0.GA/server/default/lib/sqljdbc.jar]
at org.jboss.classloading.plugins.vfs.PackageVisitor.determineAllPackages(PackageVisitor.java:98)
at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.determineCapabilities(VFSDeploymentClassLoaderPolicyModule.java:108)
at org.jboss.classloading.spi.dependency.Module.getCapabilities(Module.java:485)
at org.jboss.classloading.spi.dependency.Module.determinePackageNames(Module.java:544)
at org.jboss.classloading.spi.dependency.Module.getPackageNames(Module.java:529)
at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.determinePolicy(VFSDeploymentClassLoaderPolicyModule.java:129)
at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.determinePolicy(VFSDeploymentClassLoaderPolicyModule.java:48)
at org.jboss.classloading.spi.dependency.policy.ClassLoaderPolicyModule.getPolicy(ClassLoaderPolicyModule.java:149)
at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.getPolicy(VFSDeploymentClassLoaderPolicyModule.java:122)
at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.getPolicy(VFSDeploymentClassLoaderPolicyModule.java:48)
at org.jboss.classloading.spi.dependency.policy.ClassLoaderPolicyModule.registerClassLoaderPolicy(ClassLoaderPolicyModule.java:88)
at org.jboss.deployers.plugins.classloading.AbstractLevelClassLoaderSystemDeployer.createClassLoader(AbstractLevelClassLoaderSystemDeployer.java:120)
at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.createClassLoader(AbstractDeploymentContext.java:562)
... 21 more
Caused by: java.lang.RuntimeException: Failed to read zip file: org.jboss.virtual.plugins.context.zip.ZipFileWrapper@f21478 - C:\jboss-5.0.0.GA\server\default\tmp\vfs-nested.tmp\5dad160c_sqljdbc.jar
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:563)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.checkIfModified(ZipEntryContext.java:693)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.getChildren(ZipEntryContext.java:765)
at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChildren(ZipEntryHandler.java:149)
at org.jboss.virtual.plugins.context.DelegatingHandler.getChildren(DelegatingHandler.java:120)
at org.jboss.virtual.plugins.context.AbstractVFSContext.getChildren(AbstractVFSContext.java:171)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:288)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:258)
at org.jboss.virtual.VFS.visit(VFS.java:404)
at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:407)
at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:356)
at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:337)
at org.jboss.classloading.plugins.vfs.PackageVisitor.visit(PackageVisitor.java:200)
at org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:313)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:258)
at org.jboss.virtual.VFS.visit(VFS.java:404)
at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:407)
at org.jboss.classloading.plugins.vfs.PackageVisitor.determineAllPackages(PackageVisitor.java:94)
... 33 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.zip.ZipFile.(ZipFile.java:131)
at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.ensureZipFile(ZipFileWrapper.java:175)
at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.acquire(ZipFileWrapper.java:245)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.initEntries(ZipEntryContext.java:461)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:554)
... 51 more
10:15:52,130 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
*** CONTEXTS IN ERROR: Name -> Error
vfsfile:/C:/jboss-5.0.0.GA/server/default/conf/jboss-service.xml -> java.util.zip.ZipException: error in opening zip file
10:15:52,130 INFO [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)] Started in 4s:953ms
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204871#4204871
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204871
17 years, 2 months
[Tomcat, HTTPD, Servlets & JSP] - Re: JBoss Web
by dgenkin
was able to fix it. i specified additional variables in bashrc and also added the following to catalina.sh:
# Setup JBosst Native library path
JBOSSWEB_NATIVE_DIR="$JBOSSWEB_HOME/bin/native"
if [ -d "$JBOSSWEB_NATIVE_DIR" ]; then
if $cygwin ; then
export PATH="$JBOSSWEB_NATIVE_DIR:$PATH"
JBOSSWEB_NATIVE_DIR=`cygpath --dos "$JBOSSWEB_NATIVE_DIR"`
fi
if [ "x$LD_LIBRARY_PATH" = "x" ]; then
LD_LIBRARY_PATH="$JBOSSWEB_NATIVE_DIR"
else
LD_LIBRARY_PATH="$JBOSSWEB_NATIVE_DIR:$LD_LIBRARY_PATH"
fi
export LD_LIBRARY_PATH
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Djava.library.path=$JBOSSWEB_NATIVE_DIR"
else
JAVA_OPTS="$JAVA_OPTS -Djava.library.path=$JBOSSWEB_NATIVE_DIR"
fi
fi
Now I see this: INFO: Loaded Apache Tomcat Native library 1.1.16.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204862#4204862
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204862
17 years, 2 months
[EJB 3.0] - Re: Ejb3 sources in zipped form
by ALRubinger
"skajotde" wrote : Version madnes is my argument and I describe my way to improve/balance this situation ;) (from experience with work on granular libraries).
That's fair, but your proposal involves coupling the release schedule of all EJB3 components. This comes at the cost of the 2 drawbacks I'd presented.
Would an additional assembly of all the EJB3 component resources in one place solve this? ie. ejb3-sources-1.0.0.jar, which contains all the sources from the various component versions that are in the EJB3 1.0.0 distribution?
"skajotde" wrote : Please don't generalise. There are projects as like whole EJB3, dont libraries.
You've now defined a difference between "project" (ie. EJB3) and "library" (the components that make up a project release); that distinction wasn't present before.
"skajotde" wrote : In definition I would separate projects from libraries. Project has separate vesioning and release schedule but library not necessary.
For the reasons laid out previously, separate release schedule for each component is necessary (or at least desirable). This *ensures* that nothing has changed when no source changes have been made. It's about a guarantee of stability, one of the reasons we've componentized so heavily in the first place.
"skajotde" wrote : You say maven releases will have independent releases - ok, so I think there should be additional release as zipped whole binary because it is project not library. Why EJB3 doesn't release zipped distribution like JBossWS, JBossAS, JBM (there is secret installer) ? We are in Linux World and Linux Users don't like when something try hide details.
I think you're just asking for a new assembly to contain all of the EJB3 binaries in a unified JAR. And another one for all sources.
"skajotde" wrote : I'm not pro shell scripts but ejb3-installer imho should be in zipped distro and operates on files in this zip. Now I guess it downloads jars from maven repo ?
No, the ejb3-plugin contains all artifacts to be installed, and is a standard executable JAR. There's no downloading involved.
"skajotde" wrote : I suspect you are maven fan and it is main reason to using automagic installer. I'm not so (I have many trouble with unpredicatble maven dependencies). When you download whole distribution there is closed space and you see what you get. With maven this space of dependecies are open and very fast grow (to 1GB maven repo) and I have many class conflicts because I dont see which library is using. Predicable closed dependencies is my prefered way to configure project and it is main reason I ask if there is enable one whole binary of EJB3. So user is not forced to maven when using EJB3.
I didn't follow a lot of that reasoning.
* We use Maven as a build tool and work through both its benefits and shortcomings. No one I've found has been a "fan" for any non-technical reason.
* Maven has nothing to do with the "automagic installer" (ejb3-plugin).
* As an end-user you're not forced to use Maven at all. Take our built artifacts and go.
* The issue of dependencies isn't just Maven's fault. The EJB3 project must declare dependencies to be built, and AS provides its own dependency chain. So there's a compilation/test set and a runtime set, which may be mismatched. We've been in talks to address this.
"skajotde" wrote : Little digression and other question: What is way to get dependency to ejb3 in my maven project. I will have to list all libraries explicite, all 22 libraries ?
Just bring in org.jboss.ejb3:jboss-ejb3-as-int:1.0.0. Everything else will come in transitively.
But if you're just building applications that *use* JBoss EJB3, you can get by with just the EJB3 API and the JBoss EJB3 External API. Or more simply, a dependency upon jbossall-client.jar.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204860#4204860
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204860
17 years, 2 months