1 2 Previous Next 15 Replies Latest reply on Sep 29, 2006 7:36 AM by adrian.brock

    Why is DeploymentUnit.getDeploymentContext() deprecated?

    bill.burke

      I did see this thread:

      http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3973024


      I'm using the DeploymentContext.getRoot() to get the Archive so that I can scan the class files within it. Currently, I don't see any other way of doing this.

        • 1. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

          This is wrong. You need to use the classpath to find out what to scan.

          e.g. scanning the root of a war will pickup a
          myway.war/something.class files that are not part of the classpath,
          instead they are contents to be served over the web.

          It is for this reason that I don't want to expose the full DeploymentContext
          via the DeploymentUnit. Because people will do things that don't
          correspond to the full model.

          I'd suggest something like making a combination helper out of the:
          org.jboss.deployers.plugins.deployers.helpers.ClassPathVisitor
          and
          org.jboss.virtual.plugins.vfs.helpers.SuffixMatchFilter
          since this could be a common pattern?

          Then add a
          void visitClassPath(VirtualFileVisitor)
          to the deployment unit.

          • 2. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

            Note: The notion of things like an abstract ClassPath and MetaDataLocation
            is fundamental to the aspectized deployers being able to work
            with varied style/structure of deployments.

            Some of which we haven't even invented yet :-)

            • 3. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
              bill.burke

              can you please describe how DeploymentContext.getClassPath() is formed?

              • 4. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
                bill.burke

                I don't think getClassPath will work. I'm not sure that manifest entries are supposed to be scanned as well.

                • 5. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
                  bill.burke

                   

                  e.g. scanning the root of a war will pickup a
                  myway.war/something.class files that are not part of the classpath,
                  instead they are contents to be served over the web.


                  Are the JARs within WEB-INF/lib DeploymentUnits in the new kernel? If so, then WEB-INF/classes also needs to be a separate DeploymentUnit.

                  Persistence Units are scoped when deployed within a WAR or EJB-JAR. Also the gay '#' syntax can be used to navigate to PUs within different components deployed within an EAR.

                  • 6. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

                     

                    "bill.burke@jboss.com" wrote:

                    Are the JARs within WEB-INF/lib DeploymentUnits in the new kernel? If so, then WEB-INF/classes also needs to be a separate DeploymentUnit.


                    No. The deployment unit is the war.
                    WEB-INF/lib and WEB-INF/classes form part of the ClassPath.

                    • 7. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

                       

                      "bill.burke@jboss.com" wrote:
                      I don't think getClassPath will work. I'm not sure that manifest entries are supposed to be scanned as well.


                      If that is the case, then we'll need a more refined notion
                      of classpath that differentiates internal elements from
                      imported elements.

                      We probably need this anyway for the OSGI style classloader
                      that Scott started?

                      • 8. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

                         

                        "bill.burke@jboss.com" wrote:

                        Persistence Units are scoped when deployed within a WAR or EJB-JAR. Also the gay '#' syntax can be used to navigate to PUs within different components deployed within an EAR.


                        Yes navigation of the whole deployment (top level + children)
                        is an api that needs adding to the DeploymentUnit.

                        I *hacked* it for the rar, so it can generate the myear.ear#myrar.rar
                        but this needs fixing!!!

                        The "gay" # syntax is actually part of the URI specification.
                        http://www.ietf.org/rfc/rfc2396.txt

                        file:///some/path/some.ear#some.jar

                        It's clearly no use for nested jars within nested jars.

                        The VFS uses a more logical/obvious name :-)
                        file:///some/path/some.ear/some.jar


                        • 9. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
                          bill.burke

                           

                          "adrian@jboss.org" wrote:
                          "bill.burke@jboss.com" wrote:

                          Are the JARs within WEB-INF/lib DeploymentUnits in the new kernel? If so, then WEB-INF/classes also needs to be a separate DeploymentUnit.


                          No. The deployment unit is the war.
                          WEB-INF/lib and WEB-INF/classes form part of the ClassPath.


                          As far as Class-path manifest goes, I think we are screwed either way. For auto-scanning of the PU you will want to scan only the classpath manifest of one particular jar in web-inf/lib.

                          Another problem I see is again, what abput META-INF/persistence.xml? In a war, it could be in multiple JARs in web-inf/lib. I need to be able to look at the JAR as a completely contained unit. So whether or not Class-path manifest should be scanned, I still need to know what exact JARS are in WEB-INF/lib excluding classpath manifest entries so that I can find the META-INF/persistence.xml for each of these jars.


                          Also, what about an EJB-JAR within an EAR? Is the EJB-JAR a DeploymentUnit I assume? If it is a DeploymentUnit does its ClassPath contain EAR/lib jars? If so this is really bad as again, I need to treat the EJB-JAR as its own unit.

                          • 10. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

                             

                            "bill.burke@jboss.com" wrote:

                            As far as Class-path manifest goes, I think we are screwed either way. For auto-scanning of the PU you will want to scan only the classpath manifest of one particular jar in web-inf/lib.


                            You make it sound like the jars in WEB-INF/lib should be separate
                            deployment units?


                            Also, what about an EJB-JAR within an EAR? Is the EJB-JAR a DeploymentUnit I assume? If it is a DeploymentUnit does its ClassPath contain EAR/lib jars? If so this is really bad as again, I need to treat the EJB-JAR as its own unit.


                            Each deployment unit has its own classpath.
                            That way it is possible to implement one classloader per
                            deployment unit or what is done now, a classloader
                            for the whole deployment by consolidating the classpath with
                            that visitor I mentioned before.

                            Feel free to extend the model to whatever fine granularity you
                            require.
                            e.g. making each jar in WEB-INF/lib its own deployment unit
                            e.g.2. separating the classpath into internal/external (manifest)
                            components

                            This api is not final until we understand what
                            the real deployers need.
                            to do

                            • 11. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
                              bill.burke

                              Yeah, I don't think doing deployments based on ClassPath is the way to go. For instance, in an embedded jboss environment (Java SE) every component has the same classpath.

                              • 12. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
                                bill.burke

                                Come to think of it Classpath is more of an abstract thing. We need to know structure and deploy based on a structure.

                                • 13. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

                                   

                                  "bill.burke@jboss.com" wrote:
                                  Come to think of it Classpath is more of an abstract thing. We need to know structure and deploy based on a structure.


                                  Which is exactly what the structure deployers do.
                                  They create the classpath from structure.

                                  Exists:
                                  Is this a jar? Well the classpath is the root
                                  Is this a war? Then the classpath is WEB-INF/classes and WEB-INF/lib/*.jar

                                  Doesn't exist:
                                  Is this a j2se system classloader, then the classpath is the
                                  paths from the system property. Or more likely each
                                  path element is made into a deployment unit so you could even
                                  add an ear to the classpath. ;-)

                                  • 14. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
                                    bill.burke

                                    No, what i'm saying is that certain deployers need to deploy based on a concrete structure, not a classpath. Or in other words, the lines are too blurry for some deployers to be driven by classpath.

                                    This is why for EARS and WARS I think their lib/ and classes/ directories need to be treated as child DeploymentUnits.

                                    1 2 Previous Next