[
https://issues.apache.org/jira/browse/GERONIMO-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798620#action_12798620
]
David Jencks commented on GERONIMO-5021:
----------------------------------------
DefaultEnvironment adds, effectively, import-package entries to the manifest of
the geronimo plugin. However, for rfc-66 like scenarios, we cannot modify the
manifest of the WAB or other bundle. So, we have to find a way to create the
gbeans for a WAB without having the gbean classes available to the WAB itself.
The solution I'm proposing is in two parts:
1. GBeanData has a new optional classSource artifact field that if set,
indicates that the bundle from the names geronimo plugin should be used to load
the class.
2. Each ee-related builder needs to set this field for gbeans that "run" ee
apps.
So, in particular, the jspModuleBuilderExtension and the JettyModuleBuilder
have fields where this artifact can be configured to the appropriate plugin.
It might be better to go directly to the bundle with the required classes, but
I don't know of a good way to get from an geronimo artifactId to an osgi bundle.
I might not have understood your suggestion....
> 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.
