[ https://issues.apache.org/jira/browse/GERONIMO-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved GERONIMO-5021.
------------------------------------
Resolution: Fixed
Seems to have been fixed.
> Allow gbean classes to be loaded from another plugin
> ----------------------------------------------------
>
> Key: GERONIMO-5021
> URL: https://issues.apache.org/jira/browse/GERONIMO-5021
> Project: Geronimo
> Issue Type: Sub-task
> Security Level: public(Regular issues)
> Components: kernel, osgi
> Affects Versions: 3.0
> Reporter: David Jencks
> Assignee: David Jencks
> Fix For: 3.0
>
>
> currently when we deploy an ee app we add import-packages for the geronimo bits needed
for the gbeans to run it to the resulting plugin's manifest.mf. This has a couple of undesirable
features:
> 1. the geronimo classes are visible to the app.
> 2. we can't use our deployment for things like osgi rfc 66 which start with a bundle
that happens to be a WAB and doesn't allow for modifying the manifest to add our import-packages.
We could possibly work around this by using fragment bundles associated with the WAB but
this still alters the visibility environment of the app.
> Proposed solution is to add a field
> private Artifact classSource
> to GBeanData that a module builder can set to indicate to GBeanInstance where the class
should be loaded from. This is quite gbean-centric in that we are using geronimo artifacts
to identify a geronimo plugin rather than something more osgi-friendly. However, since we're
using gbeans, this might not be such a big problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
|