[JBoss JIRA] Created: (JBRULES-1229) separate compile classpath from class loader's getResource() facility
by Godmar Back (JIRA)
separate compile classpath from class loader's getResource() facility
---------------------------------------------------------------------
Key: JBRULES-1229
URL: http://jira.jboss.com/jira/browse/JBRULES-1229
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.1
Reporter: Godmar Back
Assigned To: Mark Proctor
Priority: Minor
The current compiler relies on being able to read the bytecode for referred-to classes as a resource. For instance, to resolve the name "org.jboss.pkg.Clazz", a resource "org/jboss/pkg/Clazz.class" must be accessible.
This requirement is not part of the public interface of a class loader. Read the Sun Java documentation, which states: "A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code."
Although, this approach works by coincidence since most class loaders in fact return this resource - at least class loaders that don't do anything fancy to bytecode before defining classes, a more principled solution would separate the classpath used by the runtime engine from the classpath used by the compiler. (This is, for instance, what javac or practically all command-line compilers do.)
My suggestion is to either document this dependency on this particular class loader behavior, or, better, introduce a specific type resolver for the compilation process that is separated from the class loader's resource loading mechanism.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 3 months
[JBoss JIRA] Created: (JBAS-4998) App could Dynamically create Connection Pool in 3.0, but crashes in 4.2.1
by Steve Davidson (JIRA)
App could Dynamically create Connection Pool in 3.0, but crashes in 4.2.1
-------------------------------------------------------------------------
Key: JBAS-4998
URL: http://jira.jboss.com/jira/browse/JBAS-4998
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services, Transaction Manager
Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
Environment: SuSE 10.1
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
JBoss 4.2.1
Reporter: Steve Davidson
Assigned To: Dimitris Andreadis
Greetings.
Due to the fact that this application has dozen's of different Databases to talk to (later hundreds, then maybe more), other than a 'bootstrap connection pool' to the 'master database, all connection pools have to be created dynamically. The connection information is stored in a master database (the fact that we need a Database to keep track of the connection info for all the databases should say much).
In JBoss 3.0 & 3.2.8, it is quite possible to create these connections dynamically. This has been working for some time, actually (starting with JBoss 3.0Beta2). Had to tweak the code a bit when migrating to 3.2.8 a while back, but got it working again quite nicely (still is, actually, in production).
Since JBoss 3.x is end of life, we've started migrating to JBoss 4.2.8. The objects that were originally used seem to have been changed. I've updated most of the calls, but at this time, I am getting the following failure;
14:56:39,120 DEBUG [com.security.ejb.UserEJB.initializeState(UserEJB.java:318)] Exception getting Row from Service layer: Unable to obtain Database Connection from the Connection Pool: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))
Error! Unable to obtain Database Connection from the Connection Pool: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))\n\nPlease contact Administrator and relay the following information:\n\nMessage: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))\nSQLState: null\nError Code: 0\n
at com.common.ejb.DBConnection.getConnection(DBConnection.java:171)
at com.common.ejb.DBConnection.prepareStatement(DBConnection.java:469)
at com.common.ejb.DBConnection.executePreparedSQLQuery(DBConnection.java:386)
at com.common.ejb.CommonService.getRow(HRXCommonService.java:318)
at com.security.ejb.UserEJB.initializeState(UserEJB.java:306)
at com.security.ejb.UserEJB.ejbLoad(UserEJB.java:255)
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:585)
at org.jboss.ejb.plugins.BMPPersistenceManager.loadEntity(BMPPersistenceManager.java:435)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:278)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
at org.jboss.ejb.Container.invoke(Container.java:960)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ejb.EntityInterceptor.invoke(EntityInterceptor.java:112)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy75.logIn(Unknown Source)
at com.security.ThinUserProxy.logIn(ThinUserProxy.java:233)
at com.security.servlet.LoginServlet.logIn(LoginServlet.java:275)
at com.security.servlet.LoginServlet.doPost(LoginServlet.java:127)
at com.security.servlet.LoginServlet.service(LoginServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.jsr77.Jsr77ServletHolder.handle(Jsr77ServletHolder.java:74)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:227)
at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:626)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:94)
at com.common.ejb.DBConnection.getConnection(DBConnection.java:164)
... 68 more
Caused by: org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >)
at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:343)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
... 69 more
Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >
at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:744)
at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:577)
at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:337)
... 73 more
14:56:39,160 WARN [com.security.ejb.UserEJB.ejbLoad(UserEJB.java:257)] common.error.db.connectionfailed
E
The line failing in DBConnection is 'datasource.getConnection'.
I will be attaching the appropriately sanitized log files shortly.
There is currently no viable workaround. I will be posting the code used to create the Connection Pools and DataSources dynamically. If helpful, I can post the the 3. & 3.2 version as well as the 4.2 version.
Regards,
Steve
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 3 months
[JBoss JIRA] Created: (JBAS-5001) JBoss MBean Creation/Delpoyment no longer compatible with 2-Phase JBoss Transaction Manager
by Steve Davidson (JIRA)
JBoss MBean Creation/Delpoyment no longer compatible with 2-Phase JBoss Transaction Manager
-------------------------------------------------------------------------------------------
Key: JBAS-5001
URL: http://jira.jboss.com/jira/browse/JBAS-5001
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX, Transaction Manager
Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
Environment: Linux (SuSE 10.0/10.1)
java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
Reporter: Steve Davidson
Assigned To: Dimitris Andreadis
Greetings.
This issue was discovered when upgrading from JBoss 3.2 -> JBoss 4.2. When creating a Datasource dynamically from an EJB with an active transaction, via the appropriate JBoss Manager classes, the trransaction can not complete with the following exception;
14:56:39,120 DEBUG [com.security.ejb.UserEJB.initializeState(UserEJB.java:318)] Exception getting Row from Service layer: Unable to obtain Database Connection from the Connection Pool: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))
Error! Unable to obtain Database Connection from the Connection Pool: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))\n\nPlease contact Administrator and relay the following information:\n\nMessage: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))\nSQLState: null\nError Code: 0\n
Specifically, once the DataSource has been created, it can not be used in the same transaction that it was created, and is destroyed when the transaction rollsback due to the above exception.
This was originally misdiagnosed/misreported, under http://jira.jboss.com/jira/browse/JBAS-4998?page=all. Logs, and code snippets can be found there.
Current workaround is to 'allowMultipleLastResources=true' in conf/jbossjta-properties.xml.
19:47:18,092 WARN [com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:910)] [com.arjuna.ats.internal.jta.transaction.arjunacore.lastResource.multipleWarning] [com.arjuna.ats.internal.jta.transaction.arjunacore.lastResource.multipleWarning] Multiple last resources have been added to the current transaction. This is transactionally unsafe and should not be relied upon. Current resource is org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource@23d87f
-Steve
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 3 months
[JBoss JIRA] Created: (JBAS-4951) Retry debug message within UnifiedInvokerHAProxy.invoke() is misleading
by Galder Zamarreno (JIRA)
Retry debug message within UnifiedInvokerHAProxy.invoke() is misleading
-----------------------------------------------------------------------
Key: JBAS-4951
URL: http://jira.jboss.com/jira/browse/JBAS-4951
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.2.GA, JBossAS-5.0.0.Beta2
Reporter: Galder Zamarreno
Assigned To: Brian Stansberry
Priority: Minor
UnifiedInvokerHAProxy.invoke():
...
failoverAuthorized = txContextAllowsFailover(invocation);
failoverCounter++;
invocation.setValue("FAILOVER_COUNTER", new Integer(failoverCounter), PayloadKey.AS_IS);
log.debug("Received GenericClusteringException where request was not completed. Will retry.");
continue;
...
The debug message before continue is misleading. The call will only be retried if the failover is authorised and
there're any targets available, otherwise it won't. The log message should be reworded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 3 months
[JBoss JIRA] Created: (JBRULES-1250) Allow option to completely remove an asset from the repository
by Shahad Ahmed (JIRA)
Allow option to completely remove an asset from the repository
--------------------------------------------------------------
Key: JBRULES-1250
URL: http://jira.jboss.com/jira/browse/JBRULES-1250
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-brms
Affects Versions: 4.0.1
Reporter: Shahad Ahmed
Assigned To: Mark Proctor
If you use the archive feature to remove a rule or package from the BRMS it is not really seen as gone, as if you attempt to create a new rule or package with the same name as the archived rules or package then you get an error saying that the rule or package already exists (looking at the source code, the repository does not care if an item is archived or not, so it will always throw an error if an asset with an existing name is created).
I'm assuming this is the designed behaviour and not a bug (I've asked about this a couple of times on the user list and got no replies to the contrary).
However, it would be very useful to be able to remove a rule or package so that you can then recreate it (e.g by importing new versions from a drl file). At present, you have to laboriously rename the rules and packages you want to remove, so that when they are archived their names do not clash with the new versions of the rules and packages you want to import or recreate. Perhaps all that is involved in implementing this new remove feature is to just automatically rename the package and its rules before archiving it?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 3 months
[JBoss JIRA] Created: (JBCACHE-1126) distribution example cannot complete (2.0 CR3)
by Aleksandar Kostadinov (JIRA)
distribution example cannot complete (2.0 CR3)
----------------------------------------------
Key: JBCACHE-1126
URL: http://jira.jboss.com/jira/browse/JBCACHE-1126
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.CR3
Environment: linux, jdk1.5.0_11
Reporter: Aleksandar Kostadinov
Assigned To: Manik Surtani
Fix For: 2.0.0.CR4
All examples fail - some can't compile, some at runtime. These that compile are running and seem to do something (at least eat some CPU cycles) but don't complete within few minutes and through exceptions so I consider them failing. Anything I'm doing wrong? btw I run with ant.
One problem with a known reason: on loadtime example path is specified with ";" between file names and not ":". To be portable to windows and unix ant path or location element has to be used.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 3 months
