[JBoss JIRA] Commented: (EJBTHREE-489) @Service deployer doesn't notice superclass interfaces
by Carlo de Wolf (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-489?page=comments#action_12339376 ]
Carlo de Wolf commented on EJBTHREE-489:
----------------------------------------
JSR-000220 Enterprise JavaBeans v.3.0 ("Specification") Final Release, 4.6.6, 5th bullet:
The bean class must implement the interface or the interface must be designated as a local or
remote business interface of the bean by means of the Local or Remote annotation or in the
deployment descriptor.
> @Service deployer doesn't notice superclass interfaces
> ------------------------------------------------------
>
> Key: EJBTHREE-489
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-489
> Project: EJB 3.0
> Issue Type: Bug
> Affects Versions: EJB 3.0 RC5 - PFD
> Environment: JBoss 4.0.4RC1
> Reporter: Jeff Schnitzer
>
> The deployer for @Service beans gets confused when beans obtain their @Local or @Management interfaces from a base class. ie:
> class AbstractBase implements ServiceLocal, ServiceManagement {...}
> @Service(name="blah:service=ActualService")
> class ConcreteService extends AbstractBase {...}
> The stack trace on deployment:
> 2006-03-25 17:40:35,648 WARN [org.jboss.system.ServiceController] Problem creating service jboss.j2ee:service=EJB3,module=blah.jar
> java.lang.RuntimeException: bean class has no local or remote interfaces defined and does not implement at least one business interface
> at org.jboss.ejb3.ProxyFactoryHelper.getLocalInterfaces(ProxyFactoryHelper.java:71)
> at org.jboss.ejb3.ProxyDeployer.initializeLocalBindingMetadata(ProxyDeployer.java:117)
> at org.jboss.ejb3.SessionContainer.instantiated(SessionContainer.java:71)
> at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:546)
> at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:528)
> at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:509)
> at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:481)
> at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:438)
> at org.jboss.ejb3.Ejb3Module.createService(Ejb3Module.java:125)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
> at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 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:260)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:974)
> at $Proxy0.create(Unknown Source)
> at org.jboss.system.ServiceController.create(ServiceController.java:330)
> at org.jboss.system.ServiceController.create(ServiceController.java:273)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> 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:260)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:190)
> at $Proxy25.create(Unknown Source)
> at org.jboss.ejb3.EJB3Deployer.create(EJB3Deployer.java:345)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> 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.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:260)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:190)
> at $Proxy6.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:334)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:504)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:207)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:218)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:197)
--
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
17 years, 10 months
[JBoss JIRA] Closed: (JBMICROCONT-95) Inconsistent JavaBean property introspection
by Adrian Brock (JIRA)
[ http://jira.jboss.com/jira/browse/JBMICROCONT-95?page=all ]
Adrian Brock closed JBMICROCONT-95.
-----------------------------------
Resolution: Done
> Inconsistent JavaBean property introspection
> --------------------------------------------
>
> Key: JBMICROCONT-95
> URL: http://jira.jboss.com/jira/browse/JBMICROCONT-95
> Project: JBoss MicroContainer
> Issue Type: Bug
> Components: Configurator
> Environment: org.jboss.test.javabean.test.PropertyTestCase
> Reporter: Scott M Stark
> Assigned To: Adrian Brock
> Fix For: JBossMC_2_0_0M1
>
>
> There is an inconsistency between introspected bean properties relative to JavaBean conventions. The PropertyTestCase has a XYZ property in the SimpleBean that fails to parse with the following exception:
> Caused by: java.lang.IllegalArgumentException: No property 'XYZ' for AbstractBeanInfo(a)6e293a{name=org.jboss.test.javabean.support.SimpleBean classInfo= properties=[aBoolean, achar, anObject, aShort, aString, aNumber, afloat, aLong, abyte, anint, aDate, aboolean, xYZ, along, aFloat, aDouble, class, constructorUsed, ashort, aByte, adouble, aCharacter, aBigInteger, overloadedProperty, aBigDecimal, abc, anInt] methods=[hashCode, getXYZ, getABoolean, getConstructorUsed, setAnObject, setAshort, setADouble, clone, setALong, setOverloadedProperty, setOverloadedProperty, setOverloadedProperty, getAbyte, getANumber, getAString, setAlong, setANumber, setAdouble, getOverloadedProperty, getABigDecimal, setAbc, setAnInt, setAFloat, setABoolean, getAFloat, getAbc, getABigInteger, setAbyte, getAnObject, setXYZ, setAnint, getAlong, getAchar, setAchar, getADouble, setABigDecimal, equals, getAfloat, setABigInteger, wait, wait, wait, registerNatives, getAByte, setAString, notify, setACharacter, getClass, getADate, toString, setAByte, getALong, setAShort, getAdouble, notifyAll, getAnInt, setAboolean, finalize, getAshort, getACharacter, getAnint, isAboolean, getAShort, setADate, setAfloat] constructors=[] events=}
> at org.jboss.kernel.plugins.config.xml.JavaBeanSchemaInitializer.getProperty(JavaBeanSchemaInitializer.java:231)
> The PropertyTestCase also has a testJavaBeanMatching that illustrates the default JavaBean introspection behavior for an XYZ property, and the
> http://java.sun.com/products/javabeans/docs/spec.html talks about capitialization in section 8.8:
> 8.8 Capitalization of inferred names.
> When we use design patterns to infer a property or event name, we need to decide what rules
> to follow for capitalizing the inferred name. If we extract the name from the middle of a normal
> mixedCase style Java name then the name will, by default, begin with a capital letter.
> Java programmers are accustomed to having normal identifiers start with lower case letters.
> Vigorous reviewer input has convinced us that we should follow this same conventional rule
> for property and event names.
> Thus when we extract a property or event name from the middle of an existing Java name, we
> normally convert the first character to lower case. However to support the occasional use of all
> upper-case names, we check if the first two characters of the name are both upper case and if
> so leave it alone. So for example,
> "FooBah" becomes "fooBah"
> "Z" becomes "z"
> "URL" becomes "URL"
> We provide a method Introspector.decapitalize which implements this conversion rule.
--
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
17 years, 10 months
[JBoss JIRA] Updated: (JBMICROCONT-95) Inconsistent JavaBean property introspection
by Adrian Brock (JIRA)
[ http://jira.jboss.com/jira/browse/JBMICROCONT-95?page=all ]
Adrian Brock updated JBMICROCONT-95:
------------------------------------
Fix Version/s: JBossMC_2_0_0M1
Assignee: Adrian Brock
> Inconsistent JavaBean property introspection
> --------------------------------------------
>
> Key: JBMICROCONT-95
> URL: http://jira.jboss.com/jira/browse/JBMICROCONT-95
> Project: JBoss MicroContainer
> Issue Type: Bug
> Components: Configurator
> Environment: org.jboss.test.javabean.test.PropertyTestCase
> Reporter: Scott M Stark
> Assigned To: Adrian Brock
> Fix For: JBossMC_2_0_0M1
>
>
> There is an inconsistency between introspected bean properties relative to JavaBean conventions. The PropertyTestCase has a XYZ property in the SimpleBean that fails to parse with the following exception:
> Caused by: java.lang.IllegalArgumentException: No property 'XYZ' for AbstractBeanInfo(a)6e293a{name=org.jboss.test.javabean.support.SimpleBean classInfo= properties=[aBoolean, achar, anObject, aShort, aString, aNumber, afloat, aLong, abyte, anint, aDate, aboolean, xYZ, along, aFloat, aDouble, class, constructorUsed, ashort, aByte, adouble, aCharacter, aBigInteger, overloadedProperty, aBigDecimal, abc, anInt] methods=[hashCode, getXYZ, getABoolean, getConstructorUsed, setAnObject, setAshort, setADouble, clone, setALong, setOverloadedProperty, setOverloadedProperty, setOverloadedProperty, getAbyte, getANumber, getAString, setAlong, setANumber, setAdouble, getOverloadedProperty, getABigDecimal, setAbc, setAnInt, setAFloat, setABoolean, getAFloat, getAbc, getABigInteger, setAbyte, getAnObject, setXYZ, setAnint, getAlong, getAchar, setAchar, getADouble, setABigDecimal, equals, getAfloat, setABigInteger, wait, wait, wait, registerNatives, getAByte, setAString, notify, setACharacter, getClass, getADate, toString, setAByte, getALong, setAShort, getAdouble, notifyAll, getAnInt, setAboolean, finalize, getAshort, getACharacter, getAnint, isAboolean, getAShort, setADate, setAfloat] constructors=[] events=}
> at org.jboss.kernel.plugins.config.xml.JavaBeanSchemaInitializer.getProperty(JavaBeanSchemaInitializer.java:231)
> The PropertyTestCase also has a testJavaBeanMatching that illustrates the default JavaBean introspection behavior for an XYZ property, and the
> http://java.sun.com/products/javabeans/docs/spec.html talks about capitialization in section 8.8:
> 8.8 Capitalization of inferred names.
> When we use design patterns to infer a property or event name, we need to decide what rules
> to follow for capitalizing the inferred name. If we extract the name from the middle of a normal
> mixedCase style Java name then the name will, by default, begin with a capital letter.
> Java programmers are accustomed to having normal identifiers start with lower case letters.
> Vigorous reviewer input has convinced us that we should follow this same conventional rule
> for property and event names.
> Thus when we extract a property or event name from the middle of an existing Java name, we
> normally convert the first character to lower case. However to support the occasional use of all
> upper-case names, we check if the first two characters of the name are both upper case and if
> so leave it alone. So for example,
> "FooBah" becomes "fooBah"
> "Z" becomes "z"
> "URL" becomes "URL"
> We provide a method Introspector.decapitalize which implements this conversion rule.
--
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
17 years, 10 months
[JBoss JIRA] Commented: (JBCACHE-679) Deadlock using transactional JBossCache with Hibernate
by Yegor Yenikyeyev (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-679?page=comments#action_12339365 ]
Yegor Yenikyeyev commented on JBCACHE-679:
------------------------------------------
I forgot to add that in order to invoke the test you need to open servlet link like http://localhost:8080/nloptc/servlet/
> Deadlock using transactional JBossCache with Hibernate
> ------------------------------------------------------
>
> Key: JBCACHE-679
> URL: http://jira.jboss.com/jira/browse/JBCACHE-679
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Replication
> Affects Versions: 1.3.0.SP2
> Environment: SUSE 10.1, kernel 2.6.15 SPM, JDK 1.5.0_06, PostgreSQL 8.0.1
> Reporter: Yegor Yenikyeyev
> Assigned To: Manik Surtani
> Priority: Critical
> Attachments: nloptc.zip
>
>
> It seems like we discovered an unpredictable Hibernate and/or TreeCache behavior after upgrade JBossCache from 1.2.4SP2 to JBossCache 1.3.0SP2. For now I can witness that the same problem appears with 1.4.0CR2. I do not think that it's Hibernate-only or TreeCache-only issue but I do think it's a kind of integration issue or misunderstanding of how TreeCache transaction isolation is implemented.
> Our application works in clustered environment and we use JBossCache as L2 cache solution for Hibernate 3.1.3 (I checked this with 3.2.0CR2 as well). Our settings for JBossCache are
> REPL_SYNC, READ_COMMITED and our target business object methods (f1 and f2) have PROPAGATION_REQUIRED and PROPAGATION_REQUIRES_NEW. Our JDBC driver is 3.0 compliant.
> Our objects hierarchy is like: Occasion contains link to Round and Round contains link to Tournament. Round is NOT configured as "lazy" field in Occasion mapping b/c we always need to have it initialized.
>
> Here is in short what we try to do in our application:
>
> (1) Transaction1: Call f1 (PROPAGATION_REQUIRED) method of a business object and it causes Occasion1 to be loaded via a cachable query. After that Hibernate initializes Occasion1.round field and loads Round1.
> (2) Transaction1: Hibernate puts loaded Occasion1 and Round1 in L2 cache.
> (3) Transaction1: TreeCache creates com/companyname/Occasion/com.companyname.Occasion#1 region and obtains WriteLock (WL1)
> (4) Transaction1: TreeCache creates com/companyname/Round/com.companyname.Round#1 region and obtains WriteLock (WL2)
> (5) Transaction1: Do some business logic stuff
> (6) Transaction1: We expect current transaction to be long and we want to change status of Occasoin1 in DB very quickly. At this point we need an exclusive lock for appropriate row in DB table to change the status and commit it. In order to do this we call f2 (PROPAGATION_REQUIRES_NEW) which suppose to be a REALLY short transaction which release lock on the DB row as fast as possible.
>
> (7) Transaction2: Transaction1 SUSPENDED at this point. We call HibernateTemplate (we use Spring as well) to load Occasion1 for update with LockMode.UPGRADE flag and get exclusive lock.
> (8) Transaction2: Hibernate does NOT check for an instance of Occasion1 in L2 cache ( I suppose it's b/c we obviously do want to lock it for update )
> (9) Transaction2: Hibernate does check for an instance of Round1 in L2 cache and it calls get() on TreeCache to obtain com/companyname/Round/com.companyname.Round#1
> (10) Transaction2: At this point 1.3.0SP2 tries to obtain ReadLock for com/companyname/Round/com.companyname.Round#1 and it can't b/c there is a WL for that node in suspended Transaction1 !!! It can't obtain ReadLock for Round#1 anyhow!
> (11) Transaction2: Stuck waiting for WL2 to be released in TreeCache but it can't be released as soon as Transaction1 suspended and waits for Transaction2 to finish.
>
> Obviously this situation is ridiculous - a legal sequence of operations causes a deadlock on TreeCache. We do not expect com/companyname/Round/com.companyname.Round#1 to be visible in Transaction2 b/c we use READ_COMMITED but WL2 must not affect Transaction2 in this way. As soon as TreeCache prevents other transactions from reading com/companyname/Round/com.companyname.Round#1 it must not tell other transactions that the node exists to keep READ_COMMITED behavior consistent. For now it simply preventing everybody from using PROPAGATION_REQUIRES_NEW.
> The described scenario works with 1.2.4SP2 without a problem and I have serious concern that READ_COMMITED strategy is really implemented in v1.2.4 but at least the behavior is more consistent comparing to v1.3.0. As far as i understand this is result of JBCACHE-218 bugfix.
>
> We tried to change PROPAGATION_REQUIRES_NEW to PROPAGATION_NESTED and take advantage of nested transactions. We assume that com/companyname/Round/com.companyname.Round#1 would be available in a nested Transaction2 from Transaction1. But PROPAGATION_NESTED isn't supported by current JBossTransaction implementation (see line 209 in TxManager.java from 4.0.4.GA).
> We could change isolation to READ_UNCOMMITED but it's simply impossible in many other places of our application.
> We could make a trick and load Occasion1 with Round1 in a separate Transaction0 before starting Transaction1 but we HAVE to use LRU policy. That is why there is no chance for us to make sure that eviction won't happen between Transaction0 and Transaction1. If it happened then we are in the same situation as described above.
> Finally we could stop using Transaction2 but our application is intend to handle large amount of traffic and as soon as Transaction1 takes up to 3sec (comparing to 50ms for Transaction2) we might get up to 700-1000 transactions on queue waiting for table row lock to be released and we just can't allow this.
>
> From what I see in Hibernate TreeCache sources and I have no idea how to avoid the situation described above. One of my developers told me that probably it's possible to put stuff into L2 cache on transaction commit which would decrease WL time and resolve the issue with the deadlock. Honestly I'm seriously concerned how it applies to existing Hibernate. I think small issues like performance issue of loading the same object during 1 transaction more then once can be resolved by using L1 cache or JDBC driver abilities. But I guess there are a plenty of work to make this working for cachable queries.
> Another option I see is to do a trick and put values for Round1 and Occasion1 into a new region for Transaction2 if we know that Transaction1 suspended and owns WLs for various nodes. I really do not like this way b/c in fact it's not a pure pessimistic locking. But the issue described before is worse price for "pure" READ_COMMITED strategy. In fact it showstopper assuming there is no way to use PROPAGATION_NESTED.
--
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
17 years, 10 months
[JBoss JIRA] Created: (JBAS-3383) CMP field of type java.lang.Properties failes
by Ralf Zimmermann (JIRA)
CMP field of type java.lang.Properties failes
---------------------------------------------
Key: JBAS-3383
URL: http://jira.jboss.com/jira/browse/JBAS-3383
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CMP service
Affects Versions: JBossAS-4.0.4.GA
Environment: Platform independant.
Reporter: Ralf Zimmermann
Assigned To: Alexey Loubyansky
Access to an EJB CMP field of type java.lang.Properties fails with the following Exception:
12:10:56,240 ERROR [STDERR] Caused by: javax.ejb.EJBException: Load failed
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:251)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
12:10:56,240 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
12:10:56,240 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:520)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:954)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:430)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:65)
12:10:56,240 ERROR [STDERR] at $Proxy331.getId(Unknown Source)
12:10:56,240 ERROR [STDERR] at de.cit.intelliform.ejb.manager.ManagerBean.getBackendActionDTO(ManagerBean.java:2321)
12:10:56,240 ERROR [STDERR] at de.cit.intelliform.ejb.manager.ManagerBean.getActionDTO(ManagerBean.java:2410)
12:10:56,240 ERROR [STDERR] at de.cit.intelliform.ejb.manager.ManagerBean.getActionDTO(ManagerBean.java:2393)
12:10:56,240 ERROR [STDERR] at de.cit.intelliform.ejb.manager.ManagerBean.getActionDTO(ManagerBean.java:2361)
12:10:56,240 ERROR [STDERR] at de.cit.intelliform.ejb.manager.ManagerBean.getBackendActionDTO(ManagerBean.java:2331)
12:10:56,240 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
12:10:56,240 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
12:10:56,240 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
12:10:56,240 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
12:10:56,240 ERROR [STDERR] at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
12:10:56,240 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
12:10:56,255 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
12:10:56,255 ERROR [STDERR] at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:64)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
12:10:56,255 ERROR [STDERR] ... 67 more
12:10:56,255 ERROR [STDERR] Caused by: java.lang.IllegalStateException: Failed to find a ctor in class java.util.Properties that takes an instance of interface java.util.Map as an argument.
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeFactory.cloneValue(JDBCTypeFactory.java:308)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeFactory.access$000(JDBCTypeFactory.java:56)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeFactory$3.getFieldState(JDBCTypeFactory.java:105)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge$FieldState.updateState(JDBCCMP2xFieldBridge.java:443)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge$FieldState.setClean(JDBCCMP2xFieldBridge.java:431)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.setClean(JDBCCMP2xFieldBridge.java:262)
12:10:56,255 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:208)
12:10:56,255 ERROR [STDERR] ... 110 more
This is caused by an bug in org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeFactory. The CMPFieldStateFactory for the type java.lang.Map is also used for the CMP field of type java.lang.Properties.
This is wrong:There is no ctor java.lang.Properties(java.lang.Map).
Workaround: configure a custom CMPFieldStateFactory for the field.
--
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
17 years, 10 months