geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Commented: (GERONIMO-5021) Allow gbean classes to be loaded from another plugin
Date Fri, 08 Jan 2010 23:22:54 GMT


David Jencks commented on GERONIMO-5021:

rev 897346 implements this and uses it in jetty and jasper. The welcome-jetty-server seems
to work OK. This doesn't use runtime jsp compilation but does use a precompiled jsp.

> Allow gbean classes to be loaded from another plugin
> ----------------------------------------------------
>                 Key: GERONIMO-5021
>                 URL:
>             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  This has a couple of undesirable
> 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.

View raw message