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