Hi there, -----Ursprüngliche Nachricht----- >Von: marc fleury [mailto:[EMAIL PROTECTED]] >Gesendet: Mittwoch, 30. Mai 2001 20:20 >An: [EMAIL PROTECTED] >Betreff: RE: Inital Checkin of J2eeGlobalScopeDeployer was AW: >[JBoss-dev] CVS update: >Hey, >JBoss world tour is over... back to home base, ready to go in project Rabbit >hole, first email is yours ... what honour ;-) Be sure to read the JBossSoap proposal, too, as there are a few people who have applied to volunteer and I like to start this the earlier the better. >1st... congratulations on the job, it seems we are in synch on what we want >to achieve, comments below, thx for your comments. But before we run into the same misunderstandings as before, please, first review the code and then let´s talk about it concretely. (Since I´m going to merry in three weeks, I also have a bit of stress, here such that I cannot thoroughly answer to your surely well-founded arguments below before next week!) >There are so many problems that when we get this stabilized we should >default to your new and improved deployer, let's target 3.0. that was my ultimate goal: to get this as "default" into the codebase (maybe with enough configuration options such that no one will ever notice - especially performance-wise - that is not interested in getting the features and such that there is enough room for subclassing and getting all the functionality into it that is in our minds) and not residing in a dead folder besides the usual deployer (I had already a hard time to sync/decrease the redundant parts of the code ...) >Excellent, that is all we really need from a CL standpoint. I was against >the externalization of the CL dependencies, I proposed the initial CL to do >lazy loading and linking. right. >How is that done? (didn't read the code) in my initial proposal this was >done with the static map. How do you "scope" that map now? who defines the >application scope? where do you specify that? remember the less you specify >the better. The map is not static, but resides in a seperate instance, the Scope, that aggregates the classloaders that belong to that scope. >Also if someone fails to specify a scope, do you still use a default >(static) map? >again this is a great but what do you need to specify and where to get a >scoped deployment... what happens if you don't specify a scope. Currently, there is only a global scope instance (hence this is sort of static). The default deployment methods automatically use that one as reference ... But they just delegate to deployment methods that accept scope/scopename as their parameter ... if we manage to agree on a naming scheme, then these methods could be public/Mbean methods as well. >well by definition we cache the class (that is the whole fucking point) >don't make it sound like it is an "extra" ;-) hmmm, the current code caches the dependency information (hence className-->DeploymentClassLoader, instead of className-->class, in order to easily drive the undeployment logic). Since the className-->class is usually cached by URLClassLoader, this should not be a too great overhead, should it? >Ok, testbean3-->testbean2-->testbean what happens to testbean3 when we >cycle testbean? I assume this is there already? >in other words, you can build the graph of dependencies implicitely (lazy >loading and interception of load in the CL) and build a dependent set per >class and cycle that. oui. >Here we could get fancy at the CL level... >so that deployments wait until the dependencies are cleared... a bit more >complex imho... do not understand, yet. But lets discuss this next week. >I doubt it to establish CL dependencies (we can induce them) it is useful >for specifying order of deployment though... that´s exactly the information that is expressed explicitely in the Class-Path: order and need of deployment. The dependencies are then computed at runtime such that redeployment is optimal. >I don't remember saying that :) but I might have since yes it is a way to go >about it. At least this way we ensure that we only have one version all the >time, however it is still up to the deployer to make sure that all the >packages have the right version which might be a maintainance problem. I do >believe that your "explicit" solution to that problem is a bit more admin >friendly, but I do also believe that we could get fancy in the deployment >structures to allow for self sorting of the apps. We would need to catch >the failed dependencies at the CL / Deployer level and put the ear/war in >the back of a list and try to deploy the others. Circular dependencies >between jar need to be resolved by putting everyone in one jar, I don't see >a simple solution to that off-hand. >good work man, I hope to find time to review this code as part of Rabbit >hole... CU CGJ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
