[
https://issues.apache.org/jira/browse/GERONIMO-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick McGuire updated GERONIMO-5021:
-----------------------------------
Issue Type: Sub-task (was: New Feature)
Parent: GERONIMO-5087
> 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.
-
You can reply to this email to add a comment to the issue online.
