Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <1588213312.25361265114418842.JavaMail.jira@brutus.apache.org>
Date: Tue, 2 Feb 2010 12:40:18 +0000 (UTC)
From: "Rick McGuire (JIRA)" <jira@apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Updated: (GERONIMO-5021) Allow gbean classes to be loaded
 from another plugin
In-Reply-To: <771711216.129621262986555262.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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