March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6801) Add proper support for Bundle uninstall

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-6801: ----------------------------------- Summary: Add proper support for Bundle uninstall Key: AS7-6801 URL: https://issues.jboss.org/browse/AS7-6801 Project: Application Server 7 Issue Type: Feature Request Components: OSGi, Server Reporter: Thomas Diesler Assignee: Thomas Diesler In OSGi Stops the bundle, destroys the BundleContext, prevents further starts and marks the bundle as "removal pending". Determine the usage count of the bundle classloader (i.e. number of wires to this bundle). Only if there is no active wire left the bundle can get removed from the Framework and the bundle class loader can get garbage collected. Until then, wires to the bundle stay active and resource/class loading continues to work as before. A bundle gets removed from the Framework automatically when the last dependency gets is marked as removal pending or if there is an explicit call to refresh the the wirings of the dependency closure (i.e. removal pending bundles are thrown out new wirings get established) In AS today Bundle uninstall causes an 'undeploy' management operation, which rolls back the deployment through all DUPs and removes it from the Framework. AS has no notion of "removal pending" or "in use" module. Due to the way deployment phase services have dependencies on phase services from other deployments, we get an undesired side effect of bundle deployments stopping/breaking if they have a dependency on an undeployed bundle. As mentioned above, dependecies should be limited to services but not on bundle lifecycle let alone break class loader dependencies. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-89) move examples maven modules to its own profile

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-89?page=com.atlassian.jira.plugin.... ] Geoffrey De Smet resolved DROOLS-89. ------------------------------------ Assignee: Geoffrey De Smet (was: Mark Proctor) Resolution: Rejected If drools-examples would be build in their own profile, then the developers and contributors will forget to compile them and they won't break very soon. Furthermore, we want to limit the number of maven profiles to exactly 3: default (relatively fast), full (includes docs and distro zips) and soa (for red hat productization). All other profiles are temporary hacks that we want to remove in time. This is because profiles heavily complexify the build as well as the use of the build. 2 years ago, before the build clean-up, we had dozens of profiles, no one knew what they did and a slow build. Simple is better. Sorry :/ > move examples maven modules to its own profile > ---------------------------------------------- > > Key: DROOLS-89 > URL: https://issues.jboss.org/browse/DROOLS-89 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Cristiano Gavião > Assignee: Geoffrey De Smet > Labels: maven > > When working with snapshot versions we need to do a 'mvn install' all the time. Building examples slowdown the building and I don't want to install examples into m2 local repository. > So, I would like to suggest to move the examples module to its own profile. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6086) Deadlock in org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6086?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6086: ---------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> made a comment on [bug 922339|https://bugzilla.redhat.com/show_bug.cgi?id=922339] The fix is present in 6.1.0.ER3. This bug is not marked as ON_QA, but I will close it anyway; if there are concerns, please add comments. > Deadlock in org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler > --------------------------------------------------------------------------------------- > > Key: AS7-6086 > URL: https://issues.jboss.org/browse/AS7-6086 > Project: Application Server 7 > Issue Type: Bug > Components: EJB, Remoting > Affects Versions: 7.1.3.Final (EAP) > Environment: Doesn't matter. > Reporter: Krzysztof Noceń > Assignee: Eduardo Martins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP) > > > Class: > {code} > org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler > {code} > Method: > {code} > public void processMessage(ChannelAssociation, MessageInputStream) throws IOException; > {code} > This code fragment: > {code} > try { > methodParams[i] = unmarshaller.readObject(); > } catch (ClassNotFoundException cnfe) { > /.../ > return; > } > {code} > doesn't catch *java.lang.IllegalArgumentException*. > This causes the server hangs. > Example stacktrace: > {code} > java.lang.IllegalArgumentException: No enum const org.example.ExampleEnum.ENUM_VALUE > at java.lang.Enum.valueOf(Enum.java:196) > at org.jboss.marshalling.river.RiverUnmarshaller.resolveEnumConstant(RiverUnmarshaller.java:1549) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1293) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:164) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:182) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:429) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > {code} > I caught *java.lang.Exception*. It helps. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6086) Deadlock in org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6086?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6086: ---------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 922339|https://bugzilla.redhat.com/show_bug.cgi?id=922339] from ASSIGNED to VERIFIED > Deadlock in org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler > --------------------------------------------------------------------------------------- > > Key: AS7-6086 > URL: https://issues.jboss.org/browse/AS7-6086 > Project: Application Server 7 > Issue Type: Bug > Components: EJB, Remoting > Affects Versions: 7.1.3.Final (EAP) > Environment: Doesn't matter. > Reporter: Krzysztof Noceń > Assignee: Eduardo Martins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP) > > > Class: > {code} > org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler > {code} > Method: > {code} > public void processMessage(ChannelAssociation, MessageInputStream) throws IOException; > {code} > This code fragment: > {code} > try { > methodParams[i] = unmarshaller.readObject(); > } catch (ClassNotFoundException cnfe) { > /.../ > return; > } > {code} > doesn't catch *java.lang.IllegalArgumentException*. > This causes the server hangs. > Example stacktrace: > {code} > java.lang.IllegalArgumentException: No enum const org.example.ExampleEnum.ENUM_VALUE > at java.lang.Enum.valueOf(Enum.java:196) > at org.jboss.marshalling.river.RiverUnmarshaller.resolveEnumConstant(RiverUnmarshaller.java:1549) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1293) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:164) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:182) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:429) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > {code} > I caught *java.lang.Exception*. It helps. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6800) Clean unreferenced deployments from the content repository

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6800?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6800: --------------------------------------- A possible simple solution to this is to pass the value of the "persistent" attribute from the deployment resource into the repo and use it to track non-persistent deployments and remove them when the content repo service stops. This is a bit dodgy though. It doesn't cover cases where the service isn't stopped during shutdown; e.g. a hard kill or where -Xrs is passed to the JVM thus disabling shutdown hook execution. The latter seems to be used in init.d scripts. (The MSC service container is stopped via a shutdown hook; it is that which causes services to stop.). A background process that periodically cleans unreferenced content may work better. > Clean unreferenced deployments from the content repository > ---------------------------------------------------------- > > Key: AS7-6800 > URL: https://issues.jboss.org/browse/AS7-6800 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-3694) Allow management client to associate metadata with DeploymentUnit

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-3694?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-3694: -------------------------------- Priority: Major (was: Critical) > Allow management client to associate metadata with DeploymentUnit > ----------------------------------------------------------------- > > Key: AS7-3694 > URL: https://issues.jboss.org/browse/AS7-3694 > Project: Application Server 7 > Issue Type: Feature Request > Components: OSGi, Server > Reporter: Thomas Diesler > Assignee: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > Currently there is no way to pass some metadata through the deployment API such that they could show up with the DU. > As a client I'd like to say autostart=false and in my DUP I'd like to pick that up and not start a deployment (i.e. a bundle) automatically > Generally it should be possible for the client to set some properties for the deployment in a generic way such that they get associated with the DeploymentUnit > For an OSGi deployment it would be necessary to be able to define that start behaviour and the start level. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4243) Required changes to deployment layer

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-4243?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved AS7-4243. --------------------------------- Resolution: Out of Date Out of Date > Required changes to deployment layer > ------------------------------------ > > Key: AS7-4243 > URL: https://issues.jboss.org/browse/AS7-4243 > Project: Application Server 7 > Issue Type: Task > Components: OSGi, Server > Reporter: Thomas Diesler > > This is the umbrella task for the following > #1 Allign deployment phases with bundle lifecyle. It should be possible for DUPs to operate on resolved bundles that have an associated Module > #2 Add start/stop lifecycle for deployments. Bundles as well as JSR88 deployments have the notion of start/stop > #3 Allow DUPs to operate on a set of deployments. It should be possible to deploy a set of bundles in arbitrary order. When all deployments in the set are installed - they can be resolved/started. > #4 Allow the management client to associate metadata with a deployment that can be seen by the DUPs. This is needed to be able to specify autostart behavior and a potential start level. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6800) Clean unreferenced deployments from the content repository

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6800: ------------------------------------- Summary: Clean unreferenced deployments from the content repository Key: AS7-6800 URL: https://issues.jboss.org/browse/AS7-6800 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) Reporter: Brian Stansberry Fix For: 8.0.0.Alpha1 The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1006) isSameRmOverride doesn't take effect

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1006?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1006: ------------------------------------------------ Jesper Pedersen <jpederse(a)redhat.com> made a comment on [bug 922793|https://bugzilla.redhat.com/show_bug.cgi?id=922793] PR78 sent > isSameRmOverride doesn't take effect > ------------------------------------ > > Key: JBJCA-1006 > URL: https://issues.jboss.org/browse/JBJCA-1006 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1004) Subject / security domain overrides null values from CRI for a datasource with allow-multiple-users

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1004?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1004: ------------------------------------------------ Jesper Pedersen <jpederse(a)redhat.com> made a comment on [bug 922793|https://bugzilla.redhat.com/show_bug.cgi?id=922793] PR78 sent > Subject / security domain overrides null values from CRI for a datasource with allow-multiple-users > --------------------------------------------------------------------------------------------------- > > Key: JBJCA-1004 > URL: https://issues.jboss.org/browse/JBJCA-1004 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > Attachments: JBJCA-1004-tests.patch, JBJCA-1004.patch > > > An issue cloned from JBPAPP6-1323 for the upstream. > DataSource configured with security-domain using org.picketbox.datasource.security.CallerIdentityLoginModule is able to create correct connection > when one of ds.getConection(username, password) is set to null. > Null parameter is substituted using value of corresponding field from the security-domain. > The datasource is defined using <allow-multiple-users/>. > See test org.jboss.as.test.integration.jca.security.DsWithCallerIdentityLoginModuleTestCase at https://github.com/pskopek/jboss-as/tree/JBPAPP-9583. -- 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, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2013