[JBoss JIRA] (AS7-6396) EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created AS7-6396:
-------------------------------------
Summary: EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
Key: AS7-6396
URL: https://issues.jboss.org/browse/AS7-6396
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.3.Final (EAP)
Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
Reporter: Wolf-Dieter Fink
Assignee: Wolf-Dieter Fink
If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
Caused by: java.lang.NullPointerException
at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
... 82 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6395) EJB2 CMP - no entity-bean instance pool configured in *full* profiles with cmp
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created AS7-6395:
-------------------------------------
Summary: EJB2 CMP - no entity-bean instance pool configured in *full* profiles with cmp
Key: AS7-6395
URL: https://issues.jboss.org/browse/AS7-6395
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.3.Final (EAP)
Reporter: Wolf-Dieter Fink
Assignee: Wolf-Dieter Fink
Priority: Minor
The ejb3 subsystem does not configure entity-bean.bean-instance-pool.
In that case the CMP subsystem must create a instance for each entity if it is used.
This might be a performance issue (instantiation and GC), also the setContext/unsetContext methods must be called.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBRULES-3675) java.lang.LinkageError, but only sometimes (multithreading issue)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3675?page=com.atlassian.jira.plug... ]
Mario Fusco resolved JBRULES-3675.
----------------------------------
Resolution: Done
> java.lang.LinkageError, but only sometimes (multithreading issue)
> -----------------------------------------------------------------
>
> Key: JBRULES-3675
> URL: https://issues.jboss.org/browse/JBRULES-3675
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final
> Environment: - JBoss 7.1.1
> - drools 5.4.0.Final
> - jdk 1.6u30
> - Windows 7 64 bit
> Reporter: kenneth westelinck
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> See mail on mailinglist:
> {noformat}
> We have an application (A) deployed on JBoss 7.1.1 accepting commands (CQRS,
> but only C and Q :) ). A console application (B) is sending a large volume
> of commands to create entities in A. Entities in A are validated by Drools
> (plain drl files, configured in spring using drools-spring). Most of the
> time this works just fine. But sometimes, we get the following exception:
> java.lang.LinkageError: loader (instance of
> org/drools/rule/JavaDialectRuntimeData$PackageClassLoader): attempted
> duplicate class definition for name:
> "a/b/c/Rule_person_unique___name_656ee3db19d34e689d95e2d6b2be67b6"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_30]
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:615) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:254) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_30]
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0InvokerGenerated.evaluate(Unknown Source)
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> Any idea where this is coming from or what's causing this.
> {noformat}
> And the answer:
> {noformat}
> I have never experienced this myself, but after having a quick look at the code I believe this could be a multi-threading problem.
> In the abstract class java.lang.ClassLoader the method loadClass(String, boolean) is synchronized, but both org.drools.util.CompositeClassLoader
> and org.drools.rule.JavaDialectRuntimeData$PackageClassLoader override this method without the use of "synchronized".
> I would suggest you create a JIRA issue for this.
> {noformat}
> We are now trying 5.5.0.CR1 and so far, we have not encountered this issue. I'll keep you posted should the same issue appear on 5.5.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated AS7-6334:
-----------------------------
Description:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups (OK)
clustering/infinispan
cmp - PR sent https://github.com/jbossas/jboss-as/pull/3792
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner
ee
ejb3 [OK]
jacorb - Just a note: the 'security' attribute transformation is not tested
jaxr OK
jaxrs - nothing to do, empty subsystem
jdr - nothing to do, empty subsystem
jmx (OK)
jpa (OK)
jsf [PR https://github.com/jbossas/jboss-as/pull/3925]
jsr77 - nothing to do, empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail
messaging [OK]
modcluster
naming [PR https://github.com/jbossas/jboss-as/pull/3910]
osgi (OK)
pojo - nothing to do, empty subsystem
remoting - [OK]
sar - nothing to do, empty subsystem
security PR sent - https://github.com/jbossas/jboss-as/pull/3941
threads
transactions (just needs AS7-6336)
web
webservices
weld - nothing to do, empty subsystem
xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3
was:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups (OK)
clustering/infinispan
cmp
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner
ee
ejb3 [OK]
jacorb - Just a note: the 'security' attribute transformation is not tested
jaxr OK
jaxrs - nothing to do, empty subsystem
jdr - nothing to do, empty subsystem
jmx (OK)
jpa (OK)
jsf [PR https://github.com/jbossas/jboss-as/pull/3925]
jsr77 - nothing to do, empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail
messaging [OK]
modcluster
naming [PR https://github.com/jbossas/jboss-as/pull/3910]
osgi (OK)
pojo - nothing to do, empty subsystem
remoting - [OK]
sar - nothing to do, empty subsystem
security
threads
transactions (just needs AS7-6336)
web
webservices
weld - nothing to do, empty subsystem
xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3
> Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6334
> URL: https://issues.jboss.org/browse/AS7-6334
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.2.0.Alpha1
>
>
> Task to track the work we've all been doing on expressions/transformers.
> See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
> 1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
> 2) Basic transformation testing against 7.1.2 and 7.1.3
> 3) Reject-expression testing against 7.1.2 and 7.1.3
> Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
> Please edit this description and put an OK after the subsystem name to indicate it's good to go.
> clustering/jgroups (OK)
> clustering/infinispan
> cmp - PR sent https://github.com/jbossas/jboss-as/pull/3792
> configadmin [OK]
> connector/datasource
> connector/jca [OK]
> connector/resource-adapter
> deployment-scanner
> ee
> ejb3 [OK]
> jacorb - Just a note: the 'security' attribute transformation is not tested
> jaxr OK
> jaxrs - nothing to do, empty subsystem
> jdr - nothing to do, empty subsystem
> jmx (OK)
> jpa (OK)
> jsf [PR https://github.com/jbossas/jboss-as/pull/3925]
> jsr77 - nothing to do, empty subsystem
> logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
> mail
> messaging [OK]
> modcluster
> naming [PR https://github.com/jbossas/jboss-as/pull/3910]
> osgi (OK)
> pojo - nothing to do, empty subsystem
> remoting - [OK]
> sar - nothing to do, empty subsystem
> security PR sent - https://github.com/jbossas/jboss-as/pull/3941
> threads
> transactions (just needs AS7-6336)
> web
> webservices
> weld - nothing to do, empty subsystem
> xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6083) ConcurrentModificationException in ConfigAdminService
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6083?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler reassigned AS7-6083:
-----------------------------------
Assignee: Thomas Diesler
> ConcurrentModificationException in ConfigAdminService
> -----------------------------------------------------
>
> Key: AS7-6083
> URL: https://issues.jboss.org/browse/AS7-6083
> Project: Application Server 7
> Issue Type: Bug
> Components: ConfigAdmin, OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> {code}
> 12:07:46,616 ERROR [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011026: Framework Error: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:110) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:167)
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:522) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.DefaultStartLevelPlugin.increaseStartLevel(DefaultStartLevelPlugin.java:265) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.FrameworkActive.start(FrameworkActive.java:131) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373) [rt.jar:1.6.0_37]
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:384) [rt.jar:1.6.0_37]
> at org.jboss.as.configadmin.service.ConfigAdminServiceImpl.addListener(ConfigAdminServiceImpl.java:249)
> at org.jboss.as.osgi.configadmin.DomainModelPersistenceManager.start(DomainModelPersistenceManager.java:68)
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:84) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5083) Complete support for OSGi webapps in JBossWeb
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5083?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-5083:
--------------------------------
Fix Version/s: (was: 7.2.0.CR1)
Priority: Major (was: Critical)
> Complete support for OSGi webapps in JBossWeb
> ---------------------------------------------
>
> Key: AS7-5083
> URL: https://issues.jboss.org/browse/AS7-5083
> Project: Application Server 7
> Issue Type: Feature Request
> Components: OSGi
> Reporter: Thomas Diesler
> Attachments: webapp-1.0.pdf
>
>
> Following initial support for WAB please review the spec and implement missing functionality.
> h5. 128.3.1 WAB Definition
> The web.xml must be found with the Bundle findEntries method. The findEntries method includes fragments, allowing the web.xml to be provided by a fragment.
> h5. 128.3.2 Starting the Web Application Bundle
> The Web Extender should ensure that serving static content from the WAB does not activate the WAB when it has a lazy activation policy.
> Validate that the Web-ContextPath manifest header does not match the Context Path of any other currently deployed web application.
> h5. 128.3.4 Publishing the Servlet Context
> The Web Extender must register the Servlet Context of the WAB as a service, using the Bundle Context of the WAB.
> h5. 128.3.5 Static Content
> For confidentiality reasons, a Web Runtime must not return any static content for paths that start with one of the following prefixes:
> WEB-INF/
> OSGI-INF/
> META-INF/
> OSGI-OPT/
> h5. 128.3.8 Stopping the Web Application Bundle
> It is possible that there are one or more colliding WABs because they had the same Context Path as this stopped WAB. If such colliding WABs exists then the Web Extender must attempt to deploy the colliding WAB with the lowest bundle id.
> h5. 128.5 Events
> * org/osgi/service/web/DEPLOYING The Web Extender has accepted a WAB and started the process of deploying a Web Application.
> * org/osgi/service/web/DEPLOYED The Web Extender has finished deploying a Web Application, and the Web Application is now available for web requests on its Context Path.
> * org/osgi/service/web/UNDEPLOYING The web extender started undeploying the Web Application in response to its corresponding WAB being stopped or the Web Extender is stopped.
> * org/osgi/service/web/UNDEPLOYED The Web Extender has undeployed the Web Application. The application is no longer available for web requests.
> * org/osgi/service/web/FAILED The Web Extender has failed to deploy the Web Application, this event can be fired after the DEPLOYING event has fired and indicates that no DEPLOYED event will be fired.
> h5. 128.6.1 Bundle Context Access
> A Servlet can obtain a Bundle Context as follows:
> {code}
> BundleContext ctxt = (BundleContext)
> servletContext.getAttribute(osgi-bundlecontext);
> {code}
> h5. 128.6.3 Resource Lookup
> The getResource and getResourceAsStream methods of the ServletContext interface are used to access resources in the web application. For a WAB, these resources must be found according to the findEntries method, this method includes fragments.
> The getResourcePaths method must map to the Bundle getEntryPaths method, its return type is a Set and can not handle multiples. However, the paths from the getEntryPaths method are relative while the methods of the getResourcePaths must be absolute.
> h5. 128.6.5 JavaServer Pages Support
> The Web Runtime can construct a special class loader to load generated JSP
> classes such that classes from the bundle class path are visible to newly compiled JSP classes.
> This issue is complete when the TCK passes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBASPECT-39) java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/JBASPECT-39?page=com.atlassian.jira.plugi... ]
Tom Ross updated JBASPECT-39:
-----------------------------
Steps to Reproduce:
To reproduce the problem convert a JBoss EAP instance to JTS transactions.
Fire a timer that runs longer than the default transaction timeout. Wait until transaction times out and is rolled back. Then wait until the time finishes. You should see the exception then.
> java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBASPECT-39
> URL: https://issues.jboss.org/browse/JBASPECT-39
> Project: JBoss Aspects
> Issue Type: Bug
> Environment: JBoss EAP 5.1.2
> Reporter: Tom Ross
> Assignee: Andrew Rubinger
>
> When a timer runs longer than a transaction timeout it throws an exception:
> {noformat}
> 2013-01-25 15:06:34,613 ERROR [org.jboss.ejb.txtimer.TimerImpl] (EJB-Timer-144eac73-8911-4bf7-ab78-7ac081374794[target=jboss.j2ee:ear=XX_TEST_CASE.ear,jar=XX_TEST_CASE_EJB.jar,name=TXTimerBean,service=EJB3]) Error invoking ejbTimeout
> java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >, actual TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >
> at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:157)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:686)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:202)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerBridge.callTimeout(TimedObjectInvokerBridge.java:44)
> at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:664)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBASPECT-39) java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
by Tom Ross (JIRA)
Tom Ross created JBASPECT-39:
--------------------------------
Summary: java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
Key: JBASPECT-39
URL: https://issues.jboss.org/browse/JBASPECT-39
Project: JBoss Aspects
Issue Type: Bug
Environment: JBoss EAP 5.1.2
Reporter: Tom Ross
Assignee: Andrew Rubinger
When a timer runs longer than a transaction timeout it throws an exception:
{noformat}
2013-01-25 15:06:34,613 ERROR [org.jboss.ejb.txtimer.TimerImpl] (EJB-Timer-144eac73-8911-4bf7-ab78-7ac081374794[target=jboss.j2ee:ear=XX_TEST_CASE.ear,jar=XX_TEST_CASE_EJB.jar,name=TXTimerBean,service=EJB3]) Error invoking ejbTimeout
java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >, actual TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:157)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:686)
at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:202)
at org.jboss.as.ejb3.timerservice.TimedObjectInvokerBridge.callTimeout(TimedObjectInvokerBridge.java:44)
at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:664)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBRULES-3669) Bug when using two knowledge bases and one declarative model between
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3669?page=com.atlassian.jira.plug... ]
Mario Fusco resolved JBRULES-3669.
----------------------------------
Resolution: Rejected
This is not a bug: the correct way to do that is to make the 2 KnowledgeBases to share the same ClassLoader.
> Bug when using two knowledge bases and one declarative model between
> --------------------------------------------------------------------
>
> Key: JBRULES-3669
> URL: https://issues.jboss.org/browse/JBRULES-3669
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-compiler
> Affects Versions: 5.4.0.Final
> Reporter: Jackson Cunha
> Assignee: Mario Fusco
>
> Hello conrads.
> To explain what I need, the problem that I found and the solution that I planning to use, I will firstly describe my cenario.
> Cenario
> In my cenario, I have a declarative model and rules of different groups. I need put each rules group in a different knowledge base and all of it will share the same declarative model.
> In a time, I will create a fact using fact types defined in a knowledge base that I will call as kbaseModel. This knowledge base will have only the declarative model and no rules.
> All facts created will be used in other knowledge base, called kbaseRules. All kbaseRules have only rules and no declarative model, because model was defined in kbaseModel.
> I could have many kbaseRules but exists only one kbaseModel.
> Using the Drools API, teoricaly, I could implement my cenario using the following code:
> //DRL for resourceModel
> declare MyEntity
> name : String
> end
> //DRL for resourceRules
> rule "Simple Rule"
> when
> $entity: MyEntity()
> then
> System.out.println($entity)
> end
> Resource resourceModel = ... //Resource with only the declarative model and no rules
> Resource resourceRules = ... //Resource with only rules and no declarative model
> KnowledgeBuilder kbuilderModel = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilderModel add(resourceModel, ResourceType.DRL);
> KnowledgeBase kbaseModel = kbuilderModel.newKnowledgeBase();
> KnowledgeBuilder kbuilderRules = KnowledgeBuilderFactory.newKnowledgeBuilder(kbaseModel);
> kbuilderRules.add(resourceRules, ResourceType.DRL);
> KnowledgeBase kbaseRules = KnowledgeBaseFactory.newKnowledgeBase();
> kbaseRules.addKnowledgePackages(kbuilderRules.getKnowledgePackages());
> FactType factType = kbaseModel.getFactType("mymodel", "MyEntity");
> Object myEntity = factType.newInstance();
> factType.set(myEntity, "name", "Jackson Cunha Cassimiro");
> StatelessKnowledgeSession session = kbaseRules.newStatelessKnowledgeSession();
> session.execute(myEntity);
> This code should work, but when I try to run I get this stacktrace:
> java.lang.ClassNotFoundException: Unable to load class: mymodel.MyEntity
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:92)
> at org.drools.common.AbstractRuleBase.registerAndLoadTypeDefinition(AbstractRuleBase.java:649)
> at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:553)
> at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
> at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:150)
> at app.UsingDeclares.main(UsingDeclares.java:79)
> Exception in thread "main" org.drools.RuntimeDroolsException: unable to resolve Type Declaration class 'mymodel.MyEntity'
> at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:582)
> at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
> at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:150)
> at app.UsingDeclares.main(UsingDeclares.java:79)
> It happens because Drools can't find any reference of mymodel.MyEntity in kbaseRules, but this kbase was built from kbaseModel that already have this class declared. I think it can be a bug.
> Debuging
> During creation of kbaseModel, a method called mergePackage(pkgRegistry, packageDescr) from PackageBuilder class is invoked. The pkgRegistry not contains any reference to declarative model. The packageDescr contains a list of type definitions from declarative model. Inside mergePackage is invoked other method, called processTypeDeclarations(pkgRegistry, packageDescr) that will iterate over all type definitions from packageDescr and will fill a map called Map<String,byte[]> classLookups from JavaDialectRuntimeData class.
> During the creation of kbaseRules the method mergePackage(pkgRegistry, packageDescr) from PackageBuilder is invoked again, but at this time pkgRegistry contains all type definitions defined previously in kbaseModel and packageDescr not contains any type definitions, only rules. When the method processTypeDeclarations(pkgRegistry, packageDescr) from PackageBuilder is called and try iterate over type definitions of packageDescr, this is empty and nothing is done and the map Map<String,byte[]> classLookups from JavaDialectRuntimeData will be empty too.
> The classLookups empty is the cause of ClassNotFoundException.
> Solution
> The solution that I found was apply reflection to fill Map<String,byte[]> classLookups from JavaDialectRuntimeData correctly before add the packages into kbaseRules:
> Collection<KnowledgePackage> packages = kbuilderRules.getKnowledgePackages();
> Mirror mirror = new Mirror();//Reflection utilities
>
> for (KnowledgePackage kPackage : packages) {
> Package pkg = (Package) mirror.on(kPackage).get().field("pkg");
> JavaDialectRuntimeData dialect = (JavaDialectRuntimeData) pkg.getDialectRuntimeRegistry().getDialectData( "java" );
>
> for (FactType factType : kPackage.getFactTypes()) {
> Class<?> c = factType.getFactClass();
> String className = c.getName();
> String classAsPath = className.replace('.', '/') + ".class";
> InputStream stream = c.getClassLoader().getResourceAsStream(classAsPath);
> byte[] bytes = IOUtils.toByteArray(stream);
> dialect.putClassDefinition(classAsPath, bytes);
> }
> }
> KnowledgeBase kbaseRules = KnowledgeBaseFactory.newKnowledgeBase();
> kbaseRules.addKnowledgePackages(packages);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months