On 2002.04.22 02:41:50 -0400 Jason Dillon wrote: > > > David, if you are reading this... and got this far down... what is > the > > > plan to > > > have this issue tied down and solved once and for all. I think the > > > approche > > > that dain, you and I discussed in Tahoe is along the correct lines. > > > > > > Do you have any idea when the wrinkles will be sorted out? > > > > What _ARE_ the wrinkles???? > > Um... the problem is that the dependency system does not cover all > components > does not cover the relation ship between config and configless archice > (ie. > jar). > > Didn't we talk about this in Tahoe? Is this the same David... or have I > been > sucked into a parrallel universe...? > > > I spent the weekend writing a new local jdbc > > wrapper rather than looking for deployment problems. I need a clear > list of > > problems without a lot of arguing about solutions. > > I don't have the full list... but one is all of this ordering maddness. > > > I get distracted easily. > > Yes that is clear =] > > > We have right now: > > > > mbeans depend on their classes, if the class isn't there they wait. If > it > > is removed they save their configuration, and if the class comes back > they > > recreate themselves with the saved config. I am pretty convinced that > this > > cannot be modeled as an mbean dependency without a really major rewrite > of > > the dependency system which I think is undesirable. This dependency is > > really different from mbean-mbean dependency and I don't think we > should > > try to force it to fit. I think it works fine the way it is now. > > Didn't we descide to model these dependencies as MBean dependency on the > MBean > that represents that deployed file? This way all depends are modeled in > the > same fashion. > > Seriously don't you remeber having this conversation? > > > ejbs can depend on other mbeans. Its not automatic, but you can put a > > depends element in jboss.xml in the bean config or in the > container-conf. > > > > We already have depends between mbeans. I'd still like to remove the > > dependency wait in the create step, but not before 3.0 comes out. > > > > Once again... what are the problems? > > Ok, perhaps I am consued... but if all of these dependency issues are > solved, > then we do not need to have any ordering in a DS, as the dependency > system > will handle bringing components up when dependents are available. > > If this is true, then we can remove the need for sorting URLs from any DS > and > we can have DS peers with out having to worry about what order they come > up > in... cause it plain does not matter. > > If this is not the case, then there is a problem with the dependency > system > and that should be resolved. > > I had assumed it was not due to the sorting madness which still seems to > be > alive in some of us. I had also assumed that part of the solution was to > turn > deployed files into MBeans and config into MBeans per the talk with dain > and > you. > > Which is it?
1. As far as I know, the deployment problems we have now are due to arguing with the tomcat classloaders. I have tried to stay out of this, maybe I won't be able to. I would like very much to know of any other problems, I am not aware of any. Everyone, please be concise yet thorough in reporting such problems. 2. In Tahoe I had some doubts about whether it was practical to model dependencies between mbeans and their class through mbean-mbean dependencies. I still haven't found a way to do it and am not convinced it is desirable. However I think what I did implement for mbean-class dependencies does work fine. I'm not aware of any problems with it anyway. Again, problem reports are welcome. 3. I think eventually we want each deployed package (DeploymentInfo) to be represented by an mbean. I think Larry's plans for making these package-type-specific should happen first/simultaneously. I don't know of any current deployment problems that would be immediately solved by making the current DeploymentInfo into an mbean. 4. I really don't know if there is any need right now for sorting deployments. I suspect that at the moment it is helpful in avoiding a necessity of explicitly listing ejb dependencies on mbeans that could theoretically be automatically determined but are not at present. So, for me to proceed with modifying anything, I need to know about a specific problem with how the system currently operates. Right now I don't know of any specific problems that are related to our (rather than Tomcat) deployment. (I wouldn't rule out my head being buried in the sand though;-) thanks david jencks > > --jason > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
