[JBoss JIRA] (AS7-3694) Allow management client to associate metadata with DeploymentUnit
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-3694?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated AS7-3694:
--------------------------------------
Forum Reference: https://community.jboss.org/message/782610#782610
> 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: Thomas Diesler
> Priority: Critical
> Fix For: 7.2.0.CR1
>
>
> 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
12 years
[JBoss JIRA] (AS7-6234) WAB deployment showing as successful, but not responding
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6234?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler closed AS7-6234.
-------------------------------
Assignee: Thomas Diesler (was: Jean-Frederic Clere)
Fix Version/s: (was: 7.2.0.CR1)
Resolution: Rejected
Thanks. Rejecting - seems to be a spring issue
> WAB deployment showing as successful, but not responding
> --------------------------------------------------------
>
> Key: AS7-6234
> URL: https://issues.jboss.org/browse/AS7-6234
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: Thomas Diesler
> Attachments: jboss-7.2.0-server-output-deployment-showing-as-successful.txt, server.springapp.log, spring-app-1.0.0-BUILD-SNAPSHOT-looks-to-start-normally-but-doesnt.war, spring-app-1.0.0-BUILD-SNAPSHOT-no-manifest-works.war, spring-app-source-codes.zip
>
>
> Simple Spring WAB file, that I think should work, doesn't seem to. Deployment goes seemingly without issues - no errors are reported - but servlet does not respond to requests. Both OSGi panel and deployment management panel in admin console show the deployment as successful.
> Attached server output and .war file, that should respond to /spring-app request.
--
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] (JBWEB-257) Filter.destroy() exceptions break application undeployment
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBWEB-257?page=com.atlassian.jira.plugin.... ]
Jean-Frederic Clere commented on JBWEB-257:
-------------------------------------------
r2129 is the fix for trunk.
> Filter.destroy() exceptions break application undeployment
> ----------------------------------------------------------
>
> Key: JBWEB-257
> URL: https://issues.jboss.org/browse/JBWEB-257
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: JBossWeb-2.1.12.GA
> Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2 and earlier
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: destroy-linkage-error.war
>
>
> JBoss does not handle any exceptions from custom Filter.destroy() implementations. This is passed on to the JBoss container and disrupts the
> undeployment so the app is not successfully undeployed.
> That causes a potentially critical issue as the application is no longer deployed at that point, but it can't be redeployed due to conflicts with the prior incomplete undeployment. The server has to be restarted to be able to deploy the application again.
> The broken undeployment could be fixed at the container level if org.apache.catalina.core.ApplicationFilterConfig.release() caught exceptions thrown by Filter.destroy()
--
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-6238) Deadlock in Module FallbackClassLoader
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6238?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-6238:
-------------------------------------
Should be fixed in jbosgi-framework-2.1.0.CR9
> Deadlock in Module FallbackClassLoader
> --------------------------------------
>
> Key: AS7-6238
> URL: https://issues.jboss.org/browse/AS7-6238
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Steve Reed
> Assignee: Thomas Diesler
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
> Attachments: jboss-dead-lock.txt, ThreadDump-2.txt
>
>
> Actually the version is 2.0.1.final - jbosgi-framework-core-2.0.1.Final.jar
> Commit reference for JBOSS AS :- https://github.com/jbossas/jboss-as/commit/ed2bc551a55ec6a8167a8657cbb5d8...
> During start up of JBOSS AS7.0 two GeminiBlueprintExtender Threads deadlock, and services in the JBOSS OSGI container are not started.
> The deadlock appears to be concerned with a Module FallbackLoader, which acquires a lock during a call to loadClassLocal() and then proceeds to use an alternate Module to load the class, if this results in the alternate Module using it's FallbackLoader to load a class or resource, then it must also acquire a lock first. Obviously if two or more threads are attempting this, then a dead lock is possible.
> I will attach the thread dump to this issue as supporting evidence.
--
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-6238) Deadlock in Module FallbackClassLoader
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6238?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler moved JBOSGI-623 to AS7-6238:
--------------------------------------------
Project: Application Server 7 (was: JBoss OSGi)
Key: AS7-6238 (was: JBOSGI-623)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: OSGi
(was: Core Framework)
Security: (was: Public)
Fix Version/s: 7.2.0.Alpha1
(was: JBossOSGi 1.2.0)
> Deadlock in Module FallbackClassLoader
> --------------------------------------
>
> Key: AS7-6238
> URL: https://issues.jboss.org/browse/AS7-6238
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Steve Reed
> Assignee: Thomas Diesler
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
> Attachments: jboss-dead-lock.txt, ThreadDump-2.txt
>
>
> Actually the version is 2.0.1.final - jbosgi-framework-core-2.0.1.Final.jar
> Commit reference for JBOSS AS :- https://github.com/jbossas/jboss-as/commit/ed2bc551a55ec6a8167a8657cbb5d8...
> During start up of JBOSS AS7.0 two GeminiBlueprintExtender Threads deadlock, and services in the JBOSS OSGI container are not started.
> The deadlock appears to be concerned with a Module FallbackLoader, which acquires a lock during a call to loadClassLocal() and then proceeds to use an alternate Module to load the class, if this results in the alternate Module using it's FallbackLoader to load a class or resource, then it must also acquire a lock first. Obviously if two or more threads are attempting this, then a dead lock is possible.
> I will attach the thread dump to this issue as supporting evidence.
--
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