You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2010/01/08 22:35:55 UTC
[jira] Created: (GERONIMO-5021) Allow gbean classes to be loaded
from another plugin
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.
[jira] Updated: (GERONIMO-5021) Allow gbean classes to be loaded
from another plugin
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (GERONIMO-5021) Allow gbean classes to be loaded
from another plugin
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (GERONIMO-5021) Allow gbean classes to be loaded
from another plugin
Posted by "Ivan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798621#action_12798621 ]
Ivan commented on GERONIMO-5021:
--------------------------------
I might not express myself clearly. I understand that why the source artifactid is added in the gbeandata. But for JspModuleBuilder, I think that we could use the values configured by defaultEnvironment as the value of source artifactId, I am just not sure why another paramter jasperArtifact is needed. It is duplicated with the parameter defaultEnvironment. We should be able to pass the artifactIds in the defaultEnvironment to gbeandata as the source artifacts to load the gbean classes.
--->
public JspModuleBuilderExtension(@ParamAttribute(name = "defaultEnvironment") Environment defaultEnvironment,
@ParamAttribute(name = "jasperArtifact") Artifact jasperArtifact,
@ParamReference(name = "NamingBuilders", namingType = NameFactory.MODULE_BUILDER) NamingBuilder namingBuilders) {
this.defaultEnvironment = defaultEnvironment;
this.jasperArtifact = jasperArtifact;
this.namingBuilders = namingBuilders;
}
<---
> 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.
[jira] Commented: (GERONIMO-5021) Allow gbean classes to be loaded
from another plugin
Posted by "Ivan (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (GERONIMO-5021) Allow gbean classes to be loaded
from another plugin
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798244#action_12798244 ]
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: 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.