Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0
    • Fix Version/s: 3.0.0
    • Component/s: kernel, osgi
    • Security Level: public (Regular issues)
    • Labels:
      None

      Description

      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.

        Activity

        David Jencks created issue -
        Hide
        David Jencks added a comment -

        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.

        Show
        David Jencks added a comment - 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.
        Hide
        Ivan added a comment -

        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 !

        Show
        Ivan added a comment - 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 !
        Hide
        David Jencks added a comment -

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

        Show
        David Jencks added a comment - 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....
        Hide
        Ivan added a comment -

        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; }

        <---

        Show
        Ivan added a comment - 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; } <---
        Rick McGuire made changes -
        Field Original Value New Value
        Parent GERONIMO-5087 [ 12454965 ]
        Issue Type New Feature [ 2 ] Sub-task [ 7 ]
        Hide
        David Jencks added a comment -

        Seems to have been fixed.

        Show
        David Jencks added a comment - Seems to have been fixed.
        David Jencks made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        851d 2h 34m 1 David Jencks 09/May/12 01:09

          People

          • Assignee:
            David Jencks
            Reporter:
            David Jencks
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development