> > I see a problem with the current way that the expanding of the archives > > is > > not transparent to the content of the archive. When the root directory is > > unique we can circumvent the lock but the structure of the archive is the > > same. It also makes it easier to find content because right now you need > > a path to the EAR and WAR directory as well to the JAR files to fnd them > > When the root is unique then you only need the path to the root dir. > > Maybe I don't understand what you are suggesting. Could you give a specific > example?
- Copy "survey.ear" to /deploy/Default - Create a directory "survey.ear.001" - expand survey.ear into this directory - expand survey.war into this directory in subdirectory "survey.war" - etc. - remove "survey.ear" Right now it is expanded into /deploy/Default under directory "survey.ear" but the the JAR files are name ejb1001.jar and WAR files are expanded into directory "Web1001" etc. > Are you looking at how j2ee deployer works today (I don't know) or how > DeployerMBeanSupport works (I think is fine, but maybe you need more info > on original name of each package??)? Right now I am focusing on the deployment of J2EE deployments meaning J2eeDeployer. > I thought there would be name conflicts with recursive unpacking unless > each unpacked package goes in its own uniquely named directory. Exactly > what part of a package url/name do you need for jsr77? I propose that the root directory is unique and the content represents the archive (except for the JAR files). For JSR-77 I need many informations like the DD, the various deployment modules any many more (some of them are not specified (like the vendor specific DDs)). It is not all about package URL/name. > > > > - WAR archives in an EAR archive are expanded in a sub-directory > > > > of the EAR deployment directory named after the WAR file > > > > > > I don't know how this works, does j2ee deployer do this or the servlet > > > container? > > > > Installer expands the archive and the J2eeDeployer hands over the path > > to the Web-container. > > > > > > - "Deployment.java" class will only contain the deployment directory > > > > and the "Application.java" as data container for the root archive > > > > - "Application.java" contains Modules (see Deployment) representing > > > > inner archives > > > > > > > > Based on these changes I will rewrite the J2eeDeployer and Container- > > > > Factory. Later on I will migrate these changes also to the > > > > J2eeScropeDeployer. > > > > > > I would ditch the non-scope deployer. I think figuring out how to > > specify > > > which scope is an unanswered question. > > > > > > I have a large part of a "universal deployer" written, the idea is to > > > separate the unpacking phase (same for every kind of package) and the > > dd > > > processing phase (actually done by package specific deployer.) It's > > very > > > similar to how ServiceDeployer and RARDeployer work now with > > > DeployerMBeanSupport. If you want to collaborate I could send you what > > I > > > have now, or if you want to use the unpacking services of > > > DeployerMBeanSupport anything you do now could easily be converted to > > use > > > the UniversalDeployer once I get it done. Or maybe you want to start > > > over;-) > > > > Yeah, let me have a look. My motivation comes from the JSR-77 stuff to > > retrieve the necessary information and to keep a link from the EAR until > > the > > components (EJBs, Servlets, Connectors etc.). > > I think you could get this out of the DeploymentInfo I have in > UniversalDeployer -- it has lists of all the unpacked urls and xml files > found. It would be easy to add original package names if you need them. Are you rewriting the J2eeDeployer ? If yes, I will wait until you are ready. Andy _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
