On 2001.11.21 13:16:11 -0500 marc fleury wrote: > Sanity, > > thanks professor seems you are on shore with me for once :) > > |> Regardless, I'm going to work on the deployment layer to clean it up > |> and add support unarchived ears. > | > |I the likely case you get to this before I do, my goals for j2ee and > other > |deployment are: > | > | > |- Unify the ServiceLibraries and the Scoped Classloader and always use > the > |result. > > correct. I will do it if you don't. > > |- Separate deployment into > |--autodeploy detection. This will watch directories and on timestamp > change > |undeploy and redeploy. > | > |-Universal deployer. This will > |--determine which classloader to use (system (now ServiceLibraries) or > |application (now Scoped), but these should use the same code base). > This > |may turn into your idea of virtual host. > > Yes, good how are you going to do that?
(not completely worked out yet) I think every jboss dd could include a scope (or virtual host) attribute at its top level. If something comes in as a subpackage of something with an explicit scope (ejb-jar or rar or sar in ear), it goes in the same scope. If the scope is missing, if it is a sar or rar, it goes in the system scope, otherwise it gets its own private uniquely named scope. > > how about just moving the scl to sl? scl = scoped classloader sl = service libraries? the only problem there is the > ordering > of lookups which I think differs significantly but... we can look at > using > one structure. If we always set the SL as parent to teh scl then I don't > think we need to hint anything. I wondered, I haven't had the time to try this. > > |--put all accessible classes from the packaging into the extensible > |classloader (I'd use extractPackages from DeployerMBeanSupport) > > woot? what is this? I'm not an expert on this. Looking (quickly) at the j2ee deployer, it looked to me as if there was a lot of effort expended to trace various manifest classpaths etc etc. What would happen if we just put everything in the package (ear, sar, rar, whatever) in one (jboss) URLClassloader? I don't understand what these internal dependency indications are for or the consequences of ignoring them. It might as well go in one classloader, you can't redeploy embedded pieces of a deployment unit anyway. For instance, in the jar in sar, you can now have a sar with a directory structure with classes in it, plus a bunch of jars in it. This gets unpacked into a copy of the original sar, plus copies of the jars unpacked out of the sar. One (JBoss) URLClassloader handles all of them. Would there be any problems doing this for an ear? I asked a few weeks ago and no one answered. > > |--Figure out what order to process the xml dd files, discovered in the > |previous step. > |--Feed the xml files to the appropriate deployers in the appropriate > order. > | > |-individual deployers (Service, RAR, ContainerFactory, J2ee, etc) > |--these will now only process the (xml) dd. > > yes, good > > |-A new deployer for "deployment scripts" that basically contain an > ordered > |list of other things that can be deployed. Although in principal I > think > |all dependencies should be stated explicitly, a script facility would > allow > |deployment of units in a specified order rather than relying on the > random > |order of detection by autodeployer. > | > |Any thoughts? > > Excellent, some sanity finally, excellent professor, excellent. > > |David Jencks > > marcf thanks david jencks > |> ><snip> _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
