[
https://issues.apache.org/jira/browse/GERONIMO-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798571#action_12798571
]
Ivan commented on GERONIMO-5021:
--------------------------------
Usually, all the gbeans codes could be loaded from the artifacts in the
defaultEnvironment, I found an extra field is addes in JspModuleBuilder, why
not define an artifact list in the GBeanData as class sources, and directly use
them as the source artifacts ?
Thanks !
> 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: New Feature
> 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.
