5 Replies Latest reply on Jun 6, 2005 2:10 PM by juha

    JBoss Bean Deployer - deployment names

      This is really one for the "naming nazis" :-)

      What do you want to call the bean deployments?

      I'd suggest something like:
      Archive Name: mybeans.bar
      Archive MetaData: META-INF/jboss-beans.xml
      NonArchive MetaData: *-beans.xml

      I could also allow these to be changed on the deployer itself through JMX attributes?

        • 1. Re: JBoss Bean Deployer - deployment names
          starksm64

          Since there is some discussion that could result in .bar being a j2ee suffix, I would suggest jbar for java bean archive.

          As part of adding a new deployer, I would like to address the suffix handling issue that showed up with the har deployer in JBAS-1801. All deployers should just be declaring their suffixes and the recognization/unpacking issues handed by the base support classes to avoid the inconsistency showing up now.

          Adrian says in response to the latter issue:


          Given that we don't have the VFS in JBoss4 (the VFS would potentially allow signing of directories as well) what is the final decision on what should be supported by each layer.

          I would think the packed/unpacked issue should be transparent to the deployers and the deployment descriptors?
          e.g. if my deployer accepts .foo it should accept .foo/ without having to explicitly say so.


          Most deployers can rely on the packing/unpacking done by the MainDeployer and should not have to worry about details of whether they can handle an archive or a directory as the DeploymentInfo.localUrl and localCl should be configured correctly for them. Deployers like the ear and war deployers are the problems since they have non-trivial heiarchical structures.

          I think the main problem with consistency right now is the ear deployer's notion of overriding the subdeployment processing. First, the list simply needs to be externalized. Beyond that, the notion of restricting subdeployments to the application.xml jars is broken because we allow arbitrary subdeployments to be introduced via the jboss-app.xml descriptor.

          We should just be checking the subdeployment against the list of archives specified via the application.xml or jboss-app.xml descriptors. Really, I don't think we care at all about the suffix.


          • 2. Re: JBoss Bean Deployer - deployment names
            starksm64

            I have created a seperate thread in the deployers forum for the JBAS-1801 sidetrack.
            http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880454

            • 3. Re: JBoss Bean Deployer - deployment names

               

              "adrian@jboss.org" wrote:

              What do you want to call the bean deployments?


              *.beans ?

              Who says everyone has to stick to a stupid three letter convention anyway? We already have *.class



              • 4. Re: JBoss Bean Deployer - deployment names

                 

                "juha@jboss.org" wrote:
                "adrian@jboss.org" wrote:

                What do you want to call the bean deployments?


                *.beans ?

                Who says everyone has to stick to a stupid three letter convention anyway? We already have *.class



                That's what I called it in the code I just committed.
                So you can have deployments like "full.of.beans" :-)

                • 5. Re: JBoss Bean Deployer - deployment names

                  cool...

                  foo.bar had some potential too though