9 Replies Latest reply on Oct 25, 2006 5:22 PM by mculpepper

    JBoss5 integration

    starksm64

      A thread to discuss integration between the ide and jboss5. The main 3 levels which with the ide will need to integrate are:

      - vfs - a simple read-only virtual file abstraction. It does have a simple link notion that allows for virtual archives to be composed of various files so that one does not explicitly need to create war/ejb archives.
      - deployers - structural and runtime deployment spi. This could be used directly by the ide for one off deployments.
      - profile service - a collection of deployments as a named profile. This would be used by the ide if one wants a notion of a collection of deployments being part of a project.

      See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework for how these relate. The vfs/structrual deployers in the middle of another refactoring that needs to be completed before we can discuss how to use it.

        • 1. Re: JBoss5 integration
          starksm64
          • 2. Re: JBoss5 integration

            Any details on when the restructure will be complete? I'm curious how a JBossIDE implementation will be able to install itself into a running JBossAS for deployment..

            • 3. Re: JBoss5 integration
              starksm64

              The vfs changes should be complete as the stuff Bill is working on should not change the spi. I'm testing the deployer changes currently against trunk and hope to have that done today.

              • 4. Re: JBoss5 integration
                maxandersen

                what does "install itself" mean ?

                I had the naive vision that what we would be able to deploy a simple file describing a virtual filesystem allowing jbosside to be loosly coupled.

                What is the benefit from "installing the IDE into a running jbossas" ?

                • 5. Re: JBoss5 integration

                  Max,

                  I'm just trying to figure out the technical details of how we will expose a deployment to JBossAS. Whether that means creating some temporary XML descriptor and sending it to JBoss, or installing some kind of service that we can talk to.

                  • 6. Re: JBoss5 integration
                    starksm64

                    There are two levels as I see it. There is a jsr88 type of service/profile service for deployment. I think jsr88 is not particularly useful, especially with the addition of annotations, but its something we need to support and there must be some use of the api in the wtp thing. Mostly its the notion of having the vendor ee descriptors be tied into jsr88 as well as having an xpath notion of the deployment metadata that seems out of synch. Regardless, there is a deployment service.

                    Beyond that, there is the question of controlling how the package deployed through jsr88/profile service is physcally structured. I expect that we want to leverage the vfs to avoid having to create physical ee packages and instead create logical ears/wars that are a union of the ide project files. This is manipulation of the vfs configuration/implementation that we need to flesh out.

                    • 7. Re: JBoss5 integration
                      maxandersen

                      ok - regarding JSR-88 i haven't seen that in context of WTP ....marshall/rob - have you ?

                      • 8. Re: JBoss5 integration
                        rob.stryker

                        The only thing even mentioning such a thing that I've seen is some article somewhere with a completely unsubstantiated claim that webtools supports JSR-88 for "at least one major J2EE vendor", but there was absolutely no further details given and no demonstration of even a UI for such a thing.

                        • 9. Re: JBoss5 integration

                          AFAICT Webtools doesn't and won't have JSR88 support until someone brings something to the table. We had initially tried giving our old JSR88 tools (that Rob wrote when he was a co-op) to Eclipse as an initial contribution, with "someone else" taking on the responsibility after that... but no one stepped up to the plate.

                          It's a weird landscape .. it seems all the major vendors are "interested in having JSR88 tools" yet no one wants to pony up the resources. My guess is this won't change in Webtools 2.0.