[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
12 years
[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
12 years
[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
12 years
[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
12 years
[JBoss JIRA] (JBRULES-3691) Property Reactive: using nested accessor in modify() seems to prevent the correct re-evaluation of the rules.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3691?page=com.atlassian.jira.plug... ]
Mario Fusco resolved JBRULES-3691.
----------------------------------
Fix Version/s: 6.0.0.Alpha2
Resolution: Done
I also fixed how settable properties are collected: now it also takes count of the properties mentioned in the @Modifies annotation, so it is no longer necessary to add an empty setter method as you did in your test case.
> Property Reactive: using nested accessor in modify() seems to prevent the correct re-evaluation of the rules.
> --------------------------------------------------------------------------------------------------------------
>
> Key: JBRULES-3691
> URL: https://issues.jboss.org/browse/JBRULES-3691
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-compiler, drools-core
> Affects Versions: 6.0.0.Alpha1
> Reporter: Esteban Aliverti
> Assignee: Mario Fusco
> Labels: property_reactive
> Fix For: 6.0.0.Alpha2
>
> Attachments: RuleNotBeingFired.zip
>
>
> The usage of nested accessors in modify() seems to prevent rules to be re-evaluated, or the re-evaluation result is not the expected one.
--
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
12 years
[JBoss JIRA] (AS7-6187) NullPointerException during SAR Service deployment
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6187?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins commented on AS7-6187:
--------------------------------------
[~kaising] What are you trying to accomplish with this code? Note that you're hacking Naming internals (WritableServiceBasedNamingStore pushOwner & popOwner), and that may be the cause for your issues.
> NullPointerException during SAR Service deployment
> --------------------------------------------------
>
> Key: AS7-6187
> URL: https://issues.jboss.org/browse/AS7-6187
> Project: Application Server 7
> Issue Type: Bug
> Components: Naming
> Affects Versions: 7.2.0.Alpha1
> Reporter: Guy Kaisin
> Assignee: Eduardo Martins
>
> Hi all,
> Still continuing to test/verify how to use mbean...
> Here is now how I implement the bind/rebind:
> <code>
> private void rebind() throws NamingException
> {
> InitialContext rootCtx = new InitialContext();
> Name fullName = rootCtx.getNameParser("").parse(getFullJndiName());
> ServiceName servName=ServiceName.parse(getFullJndiName());
> WritableServiceBasedNamingStore.pushOwner(servName);
> try
> {
> logger.info("fullName=" + fullName+" -> rebind ...");
> org.jboss.util.naming.NonSerializableFactory.rebind(fullName, sHelper, true);
> logger.info("fullName=" + fullName+" -> rebind ok");
> }
> catch(NamingException ex)
> { ex.printStackTrace(); throw ex; }
> finally
> { WritableServiceBasedNamingStore.popOwner(); }
> }
> </code>
> Like that, I don't have the 'context is read only' issue any more.
> But I get another exception...
> 13:54:54,997 INFO [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) fullName=java:global/mid/be.pos
> t.mid.dao.AddressDAO
> 13:54:55,012 INFO [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) fullName=java:global/mid/be.pos
> t.mid.dao.AddressDAO -> rebind ...
> 13:54:55,013 ERROR [stderr] (MSC service thread 1-2) javax.naming.NamingException: Failed to bind [Reference Class Name:
> be.post.common.servicelocator.helper.ServiceHelper
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) Type: nns
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) Content: java:global/mid/be.post.mid.dao.AddressDAO
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) ] at location [service jboss.naming.context.java.global.mid."be.pos
> t.mid.dao.AddressDAO"] [Root exception is java.lang.NullPointerException]
> 13:54:55,015 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.util.NamingUtils.namingException(NamingUt
> ils.java:151)
> 13:54:55,061 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(Writ
> ableServiceBasedNamingStore.java:80)
> 13:54:55,066 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(Wr
> itableServiceBasedNamingStore.java:95)
> 13:54:55,066 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:2
> 61)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.InitialContext.rebind(InitialContext.java
> :158)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:2
> 69)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at javax.naming.InitialContext.rebind(InitialContext.java:408)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerial
> izableFactory.java:185)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerial
> izableFactory.java:250)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at be.post.common.servicebinder.JndiBinder.rebind(JndiBinder.jav
> a:72)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at be.post.common.servicebinder.JndiBinder.startService(JndiBind
> er.java:52)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(Servi
> ceMBeanSupport.java:250)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSuppor
> t.java:158)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(Serv
> iceMBeanSupport.java:229)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSuppo
> rt.java:154)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.postRegister(ServiceMBea
> nSupport.java:364)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSuppor
> t.java:192)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postReg
> isterInvoke(DefaultMBeanServerInterceptor.java:1035)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rDynamicMBean(DefaultMBeanServerInterceptor.java:974)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rObject(DefaultMBeanServerInterceptor.java:917)
> 13:54:55,072 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rMBean(DefaultMBeanServerInterceptor.java:312)
> 13:54:55,072 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBean
> Server.java:482)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.reg
> isterMBean(PluggableMBeanServerImpl.java:551)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(Plugg
> ableMBeanServerImpl.java:319)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistra
> tionService.java:90)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startSe
> rvice(ServiceControllerImpl.java:1811)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(Ser
> viceControllerImpl.java:1746)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Thread
> PoolExecutor.java:886)
> 13:54:55,075 ERROR [stderr] (MSC service thread 1-2) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool
> Executor.java:908)
> 13:54:55,075 ERROR [stderr] (MSC service thread 1-2) at java.lang.Thread.run(Thread.java:662)
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) Caused by: java.lang.NullPointerException
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(Writ
> ableServiceBasedNamingStore.java:77)
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) ... 28 more
> 13:54:55,076 WARN [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) Starting failed mid.services.da
> o:service=AddressDAOMBean: javax.naming.NamingException: Failed to bind [Reference Class Name: be.post.common.serviceloc
> ator.helper.ServiceHelper
> Type: nns
> Content: java:global/mid/be.post.mid.dao.AddressDAO
> ] at location [service jboss.naming.context.java.global.mid."be.post.mid.dao.AddressDAO"] [Root exception is java.lang.N
> ullPointerException]
> at org.jboss.as.naming.util.NamingUtils.namingException(NamingUtils.java:151)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:80)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:95)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:261)
> at org.jboss.as.naming.InitialContext.rebind(InitialContext.java:158)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:269)
> at javax.naming.InitialContext.rebind(InitialContext.java:408) [rt.jar:1.6.0_25]
> at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:185)
> at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:250)
> at be.post.common.servicebinder.JndiBinder.rebind(JndiBinder.java:72)
> at be.post.common.servicebinder.JndiBinder.startService(JndiBinder.java:52)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:250)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:158)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:229)
> at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:154)
> at org.jboss.system.ServiceMBeanSupport.postRegister(ServiceMBeanSupport.java:364)
> at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSupport.java:192) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1
> 035) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java
> :974) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
> [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) [
> rt.jar:1.6.0_25]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) [rt.jar:1.6.0_25]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:551) [j
> boss-as-jmx-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:319) [jboss-as-jmx-7.2.
> 0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:90) [jboss-as-jmx-7.2.0.Alpha1-
> SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-ms
> c-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.G
> A.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_25]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_25]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:77)
> ... 28 more
> 13:54:55,087 ERROR [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) javax.naming.NamingException: F
> ailed to bind [Reference Class Name: be.post.common.servicelocator.helper.ServiceHelper
> Type: nns
> Content: java:global/mid/be.post.mid.dao.AddressDAO
> ] at location [service jboss.naming.context.java.global.mid."be.post.mid.dao.AddressDAO"] [Root exception is java.lang.N
> ullPointerException]
> I use a jboss-service.xml file, containing the following:
> <mbean name="mid.services.dao:service=AddressDAOMBean"
> code="be.post.common.servicebinder.DaoJndiBinder">
> <attribute name="JndiName">be.post.mid.dao.AddressDAO</attribute>
> <attribute name="DataSourceJndiName">java:MIDCoreOracleDS</attribute>
> <attribute name="InterfaceClass">be.post.mid.dao.AddressDAO</attribute>
> <attribute name="ImplementationClass">be.post.mid.dao.oracle.AddressOracle</attribute>
> </mbean>
> I could identify the line giving the exception:
> // add the service name to runtime bindings management service, which on stop releases the services.
> final Set<ServiceName> duBindingReferences = (Set<ServiceName> getServiceRegistry().getService(JndiNamingDependencyProcessor.serviceName(deploymentUnitServiceName)).getValue();
> But what is the root cause of it?
> any suggestion?
> thanks a lot...
--
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
12 years
[JBoss JIRA] (AS7-5331) @Resource UserTransaction should not be allowed in CMT beans
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-5331?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins reassigned AS7-5331:
------------------------------------
Assignee: Eduardo Martins (was: jaikiran pai)
> @Resource UserTransaction should not be allowed in CMT beans
> ------------------------------------------------------------
>
> Key: AS7-5331
> URL: https://issues.jboss.org/browse/AS7-5331
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Dominik Pospisil
> Assignee: Eduardo Martins
>
> Currently, it seems then @Resource UserTransaction injection is allowed in CMT beans and injects
> container managed transaction. In AS/EAP5 this would throw an exception which I think is correct as
> this violates EJB 3.0 & 3.1 specs.
> Section 16.12 of the EJB 3.1 specification says:
> The container must make the UserTransaction interface available to the enterprise beans that are
> allowed to use this interface (only session and message-driven beans with bean-managed transaction
> demarcation are allowed to use this interface) either through injection using the Resource annotation
> or in JNDI under the name java:comp/UserTransaction, in addition to through the EJBContext
> interface. The authenticationType and shareable elements of the Resource annotation
> must not be specified.
> In my interpretation the statement "only session and message-driven beans with bean-managed transaction
> demarcation are allowed to use this interface" would mean that other beans are prohibited to use this
> interface. Allowing such beans to use this interface is specification violation.
--
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
12 years