[JBoss JIRA] Created: (JBOSGI-119) Blueprint Container service is unregistered
by Thomas Diesler (JIRA)
Blueprint Container service is unregistered
-------------------------------------------
Key: JBOSGI-119
URL: https://jira.jboss.org/jira/browse/JBOSGI-119
Project: JBoss OSGi
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Fix For: JBossOSGi 1.0.0 Beta4
When the Blueprint Container must be destroyed because: the Blueprint
bundle has stopped, there is a failure, or the Blueprint extender is stopped,
then the Blueprint Container service is unregistered and all managers are
deactivated. This will unregister any services and disable listeners, which
release the component instances. Then all component instances are
destroyed in reverse dependency order. That is, a component instance is
destroyed when no other component instances depend on it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Created: (JBOSGI-120) All top level managers share a single namespace
by Thomas Diesler (JIRA)
All top level managers share a single namespace
-----------------------------------------------
Key: JBOSGI-120
URL: https://jira.jboss.org/jira/browse/JBOSGI-120
Project: JBoss OSGi
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Fix For: JBossOSGi 1.0.0 Beta4
The Blueprint Container maintains a registry of managers by their id. These
are the managers that are called the top-level managers. Top level managers
are managers defined as child elements of the top XML blueprint element or
bean managers in the type-converters element. Their Metadata is registered
under their id (or calculated id) in the Blueprint Container. All top level
managers share a single namespace. That is, it is an error if the same id is
used multiple times or attempts to override the built-in environment managers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Updated: (JBOSGI-267) Allow multiple bundles to change state at once
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBOSGI-267?page=com.atlassian.jira.plu... ]
Thomas Diesler updated JBOSGI-267:
----------------------------------
Fix Version/s: Framework 1.0.0 Alpha4
(was: Framework 1.0.x)
> Allow multiple bundles to change state at once
> ----------------------------------------------
>
> Key: JBOSGI-267
> URL: https://jira.jboss.org/jira/browse/JBOSGI-267
> Project: JBoss OSGi
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Core Framework
> Reporter: Thomas Diesler
> Assignee: Ales Justin
> Fix For: Framework 1.0.0 Alpha4
>
>
> Currently the BundleManager can only reslove bundles one-by-one
> deployerClient.change(unit.getName(), DeploymentStages.CLASSLOADER);
> deployerClient.checkComplete(unit.getName());
> bundleState.changeState(Bundle.RESOLVED);
> this results in uglyness in PackageAdmin
> int resolved = 1;
> while (resolved > 0)
> {
> resolved = 0;
> Iterator<OSGiBundleState> it = resolvableBundles.iterator();
> while (it.hasNext())
> {
> OSGiBundleState bundleState = it.next();
> if (bundleManager.resolveBundle(bundleState, false))
> {
> it.remove();
> resolved++;
> }
> }
> }
> PackageAdmin should be able to use an API that resolves multiple deployemnts at once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Created: (JBOSGI-287) Optional import loaded from system classloader
by Thomas Diesler (JIRA)
Optional import loaded from system classloader
----------------------------------------------
Key: JBOSGI-287
URL: https://jira.jboss.org/jira/browse/JBOSGI-287
Project: JBoss OSGi
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Framework
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Fix For: Framework 1.0.0 Alpha3
It seems that the compendium resolves with the optional javax.servlet.http.
The jetty bundle which contains javax.servlet.http resolves later.
When the HttpService is loaded from compendium we get a LinkageError, because HttpServletRequest is loaded from the system CL.
Compendium should import javax.servlet.http from the jetty bundle.
Compendium should never be able to load HttpServletRequest from the system CL.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months