[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
[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
[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
[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
[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
[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
[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
[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