April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6966) Class-Path manifest entries for WARs-in-EAR not handled properly

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-6966?page=com.atlassian.jira.plugin.s... ] Stuart Douglas reassigned AS7-6966: ----------------------------------- Assignee: Stuart Douglas (was: Jason Greene) > Class-Path manifest entries for WARs-in-EAR not handled properly > ---------------------------------------------------------------- > > Key: AS7-6966 > URL: https://issues.jboss.org/browse/AS7-6966 > Project: Application Server 7 > Issue Type: Bug > Components: Server > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: James Livingston > Assignee: Stuart Douglas > > ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken. > https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml > The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader. > When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR. > When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run. > I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader. -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6966) Class-Path manifest entries for WARs-in-EAR not handled properly

by James Livingston (JIRA)

James Livingston created AS7-6966: ------------------------------------- Summary: Class-Path manifest entries for WARs-in-EAR not handled properly Key: AS7-6966 URL: https://issues.jboss.org/browse/AS7-6966 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) Reporter: James Livingston Assignee: Jason Greene ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken. https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader. When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR. When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run. I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader. -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6960) Injection failure in an ejb's superclass when superclass is loaded from a jboss module

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-6960?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-6960: ----------------------------------- Also, see this thread https://community.jboss.org/thread/201765 and the other linked threads in there, for an example. > Injection failure in an ejb's superclass when superclass is loaded from a jboss module > -------------------------------------------------------------------------------------- > > Key: AS7-6960 > URL: https://issues.jboss.org/browse/AS7-6960 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.1.Final > Reporter: Andrei Serea > Assignee: jaikiran pai > Attachments: ejbmoduledep_testcase.zip, jboss_module.zip > > -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6960) Injection failure in an ejb's superclass when superclass is loaded from a jboss module

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-6960?page=com.atlassian.jira.plugin.s... ] Stuart Douglas resolved AS7-6960. --------------------------------- Resolution: Rejected You need to pre-index the module using the jandex ant task, and then import the annotations as described here: https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7 > Injection failure in an ejb's superclass when superclass is loaded from a jboss module > -------------------------------------------------------------------------------------- > > Key: AS7-6960 > URL: https://issues.jboss.org/browse/AS7-6960 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.1.Final > Reporter: Andrei Serea > Assignee: jaikiran pai > Attachments: ejbmoduledep_testcase.zip, jboss_module.zip > > -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6849) ClassLoader memory leak with MDB

by Vlad Arkhipov (JIRA)

[ https://issues.jboss.org/browse/AS7-6849?page=com.atlassian.jira.plugin.s... ] Vlad Arkhipov commented on AS7-6849: ------------------------------------ It seems that the problem is in [https://github.com/jbossas/jboss-threads/blob/master/src/main/java/org/jb...]. createThread() creates new threads using creator's thread context class loader (it's incorrect, isn't it? should it use worker's class loader instead?). The simplest way to fix it is adding {code}thread.setContextClassLoader(null);{code} This issue also may be related to https://issues.jboss.org/browse/JBTHR-20 > ClassLoader memory leak with MDB > -------------------------------- > > Key: AS7-6849 > URL: https://issues.jboss.org/browse/AS7-6849 > Project: Application Server 7 > Issue Type: Bug > Components: JCA > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Vlad Arkhipov > Assignee: Stefano Maestri > Priority: Critical > Attachments: leak.tar.gz > > > There are still some references to MDB class (NOT to the *instance*) if you undeploy an archive from the AS. Sooner or later it leads to OutOfMemory Permgen exception after multiple redeployments. -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6965) Expose webservices endpoint metrics in console

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/AS7-6965?page=com.atlassian.jira.plugin.s... ] Alessio Soldano updated AS7-6965: --------------------------------- Summary: Expose webservices endpoint metrics in console (was: Provide webservices endpoint metrics within console) > Expose webservices endpoint metrics in console > ---------------------------------------------- > > Key: AS7-6965 > URL: https://issues.jboss.org/browse/AS7-6965 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console, Web Services > Reporter: Alessio Soldano > Assignee: Heiko Braun > Fix For: 8.0.0.Alpha1 > > > The Status->Subsystems->Webservices section of the Runtime area of the console contains basic info regarding deployed ws endpoints. It does not currently use all the available information for each of them in the model (e.g. [1]), in particular the metrics are missing and should really be added to the console (average-processing-time, fault-count, max-processing-time, min-processing-time, request-count, response-count, total-processing-time) > [1] /deployment=foo.war/subsystem=webservices/endpoint=foo-ep -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6965) Provide webservices endpoint metrics within console

by Alessio Soldano (JIRA)

Alessio Soldano created AS7-6965: ------------------------------------ Summary: Provide webservices endpoint metrics within console Key: AS7-6965 URL: https://issues.jboss.org/browse/AS7-6965 Project: Application Server 7 Issue Type: Feature Request Components: Console, Web Services Reporter: Alessio Soldano Assignee: Heiko Braun Fix For: 8.0.0.Alpha1 The Status->Subsystems->Webservices section of the Runtime area of the console contains basic info regarding deployed ws endpoints. It does not currently use all the available information for each of them in the model (e.g. [1]), in particular the metrics are missing and should really be added to the console (average-processing-time, fault-count, max-processing-time, min-processing-time, request-count, response-count, total-processing-time) [1] /deployment=foo.war/subsystem=webservices/endpoint=foo-ep -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-6833) JSR-196 JASPIC 1.1 Support

by arjan tijms (JIRA)

[ https://issues.jboss.org/browse/AS7-6833?page=com.atlassian.jira.plugin.s... ] arjan tijms commented on AS7-6833: ---------------------------------- About the new JASPIC 1.1 feature where a SAM can indicate it wants the container to establish an authentication session: The spec is not entirely clear on this, but in an email exchange with Ron Monzillo I got some explanations, which may be useful to share. I've added them to a blog article about this feature here: http://arjan-tijms.blogspot.com/2013/04/whats-new-in-java-ee-7s-authentic... See also: https://java.net/jira/browse/GLASSFISH-20317 Note that this new feature may require some extra attention for the JBoss implementation, since JBoss is already remembering the authenticated identity without the SAM asking for it, and without the SAM being asked to re-authenticate (which I think is not entirely spec compliant). > JSR-196 JASPIC 1.1 Support > -------------------------- > > Key: AS7-6833 > URL: https://issues.jboss.org/browse/AS7-6833 > Project: Application Server 7 > Issue Type: Sub-task > Components: Security > Reporter: David Lloyd > Assignee: Stefan Guilhen > Fix For: 8.0.0.Alpha1 > > > Provide support for the 1.1 maintenance release of JASPIC. > http://jcp.org/aboutJava/communityprocess/maintenance/jsr196/196ChangeLog... -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-78) NullPointerException in windows eviction

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-78?page=com.atlassian.jira.plugin.... ] Davide Sottara commented on DROOLS-78: -------------------------------------- Even if your logic was wrong, it shouldn't have turned out as an exception :) I have submitted a tentative patch for DROOLS-106 - to be reviewed by the drools team - here: https://github.com/sotty/drools/commit/c949ef0195ad174fadae6369985fa17d46... which may fix issues like the NPE on RightTupleIndexHashTable.remove(..) I hope that this will be fixed officially early next week > NullPointerException in windows eviction > ---------------------------------------- > > Key: DROOLS-78 > URL: https://issues.jboss.org/browse/DROOLS-78 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Radai Rosenblatt > Assignee: Mark Proctor > Priority: Blocker > Attachments: droolsIssue.zip > > > when writing a (fusion) rule with a length window and inserting more events than the window size drools produces a null pointer exception on the 1st event over the window size. > the exception produced is: > java.lang.NullPointerException > at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363) > at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318) > at org.drools.rule.SlidingLengthWindow.assertFact(SlidingLengthWindow.java:116) > at org.drools.rule.BehaviorManager.assertFact(BehaviorManager.java:94) > at org.drools.reteoo.WindowNode.assertObject(WindowNode.java:167) > at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) > at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) > at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55) > a similar exception happens when the rule is re-written to use a time window (and the test updated to overflow that window): > org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction@1dc39fc3 > at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:995) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:335) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55) > at TestBug2.testBug(TestBug2.java:96) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76) > at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: java.lang.NullPointerException > at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363) > at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318) > at org.drools.rule.SlidingTimeWindow.expireFacts(SlidingTimeWindow.java:189) > at org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction.execute(SlidingTimeWindow.java:471) > at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:993) > ... 31 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6771) Undefining attribute socket-binding or re-creating management interface leads to BindException: Address already in use

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6771?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved AS7-6771. ----------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 8.0.0.CR1) Resolution: Out of Date I can no longer reproduce this, so it looks like some change since 7.1.2 eliminated the problem. > Undefining attribute socket-binding or re-creating management interface leads to BindException: Address already in use > ---------------------------------------------------------------------------------------------------------------------- > > Key: AS7-6771 > URL: https://issues.jboss.org/browse/AS7-6771 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Akram Ben Aissi > Assignee: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > 1 - Assign a secure-socket-binding to management-interface=management-http: > {code} /core-service=management/management-interface=http-interface:write-attribute(name="secure-socket-binding", value="management-https") > {code} > 2- Try to remove the socket-binding (the HTTP one) > {code} > /core-service=management/management-interface=http-interface:undefine-attribute(name="socket-binding") > {code} > You receive an error: > {code} { > "outcome" => "failed", > "failure-description" => {"JBAS014671: Failed services" => {"jboss.serverManagement.controller.management.http" => "org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Address already in use /10.104.68.140:9990 > Caused by: java.net.BindException: Address already in use"}}, > "rolled-back" => true > } > {code} > if you try to affect another socket binding, and then remove it, it works: > {code} > [standalone@10.104.68.140:9999 /] /core-service=management/management-interface=http-interface:add(socket-binding=management-http2) > {"outcome" => "success"} > {code} > Also deleting the whole management-http interface and recreating fails with the same error -- 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

11 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2013