RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
On Mon, 22 Apr 2002, marc fleury wrote: > *and unreadable XML* oh my -- Juha > > just tired of it all, > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Larry > |Sanderson > |Sent: Sunday, April 21, 2002 3:10 PM > |To: [EMAIL PROTECTED] > |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ? > | > | > |I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention > |a little less likely to stumbled upon by unknowing users. I suggest: > |jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for > |"indexed" deployments first, and sort the remainder by type. This allows a > |simple, global comparator, but removes the fine-grained support > |you suggest. > |So given the following within a directory: > | > |jetty.sar > |my_ejb_ver4.jar > |jar_jb5.jar > |sar_jb10.sar > | > |This would order them thus: > |jar_jb5.jar <-- all "indexed" deployments first > |sar_jb10.sar > |jetty.sar <-- all others second, in order of sar,rar,jar,war,ear > |my_ejb_ver4.jar > | > |Hell, if they really need the flexibility you suggest then they > |can set up a > |second scanner, but I can't imagine any place where this is not sufficient. > | > |-Larry > | > |> I'm not sure specifying the global sorter for a whole scanner is the way > |we > |> want to go... on the other hand extensibility is nice... Do we want to > |> encourage people to have lots of scanners? > |> > |> At the risk of making things more complicated than necessary, > |yet striving > |> for simplicity, how about > |> > |>|> name="jboss.deployment:type=DeploymentScanner,flavor=URL"> > |> > |> > |> 5000 > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> |optional-attribute-name="Deployer">jboss.system:service=MainDeploye > |r |s> > |> > |> > |> > |> > |> |name="jboss.deployment:type=DeploymentSorter,order=type"/> > |> |name="jboss.deployment:type=DeploymentSorter,order=lexical/> > |> > |> The deployment scanner looks up the requested ordering using the naming > |> pattern on the DeploymentSorter mbeans. > |> > |> I'm not sure if we really need explicit dependencies listed in the > |> DeploymentScanner. > |> > |> Striving towards simplicity (believe it or not;-) > |> > |> david jencks > |> > |> > |> On 2002.04.21 16:37:46 -0400 Larry Sanderson wrote: > |> > > As larry said (do you have rw yet?) > |> > > |> > Yup. I've already checked in at least one bug :-) > |> > > |> > > let's not shove it down people's throat > |> > > and let's document all of this. Case closed. Implementation > |needed :) > |> > > |> > Simple, and not too hacked implementation: > |> > > |> > Add MBean attribute to URLDeploymentScanner: URLComparator > |> > make default comparator point to: org.jboss.deployment.DeploymentSorter > |> > (make this a comparator that does the correct ordering) > |> > in scanDirectory, change: list = sorter.sortURLs(list); > |> > to: if (urlComparator != null) Collections.sort(list, urlComparator); > |> > > |> > This allows users unhappy with the ordering scheme to replace it with > |> > their > |> > own Comparator (or simply drop it to remove all ordering). If this > |> > sounds > |> > OK, I am mucking about in that code anyway. Would you like me to make > |> > these > |> > changes? > |> > > |> > -Larry > |> > > |> > > |> > > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> https://lists.sourceforge.net/lists/listinfo/jboss-development > |> > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > -- Juha Lindfors Author of "JMX: Managing J2EE with Java Management Extensions" Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I am checking out of this bullshit, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I am tired of JBoss-development, see a simple idea turned into mush for brains and unreadable XML just tired of it all, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Larry |Sanderson |Sent: Sunday, April 21, 2002 3:10 PM |To: [EMAIL PROTECTED] |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ? | | |I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention |a little less likely to stumbled upon by unknowing users. I suggest: |jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for |"indexed" deployments first, and sort the remainder by type. This allows a |simple, global comparator, but removes the fine-grained support |you suggest. |So given the following within a directory: | |jetty.sar |my_ejb_ver4.jar |jar_jb5.jar |sar_jb10.sar | |This would order them thus: |jar_jb5.jar <-- all "indexed" deployments first |sar_jb10.sar |jetty.sar <-- all others second, in order of sar,rar,jar,war,ear |my_ejb_ver4.jar | |Hell, if they really need the flexibility you suggest then they |can set up a |second scanner, but I can't imagine any place where this is not sufficient. | |-Larry | |> I'm not sure specifying the global sorter for a whole scanner is the way |we |> want to go... on the other hand extensibility is nice... Do we want to |> encourage people to have lots of scanners? |> |> At the risk of making things more complicated than necessary, |yet striving |> for simplicity, how about |> |>name="jboss.deployment:type=DeploymentScanner,flavor=URL"> |> |> |> 5000 |> |> |> |> |> |> |> |> |> |> |> |> |> |> jboss.system:service=MainDeploye |r |> |> |> |> |> |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
On 2002.04.22 11:26:06 -0400 Larry Sanderson wrote: > > Anyway, I think there is a real bug nearby that we > > need to fix. See > > > > http://jboss.org/forums/thread.jsp?forum=46&thread=1346&start=0&msRange=15 > > > > If a jar file references a nonexistent jar file in > > the manifest classpath > > entry, something (the scanner???) goes haywire and > > keeps trying to deploy > > the ./deploy directory as if it is a package. > > Presumably there is a > > missing existence check somewhere. > > I could not reproduce this bug on jdk1.4 for Windows. What VM was he > using? I can try Sun's jdk1.3 - have you been able to reproduce this? I'm afraid I didn't try to. Maybe we should ask him to check with cvs 3.0? Did you try with rc1 as released? david jencks > > -Larry > > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13522 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
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
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> Anyway, I think there is a real bug nearby that we > need to fix. See > > http://jboss.org/forums/thread.jsp?forum=46&thread=1346&start=0&msRange=15 > > If a jar file references a nonexistent jar file in > the manifest classpath > entry, something (the scanner???) goes haywire and > keeps trying to deploy > the ./deploy directory as if it is a package. > Presumably there is a > missing existence check somewhere. I could not reproduce this bug on jdk1.4 for Windows. What VM was he using? I can try Sun's jdk1.3 - have you been able to reproduce this? -Larry * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13522 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Michael Robinson wrote: > On Sun, Apr 21, 2002 at 07:11:52PM -0400, David Jencks wrote: > >>3. I'd like to have an actual user ask for this over explicitly listing the >>files in the deployment scanner. > > > I'm an actual user, and just the thought of reording by typing a bunch of > > % mv 05my-application.war 06my-application.war > [...] > % mv 01foo-applicationlibs.jar 02foo-applicationlibs.jar > % mv foo-newapplicationlibs.jar 01foo-newapplicationlibs.jar > > Well, it gives me itchy fits. > > Anyone who uses ant to manage their application development is going to > find the existing config option intuitive, simple, and straightforward > (assuming the documentation is clear about what you need to do, and why > you would need to do it). > > -Michael Robinson > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development Isn't it possible to include in xx-service.xml in the .sar what other services/jars it depends on? JBoss could then find the right order. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
On Sun, Apr 21, 2002 at 07:11:52PM -0400, David Jencks wrote: > 3. I'd like to have an actual user ask for this over explicitly listing the > files in the deployment scanner. I'm an actual user, and just the thought of reording by typing a bunch of % mv 05my-application.war 06my-application.war [...] % mv 01foo-applicationlibs.jar 02foo-applicationlibs.jar % mv foo-newapplicationlibs.jar 01foo-newapplicationlibs.jar Well, it gives me itchy fits. Anyone who uses ant to manage their application development is going to find the existing config option intuitive, simple, and straightforward (assuming the documentation is clear about what you need to do, and why you would need to do it). -Michael Robinson ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> > 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? --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> But this thread was started by you, whose original complaint was that it is > difficult to configure packaged archives. The answer is staring you in the > face and you can't see it... Deploy these as exploded archives, and modify > the configurations whenever you want. I don't want to manage the exploded archive. I want to manage the .sar and .xml... 2 files vs. who knows how many inside of an exploded archive. > That's crap, and you know it. If you're building a new house you can put > up > with a shitty apartment for a little while. You should know better than that if you are as good of a designer as you pimp yourself to be. If you are building a new house does that mean that you remodel your current shit hole so you have room for your new crap while you are building your new house? Do you also do that while you are trying to sell the shit hole? No and no... If there was a need for the hack because the system was failing with out it... perhaps. As was the reasomn for the sorting crap in the first place. You are adding a feature as a hack to an already functioning system... while we are trying to go final... which is just plain stupid. If you want this feature I say put in a seperate component... that is a safer hack than changing UDS at this point in the game. > Where are you coming from here? I have already expressed great interest in > fixing the root of the problem. What I am presenting is a solution that > will get us through until the process is complete. Yes I understand you are interested in helping, and for that I am greatful... in fact so much that I will appologize that I have gotten so heated in the past emails with you... But your solution seems inapproproate given where this version is in its release timeline given that it does not fix anything, it only adds feature. So I think the safest way to add the feature with out changing the stability of the system would be to add it as a replacement component. This allows you to make use of it, as well as others. > Fine. I give up - unless anyone else requests this and it is agreed that a > hack is OK for now, I will not check this in. I'm going to bed. Make it an optional replacement for UDS or leave it for 3.1 to run as a peer to UDS when dependency system is fixed. --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> > 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 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 get distracted easily. 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. 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? david > > --jason > > - > This mail sent through IMP: http://horde.org/imp/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: MBean attrib persistence was Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Yes, agreeded, but lets put this off until some of the other problems are fixed. There is nothing pressing us for this feature at the moment. Lets hold off until the deployment and dependency system is fixed. Either that or find a way to clone yourself. --jason Quoting David Jencks <[EMAIL PROTECTED]>: > Also.. > > I think we need a way of feeding configuration change scripts into the > server. For example, config snippets showing only the changed values for > the mbeans. Furthermore eventually we should make this transactional... > all changes succeed or you get back to your original state. > > david jencks > > On 2002.04.22 01:10:06 -0400 Jason Dillon wrote: > > What is the hell about jboss-auto.jcml? Is it that you never quite know > > what > > config is used? If so, then all of these solutions will result in this > > hell. > > > > Though some like it hot... and for them we can provid some abstraction to > > > > implement a file based persistence or jdbc or whatever. Then the input > > xml > > files are defaults which are used unless there is a value in the > > attribute > > store. > > > > If there is a way to inalidatye the store based on timestamps that would > > be > > good to... so if a user changes the file it will then override the bits > > in the > > store. > > > > --jason > > > > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > > > The jmx part of this is the persistence service, which is pretty highly > > > configurable. I think jbossmx has an xml-based persistence service > > > implementation. I also think it works best with xmbeans or at least > > > modelmbeans, another reason to migrate soon. So I think the technical > > > issue of storing the mbean attribute values is done, more or less, > > rather > > > elegantly. I just don't want to get back to the jboss-auto.jcml hell, > > and > > > am wondering how to think about the problem. > > > > > > david jencks > > > > > > On 2002.04.21 21:17:32 -0400 Jason Dillon wrote: > > > > Quick thought... if there was a pluggable interceptor in the config > > > > service > > > > which would filter values as well as some JMX interceptor that would > > > > persist > > > > attribute changes... > > > > > > > > Or even a pluggable interceptor around JMX attribute changes (for get > > > > config > > > > service, cause it will just invoke the server), then we could plug in > > any > > > > > > > > given impl to provide what you are talking about. > > > > > > > > One that would say create jboss-auto.jcml-like files (only better > > > > formatted so > > > > we can read them), or a serialzed hashtable with values or a > > database. > > > > > > > > There are some details wich need to be fleshed out, like what happens > > > > when the > > > > datastore has more values than the config file, how does the mbean > > get > > > > those > > > > config notices. > > > > > > > > Is there any part of JMX what handles this... lets use it, make it > > > > pluggbale, > > > > if it isn't already, then provide one ore more impls and let users > > choose > > > > what > > > > posion they eat. > > > > > > > > Personally I would disable it all and use the static files as the > > > > definitive, > > > > but others might like to boot up and then fiddle with the html > > adapter > > > > then > > > > expect the changes to remain on reboot. > > > > > > > > Both are possible... > > > > > > > > Really, where are the JMX guys... is there something in JMX that buys > > is > > > > this > > > > at ;little design cost? If not, what could we do to implement this? > > I > > > > think > > > > this is easiest done at the jmx level... though it will probably have > > to > > > > be > > > > something that can be described in jboss-service.xml as the first > > > > component. > > > > > > > > --jason > > > > > > > > > > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > > > > > > > Jason, thanks for trying to get this discussion back to something > > > > useful. > > > > > There's another thing I've mentioned a couple of times that I think > > is > > > > > relevant. > > > > > > > > > > What's the relationship between the initial config supplied by > > > > > *-service.xml files and the possibly modified config in the mbean > > > > server? > > > > > If someone changes something in the running mbean server, what do > > we > > > > do? > > > > > How persistent is the change? Where do we keep it? I think this is > > part > > > > of > > > > > the same family of questions-- just a different time frame. > > > > > > > > > > -- how do you easily modify config before deployment > > > > > > > > > > -- how do you save config changes made to deployed apps. > > > > > > > > > > I don't have a good answer. I'm trying to think of the situation > > like > > > > a db > > > > > -- deploying an mbean like an insert, modifying its config like > > update. > > > > > > > > > Undeploy should be like delete, but shutting down a server and > > > > restarting > > > >
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> You are trying very hard to implement exploded archives... which I personally > have little need for. But this thread was started by you, whose original complaint was that it is difficult to configure packaged archives. The answer is staring you in the face and you can't see it... Deploy these as exploded archives, and modify the configurations whenever you want. > I thought you said you were going to make sorting pluggable... why don't you > just go do that and leave this issue for later? I am about to check that in. This issue can wait, though I don't see why it should. > I think it would be simpiler to subclass, thus only complicating the config > for the very small percentage of users who will use this. If I am wrong, fine > we will have this fixced for 3.1 and then we will all be happy. > > You call it a hack, and I agree. However, we already have a hacked system > > that will hopefully be fixed shortly. > > This is a rather lame answer... lets hack it up more because it is hacked > already? You don't work for microsoft do you? That's crap, and you know it. If you're building a new house you can put up with a shitty apartment for a little while. > > Forcing me down the awkward path of > > well architect code that must function within a design that has outlived > > its > > usefulness is not the right answer. > > Ic, so because your functionality does not fit into the DS design due to a > problem with the deployment dependency system the DS design is now > useless? And you would rather hackup a component in this flawed design rather > than work on fixing the root of the problem... Where are you coming from here? I have already expressed great interest in fixing the root of the problem. What I am presenting is a solution that will get us through until the process is complete. Fine. I give up - unless anyone else requests this and it is agreed that a hack is OK for now, I will not check this in. I'm going to bed. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> scanner1 looks at dir1 with jar1, jar2jar 100 in it > > scanner 2 looks at dir2 with jar101...jar200 in it. > > I haven't checked recently but I thought scanning happened in its own > thread. Yes each DS which extends from ADS gets its own thread. > scanner1 starts, new thread deploys jar1... > > scanner2 starts, new thread deploys jar101,jar102,jar103 > thread 1 deploys jar2,jar3. > > thread2 finishes jar200 > thread1 is still on jar50. > > If you have one scanner, they will be deployed in order 1...200. > > Maybe I am wrong about the threads. No you are right. When I desgined this I had the understanding that the MBean dcependencies made ordering an extra and usless step... which is why it was removed from the original impl I commited. That was a mistake on my part and I put it back in... that said I think that we need to get back to a point where we can pull the sorting back and let the dependency system handle the details of ordering. I think we are close to a final (ok semi final) solution which will simplify the DS componets and allow for them to do more (like I descibed with DS peers + more). Lets just get this fixed. I think we have a good understanding of the problem. I think we have several options for solutions. Lets dig through the details find the solutuon and implement it. This is linked to the deployer re-design work that needs to be done, but I think it can be isolated and thus we can and should continue working on a solutuon for it now, while we settle the requirements for the next and hopfully close to last iteration on deploytment managment. You are really the lead for this, so let us know what the plan is... we really need this fixed. I think this is a 3.1 fix, so getting 3.0 out is probably a bit more important, assuming we are still planning to release that soon. --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: MBean attrib persistence was Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Also.. I think we need a way of feeding configuration change scripts into the server. For example, config snippets showing only the changed values for the mbeans. Furthermore eventually we should make this transactional... all changes succeed or you get back to your original state. david jencks On 2002.04.22 01:10:06 -0400 Jason Dillon wrote: > What is the hell about jboss-auto.jcml? Is it that you never quite know > what > config is used? If so, then all of these solutions will result in this > hell. > > Though some like it hot... and for them we can provid some abstraction to > > implement a file based persistence or jdbc or whatever. Then the input > xml > files are defaults which are used unless there is a value in the > attribute > store. > > If there is a way to inalidatye the store based on timestamps that would > be > good to... so if a user changes the file it will then override the bits > in the > store. > > --jason > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > The jmx part of this is the persistence service, which is pretty highly > > configurable. I think jbossmx has an xml-based persistence service > > implementation. I also think it works best with xmbeans or at least > > modelmbeans, another reason to migrate soon. So I think the technical > > issue of storing the mbean attribute values is done, more or less, > rather > > elegantly. I just don't want to get back to the jboss-auto.jcml hell, > and > > am wondering how to think about the problem. > > > > david jencks > > > > On 2002.04.21 21:17:32 -0400 Jason Dillon wrote: > > > Quick thought... if there was a pluggable interceptor in the config > > > service > > > which would filter values as well as some JMX interceptor that would > > > persist > > > attribute changes... > > > > > > Or even a pluggable interceptor around JMX attribute changes (for get > > > config > > > service, cause it will just invoke the server), then we could plug in > any > > > > > > given impl to provide what you are talking about. > > > > > > One that would say create jboss-auto.jcml-like files (only better > > > formatted so > > > we can read them), or a serialzed hashtable with values or a > database. > > > > > > There are some details wich need to be fleshed out, like what happens > > > when the > > > datastore has more values than the config file, how does the mbean > get > > > those > > > config notices. > > > > > > Is there any part of JMX what handles this... lets use it, make it > > > pluggbale, > > > if it isn't already, then provide one ore more impls and let users > choose > > > what > > > posion they eat. > > > > > > Personally I would disable it all and use the static files as the > > > definitive, > > > but others might like to boot up and then fiddle with the html > adapter > > > then > > > expect the changes to remain on reboot. > > > > > > Both are possible... > > > > > > Really, where are the JMX guys... is there something in JMX that buys > is > > > this > > > at ;little design cost? If not, what could we do to implement this? > I > > > think > > > this is easiest done at the jmx level... though it will probably have > to > > > be > > > something that can be described in jboss-service.xml as the first > > > component. > > > > > > --jason > > > > > > > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > > > > > Jason, thanks for trying to get this discussion back to something > > > useful. > > > > There's another thing I've mentioned a couple of times that I think > is > > > > relevant. > > > > > > > > What's the relationship between the initial config supplied by > > > > *-service.xml files and the possibly modified config in the mbean > > > server? > > > > If someone changes something in the running mbean server, what do > we > > > do? > > > > How persistent is the change? Where do we keep it? I think this is > part > > > of > > > > the same family of questions-- just a different time frame. > > > > > > > > -- how do you easily modify config before deployment > > > > > > > > -- how do you save config changes made to deployed apps. > > > > > > > > I don't have a good answer. I'm trying to think of the situation > like > > > a db > > > > -- deploying an mbean like an insert, modifying its config like > update. > > > > > > > Undeploy should be like delete, but shutting down a server and > > > restarting > > > > is like ? I think you should perhaps end up with the same > config > > > as > > > > you had before you shut down. But if _you_ change a config file, > > > should > > > > you have to undeploy and redeploy it to get the changes to stick? > I > > > don't > > > > know. > > > > > > > > Thanks > > > > david jencks > > > > > > > > > > > > On 2002.04.21 19:00:31 -0400 Jason Dillon wrote: > > > > > > don't be an ignorant bastard on your own idea and its actual > > > > > > implementation. > > > > > > > > > > Whatever dude... I am enlightened to users needs, to the needs of
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
On 2002.04.22 01:06:14 -0400 Jason Dillon wrote: > I am not sure what you mean. Can you explain more? > > --jason scanner1 looks at dir1 with jar1, jar2jar 100 in it scanner 2 looks at dir2 with jar101...jar200 in it. I haven't checked recently but I thought scanning happened in its own thread. scanner1 starts, new thread deploys jar1... scanner2 starts, new thread deploys jar101,jar102,jar103 thread 1 deploys jar2,jar3. thread2 finishes jar200 thread1 is still on jar50. If you have one scanner, they will be deployed in order 1...200. Maybe I am wrong about the threads. david jencks > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > I really hope I'm not throwing more fuel on any fires... > > > > If you have one scanner whose scanned directories can be ordered > > individually, you still get to specify the startup order of the > directories > > by how they are listed in the single scanner. > > > > With more than one scanner, this may be less deterministic, considering > > each scanner runs in a separate thread (is this true?). Maybe there's a > way > > out, I haven't thought of it. > > > > david jencks > > > > On 2002.04.21 21:09:09 -0400 Jason Dillon wrote: > > > > I want a distinction between directories to be scanned, and URLs to > be > > > > deployed. This goes back to an earlier patch (that I never checked > in) > > > for > > > > URLDeploymentScanner. If you specify a URL that is the base of an > > > exploded > > > > archive, then currently the scanner scans that directory. It > should, > > > > instead, deploy the directory. > > > > > > Right, so like I said before I think this should go into another > scanner. > > > > > > > The solution you presented at the time was to create an alternate > > > scanner > > > > for this purpose. I don't like that since it violates the concept > of > > > > exploded archives being treated just like their packaged > counterparts. > > > > > > What? No it does not at all. It is just the same, it is just a > matter > > > of > > > which scanner it came from. > > > > > > For example, if using a cache in between UDS and MD it now has to > know > > > how to > > > handle a directory... blah, screw that. > > > > > > Make a seperate scanner, perhaps if you must bring > > > DirectoryDeploymentScanner > > > back to life and put in all of your directory specific stuff. It has > no > > > business in UDS, perhaps even the bit for scanning a directory url > for > > > files > > > has no business in there. > > > > > > Please do not complicate UDS when you can create a simple alternative > DS > > > which > > > can be used in replacement or in conjunction with the UDS. > > > > > > The system is designed to take more than one DS for just this > reason... > > > to > > > allow for different scanning behavior. This is why I seperated the > > > common > > > scanning loop code into ADS. > > > > > > We do not want to get back into the monolithic component business > again. > > > > > > Design with plugablility then make use of it when you need new > > > functionality. > > > If required refactor the existing components to better seperate the > > > plugability... but don't go making simple components complicated when > you > > > > > > could have easily created a replacment or peer to gain the same > result. > > > > > > *sigh* > > > > > > --jason > > > > > > > > > - > > > This mail sent through IMP: http://horde.org/imp/ > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > - > This mail sent through IMP: http://horde.org/imp/ > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> Multiple scanners make it difficult at best to define deployment ordering. > URLDeploymentScanner is already written (by you, I might add) to handle two Thanks for reminding me of the obvious... > forms of deployment: Directory scanning and direct URL deployment. I am > trying very hard NOT to complicate this issue, but we do need a solution > for > exploded archives. You are trying very hard to implement exploded archives... which I personally have little need for. Granted it sounds usefull, but I don't think it should have been added to 3.0 this close to final... thus I think we should hold off, fix the deployment dependencies outside of the scanner (as was the assumption when I designed this level), then implement your exploded scanner as a peer to UDS. If you must add an explosed scanner now then subclass UDS and document how to replace UDS to gain this exploded behavior. I thought you said you were going to make sorting pluggable... why don't you just go do that and leave this issue for later? > The simplest at this point is to preserve the > functionality of URLDeploymentScanner, and that means make it understand > exploded archives. I think it would be simpiler to subclass, thus only complicating the config for the very small percentage of users who will use this. If I am wrong, fine we will have this fixced for 3.1 and then we will all be happy. > You call it a hack, and I agree. However, we already have a hacked system > that will hopefully be fixed shortly. This is a rather lame answer... lets hack it up more because it is hacked already? You don't work for microsoft do you? > Forcing me down the awkward path of > well architect code that must function within a design that has outlived > its > usefulness is not the right answer. Ic, so because your functionality does not fit into the DS design due to a problem with the deployment dependency system the DS design is now useless? And you would rather hackup a component in this flawed design rather than work on fixing the root of the problem... because you want to implement a feature that you are unwilling to put into a replacement component... blah > Let me hack this for now, and spend my > time on a better designed rewrite. If you want to add this, the make a subclass and put it there. Leave UDS as the default as it works as is. We are trying to get a final release out... which means we should not add frivoluos stuff to the core, just because we can. I don't want to hold you back from adding this functionality, as it does sound useful... but don't let it get in the way of the already working components. I agree there are some issues with the system as a whole, but we don't have the time to fix them such that DS peers will work... though if the dependencies are handled at a higher level, then all of this sorting timing crap is just nonsense. In fact I think that the URLComp* stuff is just another hack to make up for defficencies in the dependency system. * * * 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? --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
MBean attrib persistence was Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
What is the hell about jboss-auto.jcml? Is it that you never quite know what config is used? If so, then all of these solutions will result in this hell. Though some like it hot... and for them we can provid some abstraction to implement a file based persistence or jdbc or whatever. Then the input xml files are defaults which are used unless there is a value in the attribute store. If there is a way to inalidatye the store based on timestamps that would be good to... so if a user changes the file it will then override the bits in the store. --jason Quoting David Jencks <[EMAIL PROTECTED]>: > The jmx part of this is the persistence service, which is pretty highly > configurable. I think jbossmx has an xml-based persistence service > implementation. I also think it works best with xmbeans or at least > modelmbeans, another reason to migrate soon. So I think the technical > issue of storing the mbean attribute values is done, more or less, rather > elegantly. I just don't want to get back to the jboss-auto.jcml hell, and > am wondering how to think about the problem. > > david jencks > > On 2002.04.21 21:17:32 -0400 Jason Dillon wrote: > > Quick thought... if there was a pluggable interceptor in the config > > service > > which would filter values as well as some JMX interceptor that would > > persist > > attribute changes... > > > > Or even a pluggable interceptor around JMX attribute changes (for get > > config > > service, cause it will just invoke the server), then we could plug in any > > > > given impl to provide what you are talking about. > > > > One that would say create jboss-auto.jcml-like files (only better > > formatted so > > we can read them), or a serialzed hashtable with values or a database. > > > > There are some details wich need to be fleshed out, like what happens > > when the > > datastore has more values than the config file, how does the mbean get > > those > > config notices. > > > > Is there any part of JMX what handles this... lets use it, make it > > pluggbale, > > if it isn't already, then provide one ore more impls and let users choose > > what > > posion they eat. > > > > Personally I would disable it all and use the static files as the > > definitive, > > but others might like to boot up and then fiddle with the html adapter > > then > > expect the changes to remain on reboot. > > > > Both are possible... > > > > Really, where are the JMX guys... is there something in JMX that buys is > > this > > at ;little design cost? If not, what could we do to implement this? I > > think > > this is easiest done at the jmx level... though it will probably have to > > be > > something that can be described in jboss-service.xml as the first > > component. > > > > --jason > > > > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > > > Jason, thanks for trying to get this discussion back to something > > useful. > > > There's another thing I've mentioned a couple of times that I think is > > > relevant. > > > > > > What's the relationship between the initial config supplied by > > > *-service.xml files and the possibly modified config in the mbean > > server? > > > If someone changes something in the running mbean server, what do we > > do? > > > How persistent is the change? Where do we keep it? I think this is part > > of > > > the same family of questions-- just a different time frame. > > > > > > -- how do you easily modify config before deployment > > > > > > -- how do you save config changes made to deployed apps. > > > > > > I don't have a good answer. I'm trying to think of the situation like > > a db > > > -- deploying an mbean like an insert, modifying its config like update. > > > > > Undeploy should be like delete, but shutting down a server and > > restarting > > > is like ? I think you should perhaps end up with the same config > > as > > > you had before you shut down. But if _you_ change a config file, > > should > > > you have to undeploy and redeploy it to get the changes to stick? I > > don't > > > know. > > > > > > Thanks > > > david jencks > > > > > > > > > On 2002.04.21 19:00:31 -0400 Jason Dillon wrote: > > > > > don't be an ignorant bastard on your own idea and its actual > > > > > implementation. > > > > > > > > Whatever dude... I am enlightened to users needs, to the needs of IT > > > > professionsals who need ease of configuration managment... I am > > > > enlightened to > > > > the possibilities of creating a super system around JBoss which will > > > > dynamiclly generate xml configuration for anonymous hosts in a mega > > > > cluster. > > > > > > > > I am thinking outside the box, outside the archive... and trying to > > get > > > > the > > > > usage of .sar back on track to what those fucking birds were > > saying... > > > > which > > > > was seperation of code and configuration. > > > > > > > > My email suggested that each service archive contain some config to > > show > > > > what >
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> > The solution you presented at the time was to create an alternate scanner > > for this purpose. I don't like that since it violates the concept of > > exploded archives being treated just like their packaged counterparts. > > What? No it does not at all. It is just the same, it is just a matter of > which scanner it came from. > > yada-yada > > We do not want to get back into the monolithic component business again. > Design with plugablility then make use of it when you need new functionality. > If required refactor the existing components to better seperate the > plugability... but don't go making simple components complicated when you > could have easily created a replacment or peer to gain the same result. Multiple scanners make it difficult at best to define deployment ordering. URLDeploymentScanner is already written (by you, I might add) to handle two forms of deployment: Directory scanning and direct URL deployment. I am trying very hard NOT to complicate this issue, but we do need a solution for exploded archives. The simplest at this point is to preserve the functionality of URLDeploymentScanner, and that means make it understand exploded archives. You call it a hack, and I agree. However, we already have a hacked system that will hopefully be fixed shortly. Forcing me down the awkward path of well architect code that must function within a design that has outlived its usefulness is not the right answer. Let me hack this for now, and spend my time on a better designed rewrite. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I am not sure what you mean. Can you explain more? --jason Quoting David Jencks <[EMAIL PROTECTED]>: > I really hope I'm not throwing more fuel on any fires... > > If you have one scanner whose scanned directories can be ordered > individually, you still get to specify the startup order of the directories > by how they are listed in the single scanner. > > With more than one scanner, this may be less deterministic, considering > each scanner runs in a separate thread (is this true?). Maybe there's a way > out, I haven't thought of it. > > david jencks > > On 2002.04.21 21:09:09 -0400 Jason Dillon wrote: > > > I want a distinction between directories to be scanned, and URLs to be > > > deployed. This goes back to an earlier patch (that I never checked in) > > for > > > URLDeploymentScanner. If you specify a URL that is the base of an > > exploded > > > archive, then currently the scanner scans that directory. It should, > > > instead, deploy the directory. > > > > Right, so like I said before I think this should go into another scanner. > > > > > The solution you presented at the time was to create an alternate > > scanner > > > for this purpose. I don't like that since it violates the concept of > > > exploded archives being treated just like their packaged counterparts. > > > > What? No it does not at all. It is just the same, it is just a matter > > of > > which scanner it came from. > > > > For example, if using a cache in between UDS and MD it now has to know > > how to > > handle a directory... blah, screw that. > > > > Make a seperate scanner, perhaps if you must bring > > DirectoryDeploymentScanner > > back to life and put in all of your directory specific stuff. It has no > > business in UDS, perhaps even the bit for scanning a directory url for > > files > > has no business in there. > > > > Please do not complicate UDS when you can create a simple alternative DS > > which > > can be used in replacement or in conjunction with the UDS. > > > > The system is designed to take more than one DS for just this reason... > > to > > allow for different scanning behavior. This is why I seperated the > > common > > scanning loop code into ADS. > > > > We do not want to get back into the monolithic component business again. > > > > Design with plugablility then make use of it when you need new > > functionality. > > If required refactor the existing components to better seperate the > > plugability... but don't go making simple components complicated when you > > > > could have easily created a replacment or peer to gain the same result. > > > > *sigh* > > > > --jason > > > > > > - > > This mail sent through IMP: http://horde.org/imp/ > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
The jmx part of this is the persistence service, which is pretty highly configurable. I think jbossmx has an xml-based persistence service implementation. I also think it works best with xmbeans or at least modelmbeans, another reason to migrate soon. So I think the technical issue of storing the mbean attribute values is done, more or less, rather elegantly. I just don't want to get back to the jboss-auto.jcml hell, and am wondering how to think about the problem. david jencks On 2002.04.21 21:17:32 -0400 Jason Dillon wrote: > Quick thought... if there was a pluggable interceptor in the config > service > which would filter values as well as some JMX interceptor that would > persist > attribute changes... > > Or even a pluggable interceptor around JMX attribute changes (for get > config > service, cause it will just invoke the server), then we could plug in any > > given impl to provide what you are talking about. > > One that would say create jboss-auto.jcml-like files (only better > formatted so > we can read them), or a serialzed hashtable with values or a database. > > There are some details wich need to be fleshed out, like what happens > when the > datastore has more values than the config file, how does the mbean get > those > config notices. > > Is there any part of JMX what handles this... lets use it, make it > pluggbale, > if it isn't already, then provide one ore more impls and let users choose > what > posion they eat. > > Personally I would disable it all and use the static files as the > definitive, > but others might like to boot up and then fiddle with the html adapter > then > expect the changes to remain on reboot. > > Both are possible... > > Really, where are the JMX guys... is there something in JMX that buys is > this > at ;little design cost? If not, what could we do to implement this? I > think > this is easiest done at the jmx level... though it will probably have to > be > something that can be described in jboss-service.xml as the first > component. > > --jason > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > Jason, thanks for trying to get this discussion back to something > useful. > > There's another thing I've mentioned a couple of times that I think is > > relevant. > > > > What's the relationship between the initial config supplied by > > *-service.xml files and the possibly modified config in the mbean > server? > > If someone changes something in the running mbean server, what do we > do? > > How persistent is the change? Where do we keep it? I think this is part > of > > the same family of questions-- just a different time frame. > > > > -- how do you easily modify config before deployment > > > > -- how do you save config changes made to deployed apps. > > > > I don't have a good answer. I'm trying to think of the situation like > a db > > -- deploying an mbean like an insert, modifying its config like update. > > > Undeploy should be like delete, but shutting down a server and > restarting > > is like ? I think you should perhaps end up with the same config > as > > you had before you shut down. But if _you_ change a config file, > should > > you have to undeploy and redeploy it to get the changes to stick? I > don't > > know. > > > > Thanks > > david jencks > > > > > > On 2002.04.21 19:00:31 -0400 Jason Dillon wrote: > > > > don't be an ignorant bastard on your own idea and its actual > > > > implementation. > > > > > > Whatever dude... I am enlightened to users needs, to the needs of IT > > > professionsals who need ease of configuration managment... I am > > > enlightened to > > > the possibilities of creating a super system around JBoss which will > > > dynamiclly generate xml configuration for anonymous hosts in a mega > > > cluster. > > > > > > I am thinking outside the box, outside the archive... and trying to > get > > > the > > > usage of .sar back on track to what those fucking birds were > saying... > > > which > > > was seperation of code and configuration. > > > > > > My email suggested that each service archive contain some config to > show > > > what > > > classes of services were provided by it. So taking the jetty example > it > > > might > > > have a list like [ "JettyService" ]. Then an *external* > configuration > > > system > > > (be it xml, database, whatever) could be used to create an instance > of > > > that > > > service. > > > > > > If say you have a database which stores this information you might > then > > > create > > > a configuration entry name "MyJettyService", which is linked to > > > the "JettyService" by name and has a text field for storing the > actual > > > xml > > > config. > > > > > > When the system starts up it loads archives, finds the > jetty-plugin.sar > > > parses > > > its descriptor, finds out that there is a "JettyService" service > class in > > > > > > here, then asks the ConfigurationService for all configs for > > > "JettyService" > >
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I really hope I'm not throwing more fuel on any fires... If you have one scanner whose scanned directories can be ordered individually, you still get to specify the startup order of the directories by how they are listed in the single scanner. With more than one scanner, this may be less deterministic, considering each scanner runs in a separate thread (is this true?). Maybe there's a way out, I haven't thought of it. david jencks On 2002.04.21 21:09:09 -0400 Jason Dillon wrote: > > I want a distinction between directories to be scanned, and URLs to be > > deployed. This goes back to an earlier patch (that I never checked in) > for > > URLDeploymentScanner. If you specify a URL that is the base of an > exploded > > archive, then currently the scanner scans that directory. It should, > > instead, deploy the directory. > > Right, so like I said before I think this should go into another scanner. > > > The solution you presented at the time was to create an alternate > scanner > > for this purpose. I don't like that since it violates the concept of > > exploded archives being treated just like their packaged counterparts. > > What? No it does not at all. It is just the same, it is just a matter > of > which scanner it came from. > > For example, if using a cache in between UDS and MD it now has to know > how to > handle a directory... blah, screw that. > > Make a seperate scanner, perhaps if you must bring > DirectoryDeploymentScanner > back to life and put in all of your directory specific stuff. It has no > business in UDS, perhaps even the bit for scanning a directory url for > files > has no business in there. > > Please do not complicate UDS when you can create a simple alternative DS > which > can be used in replacement or in conjunction with the UDS. > > The system is designed to take more than one DS for just this reason... > to > allow for different scanning behavior. This is why I seperated the > common > scanning loop code into ADS. > > We do not want to get back into the monolithic component business again. > > Design with plugablility then make use of it when you need new > functionality. > If required refactor the existing components to better seperate the > plugability... but don't go making simple components complicated when you > > could have easily created a replacment or peer to gain the same result. > > *sigh* > > --jason > > > - > This mail sent through IMP: http://horde.org/imp/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Quick thought... if there was a pluggable interceptor in the config service which would filter values as well as some JMX interceptor that would persist attribute changes... Or even a pluggable interceptor around JMX attribute changes (for get config service, cause it will just invoke the server), then we could plug in any given impl to provide what you are talking about. One that would say create jboss-auto.jcml-like files (only better formatted so we can read them), or a serialzed hashtable with values or a database. There are some details wich need to be fleshed out, like what happens when the datastore has more values than the config file, how does the mbean get those config notices. Is there any part of JMX what handles this... lets use it, make it pluggbale, if it isn't already, then provide one ore more impls and let users choose what posion they eat. Personally I would disable it all and use the static files as the definitive, but others might like to boot up and then fiddle with the html adapter then expect the changes to remain on reboot. Both are possible... Really, where are the JMX guys... is there something in JMX that buys is this at ;little design cost? If not, what could we do to implement this? I think this is easiest done at the jmx level... though it will probably have to be something that can be described in jboss-service.xml as the first component. --jason Quoting David Jencks <[EMAIL PROTECTED]>: > Jason, thanks for trying to get this discussion back to something useful. > There's another thing I've mentioned a couple of times that I think is > relevant. > > What's the relationship between the initial config supplied by > *-service.xml files and the possibly modified config in the mbean server? > If someone changes something in the running mbean server, what do we do? > How persistent is the change? Where do we keep it? I think this is part of > the same family of questions-- just a different time frame. > > -- how do you easily modify config before deployment > > -- how do you save config changes made to deployed apps. > > I don't have a good answer. I'm trying to think of the situation like a db > -- deploying an mbean like an insert, modifying its config like update. > Undeploy should be like delete, but shutting down a server and restarting > is like ? I think you should perhaps end up with the same config as > you had before you shut down. But if _you_ change a config file, should > you have to undeploy and redeploy it to get the changes to stick? I don't > know. > > Thanks > david jencks > > > On 2002.04.21 19:00:31 -0400 Jason Dillon wrote: > > > don't be an ignorant bastard on your own idea and its actual > > > implementation. > > > > Whatever dude... I am enlightened to users needs, to the needs of IT > > professionsals who need ease of configuration managment... I am > > enlightened to > > the possibilities of creating a super system around JBoss which will > > dynamiclly generate xml configuration for anonymous hosts in a mega > > cluster. > > > > I am thinking outside the box, outside the archive... and trying to get > > the > > usage of .sar back on track to what those fucking birds were saying... > > which > > was seperation of code and configuration. > > > > My email suggested that each service archive contain some config to show > > what > > classes of services were provided by it. So taking the jetty example it > > might > > have a list like [ "JettyService" ]. Then an *external* configuration > > system > > (be it xml, database, whatever) could be used to create an instance of > > that > > service. > > > > If say you have a database which stores this information you might then > > create > > a configuration entry name "MyJettyService", which is linked to > > the "JettyService" by name and has a text field for storing the actual > > xml > > config. > > > > When the system starts up it loads archives, finds the jetty-plugin.sar > > parses > > its descriptor, finds out that there is a "JettyService" service class in > > > > here, then asks the ConfigurationService for all configs for > > "JettyService" > > and starts up each instance it has. > > > > Now this isn't an ideal design, nor was the original months back, but one > > of > > the core concepts was seperation of configuration... or rather seperation > > of > > service instance configuration. > > > > Clearly we have lost that direction... which is why I wrote this thread > > and is > > why I have continued to respond trying to communicate why it is better > > for > > this seperation to exist and why we should ship our product with config > > seperated by default. > > > > * * * > > > > > |Take Jetty for example. I am a user and I want to change the > > > |port, or enable SSL or add a non-deployed webapp for > > > |development... how do I do that? I have to break open the > > > |jetty-plugin.sar, change jboss-service.xml, rejar it, then
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> I want a distinction between directories to be scanned, and URLs to be > deployed. This goes back to an earlier patch (that I never checked in) for > URLDeploymentScanner. If you specify a URL that is the base of an exploded > archive, then currently the scanner scans that directory. It should, > instead, deploy the directory. Right, so like I said before I think this should go into another scanner. > The solution you presented at the time was to create an alternate scanner > for this purpose. I don't like that since it violates the concept of > exploded archives being treated just like their packaged counterparts. What? No it does not at all. It is just the same, it is just a matter of which scanner it came from. For example, if using a cache in between UDS and MD it now has to know how to handle a directory... blah, screw that. Make a seperate scanner, perhaps if you must bring DirectoryDeploymentScanner back to life and put in all of your directory specific stuff. It has no business in UDS, perhaps even the bit for scanning a directory url for files has no business in there. Please do not complicate UDS when you can create a simple alternative DS which can be used in replacement or in conjunction with the UDS. The system is designed to take more than one DS for just this reason... to allow for different scanning behavior. This is why I seperated the common scanning loop code into ADS. We do not want to get back into the monolithic component business again. Design with plugablility then make use of it when you need new functionality. If required refactor the existing components to better seperate the plugability... but don't go making simple components complicated when you could have easily created a replacment or peer to gain the same result. *sigh* --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Jason, thanks for trying to get this discussion back to something useful. There's another thing I've mentioned a couple of times that I think is relevant. What's the relationship between the initial config supplied by *-service.xml files and the possibly modified config in the mbean server? If someone changes something in the running mbean server, what do we do? How persistent is the change? Where do we keep it? I think this is part of the same family of questions-- just a different time frame. -- how do you easily modify config before deployment -- how do you save config changes made to deployed apps. I don't have a good answer. I'm trying to think of the situation like a db -- deploying an mbean like an insert, modifying its config like update. Undeploy should be like delete, but shutting down a server and restarting is like ? I think you should perhaps end up with the same config as you had before you shut down. But if _you_ change a config file, should you have to undeploy and redeploy it to get the changes to stick? I don't know. Thanks david jencks On 2002.04.21 19:00:31 -0400 Jason Dillon wrote: > > don't be an ignorant bastard on your own idea and its actual > > implementation. > > Whatever dude... I am enlightened to users needs, to the needs of IT > professionsals who need ease of configuration managment... I am > enlightened to > the possibilities of creating a super system around JBoss which will > dynamiclly generate xml configuration for anonymous hosts in a mega > cluster. > > I am thinking outside the box, outside the archive... and trying to get > the > usage of .sar back on track to what those fucking birds were saying... > which > was seperation of code and configuration. > > My email suggested that each service archive contain some config to show > what > classes of services were provided by it. So taking the jetty example it > might > have a list like [ "JettyService" ]. Then an *external* configuration > system > (be it xml, database, whatever) could be used to create an instance of > that > service. > > If say you have a database which stores this information you might then > create > a configuration entry name "MyJettyService", which is linked to > the "JettyService" by name and has a text field for storing the actual > xml > config. > > When the system starts up it loads archives, finds the jetty-plugin.sar > parses > its descriptor, finds out that there is a "JettyService" service class in > > here, then asks the ConfigurationService for all configs for > "JettyService" > and starts up each instance it has. > > Now this isn't an ideal design, nor was the original months back, but one > of > the core concepts was seperation of configuration... or rather seperation > of > service instance configuration. > > Clearly we have lost that direction... which is why I wrote this thread > and is > why I have continued to respond trying to communicate why it is better > for > this seperation to exist and why we should ship our product with config > seperated by default. > > * * * > > > |Take Jetty for example. I am a user and I want to change the > > |port, or enable SSL or add a non-deployed webapp for > > |development... how do I do that? I have to break open the > > |jetty-plugin.sar, change jboss-service.xml, rejar it, then > > |redeploy. What a huge pain in the ass! > > > > wow, which means it is the first time you use that (remember the mails > from > > Bill/me about 6 month ago?) and we already have a solution > > No I don't remeber the emails... is there a link in the forum? > > > just drop the jboss-service.xml in deploy > > reference the jar that has the file in the classpath of the service.xml > > they will be deployed as independent jar (and cycled accordingly) > > BUT MY POINT IS that we should ship like this BY DEFAULT... it is EASIER > and > SIMPILER for users to change the config... the alternative is only more > complicated. > > Shipping components like this vilotates your beloved K.I.S.S. > principle... > unless you mean to say that we won't expect users to change the config at > > all... but that is just plain ignorance. > > > |I think that the concept of a SAR is still useful and we should > > |not cast it aside, but there are some limited cases where we would use > > one. > > > > As Frederick Brier pointed out in response to this, it is useful for > > shipping self-contained configuration of beans. End of story, very > useful, > > get off the wanking box. + all the examples you give below. > > Yes, it is useflu I am not arguing that is isn't... I think that it would > be > better to have them cleanly seperated, but if you want them all in one, > then > go for it... (see BUT MY POINT IS) > > > |For example, SAR is good for grouping like .jar's together. There > > |are several jars needed for Jetty to work, and it makes sence to > > |group them together inside of a super archive. When used in this > >
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I want a distinction between directories to be scanned, and URLs to be deployed. This goes back to an earlier patch (that I never checked in) for URLDeploymentScanner. If you specify a URL that is the base of an exploded archive, then currently the scanner scans that directory. It should, instead, deploy the directory. The solution you presented at the time was to create an alternate scanner for this purpose. I don't like that since it violates the concept of exploded archives being treated just like their packaged counterparts. -Larry > Why? > > --jason > > > > OK - Any objections if I implement David's proposed URL configuration > > format: > > > > > > > > > > > > > > -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Why? --jason Quoting Larry Sanderson <[EMAIL PROTECTED]>: > > Yes. The current UDS has a hacked sorting blah (which I was not found > of, > but > > is required for the system to work as it stands now). If you want to > make > the > > URLCompa* change to make this optional and pluggable then go for it. I > would > > leave the default J/E/W/S comparitor in the default config though. > > > > Yes, please do... this will simplify UDS... perhaps while you are at it > you > > can also implement some regex based filters? So we can ignore scanning > dot > > files and such. > > > > Perhaps a pluggable URLFilter, and a RegexURLFilter impl? > > > > OK - Any objections if I implement David's proposed URL configuration > format: > > > > > > > -Larry > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> Yes. The current UDS has a hacked sorting blah (which I was not found of, but > is required for the system to work as it stands now). If you want to make the > URLCompa* change to make this optional and pluggable then go for it. I would > leave the default J/E/W/S comparitor in the default config though. > > Yes, please do... this will simplify UDS... perhaps while you are at it you > can also implement some regex based filters? So we can ignore scanning dot > files and such. > > Perhaps a pluggable URLFilter, and a RegexURLFilter impl? > OK - Any objections if I implement David's proposed URL configuration format: -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I think the claims of this being requested by users are suspect. Marc presented some alternatives in the London training, and this one won a vote. I don't think that means anyone asked for it or would find it useful. It means it looked good after Marc's presentation. Anyway, I think there is a real bug nearby that we need to fix. See http://jboss.org/forums/thread.jsp?forum=46&thread=13456&start=0&msRange=15 (hope the link works) If a jar file references a nonexistent jar file in the manifest classpath entry, something (the scanner???) goes haywire and keeps trying to deploy the ./deploy directory as if it is a package. Presumably there is a missing existence check somewhere. Larry, you into looking at this? thanks david jencks On 2002.04.21 18:44:37 -0400 Larry Sanderson wrote: > > This is insanity... how is renumbering your deployment files > > simipler/easier/faster/better than opening up a config file and listing > the > > order there? > > There is already a hacked sorting in the URLDeploymentScanner... but it > stops at extension comparison. This proposition extends that just a > little > to give the users more control and more choices (with this, > configuration-phobes would not have to modify the config file). Maybe it > is > not useful to everyone (I'm positive that I will not need this in my > current > job), but Marc has mentioned that many users did express this as a need. > I > don't really care, but if you want it, I am willing to do it. > > -Larry > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I agree, lets get a real use case then see what the simplest solution is. In the mean time I don't see any reason not to make this pluggable, so that users can come up with any arbitrary complexity for deployment scanning which they have a jones for as long as we leave the default config setup as the UDS is now. --jason Quoting David Jencks <[EMAIL PROTECTED]>: > 1. I think marc wanted the numbers at the beginning > 1myjar.jar > 2mysar.sar > 3myear.jar > etc. > > 2. I don't think mixing ordering schemes within 1 directory has any chance > of working. > > 3. I'd like to have an actual user ask for this over explicitly listing the > files in the deployment scanner. > > david jencks > > On 2002.04.21 18:09:45 -0400 Larry Sanderson wrote: > > I *really* don't like jar1.jar, sar2.sar. Let's make the naming > > convention > > a little less likely to stumbled upon by unknowing users. I suggest: > > jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for > > "indexed" deployments first, and sort the remainder by type. This allows > > a > > simple, global comparator, but removes the fine-grained support you > > suggest. > > So given the following within a directory: > > > > jetty.sar > > my_ejb_ver4.jar > > jar_jb5.jar > > sar_jb10.sar > > > > This would order them thus: > > jar_jb5.jar <-- all "indexed" deployments first > > sar_jb10.sar > > jetty.sar <-- all others second, in order of sar,rar,jar,war,ear > > my_ejb_ver4.jar > > > > Hell, if they really need the flexibility you suggest then they can set > > up a > > second scanner, but I can't imagine any place where this is not > > sufficient. > > > > -Larry > > > > > I'm not sure specifying the global sorter for a whole scanner is the > > way > > we > > > want to go... on the other hand extensibility is nice... Do we want to > > > encourage people to have lots of scanners? > > > > > > At the risk of making things more complicated than necessary, yet > > striving > > > for simplicity, how about > > > > > >> > name="jboss.deployment:type=DeploymentScanner,flavor=URL"> > > > > > > > > > 5000 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > optional-attribute-name="Deployer">jboss.system:service=MainDeployer > s> > > > > > > > > > > > > > > > > name="jboss.deployment:type=DeploymentSorter,order=type"/> > > > > name="jboss.deployment:type=DeploymentSorter,order=lexical/> > > > > > > The deployment scanner looks up the requested ordering using the naming > > > pattern on the DeploymentSorter mbeans. > > > > > > I'm not sure if we really need explicit dependencies listed in the > > > DeploymentScanner. > > > > > > Striving towards simplicity (believe it or not;-) > > > > > > david jencks > > > > > > > > > On 2002.04.21 16:37:46 -0400 Larry Sanderson wrote: > > > > > As larry said (do you have rw yet?) > > > > > > > > Yup. I've already checked in at least one bug :-) > > > > > > > > > let's not shove it down people's throat > > > > > and let's document all of this. Case closed. Implementation needed > > :) > > > > > > > > Simple, and not too hacked implementation: > > > > > > > > Add MBean attribute to URLDeploymentScanner: URLComparator > > > > make default comparator point to: > > org.jboss.deployment.DeploymentSorter > > > > (make this a comparator that does the correct ordering) > > > > in scanDirectory, change: list = sorter.sortURLs(list); > > > > to: if (urlComparator != null) Collections.sort(list, > > urlComparator); > > > > > > > > This allows users unhappy with the ordering scheme to replace it with > > > > their > > > > own Comparator (or simply drop it to remove all ordering). If this > > > > sounds > > > > OK, I am mucking about in that code anyway. Would you like me to > > make > > > > these > > > > changes? > > > > > > > > -Larry > > > > > > > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Yes. The current UDS has a hacked sorting blah (which I was not found of, but is required for the system to work as it stands now). If you want to make the URLCompa* change to make this optional and pluggable then go for it. I would leave the default J/E/W/S comparitor in the default config though. Yes, please do... this will simplify UDS... perhaps while you are at it you can also implement some regex based filters? So we can ignore scanning dot files and such. Perhaps a pluggable URLFilter, and a RegexURLFilter impl? --jason Quoting Larry Sanderson <[EMAIL PROTECTED]>: > > This is insanity... how is renumbering your deployment files > > simipler/easier/faster/better than opening up a config file and listing > the > > order there? > > There is already a hacked sorting in the URLDeploymentScanner... but it > stops at extension comparison. This proposition extends that just a little > to give the users more control and more choices (with this, > configuration-phobes would not have to modify the config file). Maybe it > is > not useful to everyone (I'm positive that I will not need this in my > current > job), but Marc has mentioned that many users did express this as a need. I > don't really care, but if you want it, I am willing to do it. > > -Larry > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
1. I think marc wanted the numbers at the beginning 1myjar.jar 2mysar.sar 3myear.jar etc. 2. I don't think mixing ordering schemes within 1 directory has any chance of working. 3. I'd like to have an actual user ask for this over explicitly listing the files in the deployment scanner. david jencks On 2002.04.21 18:09:45 -0400 Larry Sanderson wrote: > I *really* don't like jar1.jar, sar2.sar. Let's make the naming > convention > a little less likely to stumbled upon by unknowing users. I suggest: > jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for > "indexed" deployments first, and sort the remainder by type. This allows > a > simple, global comparator, but removes the fine-grained support you > suggest. > So given the following within a directory: > > jetty.sar > my_ejb_ver4.jar > jar_jb5.jar > sar_jb10.sar > > This would order them thus: > jar_jb5.jar <-- all "indexed" deployments first > sar_jb10.sar > jetty.sar <-- all others second, in order of sar,rar,jar,war,ear > my_ejb_ver4.jar > > Hell, if they really need the flexibility you suggest then they can set > up a > second scanner, but I can't imagine any place where this is not > sufficient. > > -Larry > > > I'm not sure specifying the global sorter for a whole scanner is the > way > we > > want to go... on the other hand extensibility is nice... Do we want to > > encourage people to have lots of scanners? > > > > At the risk of making things more complicated than necessary, yet > striving > > for simplicity, how about > > > >> name="jboss.deployment:type=DeploymentScanner,flavor=URL"> > > > > > > 5000 > > > > > > > > > > > > > > > > > > > > > > > > > > > > optional-attribute-name="Deployer">jboss.system:service=MainDeployer s> > > > > > > > > > > name="jboss.deployment:type=DeploymentSorter,order=type"/> > > name="jboss.deployment:type=DeploymentSorter,order=lexical/> > > > > The deployment scanner looks up the requested ordering using the naming > > pattern on the DeploymentSorter mbeans. > > > > I'm not sure if we really need explicit dependencies listed in the > > DeploymentScanner. > > > > Striving towards simplicity (believe it or not;-) > > > > david jencks > > > > > > On 2002.04.21 16:37:46 -0400 Larry Sanderson wrote: > > > > As larry said (do you have rw yet?) > > > > > > Yup. I've already checked in at least one bug :-) > > > > > > > let's not shove it down people's throat > > > > and let's document all of this. Case closed. Implementation needed > :) > > > > > > Simple, and not too hacked implementation: > > > > > > Add MBean attribute to URLDeploymentScanner: URLComparator > > > make default comparator point to: > org.jboss.deployment.DeploymentSorter > > > (make this a comparator that does the correct ordering) > > > in scanDirectory, change: list = sorter.sortURLs(list); > > > to: if (urlComparator != null) Collections.sort(list, > urlComparator); > > > > > > This allows users unhappy with the ordering scheme to replace it with > > > their > > > own Comparator (or simply drop it to remove all ordering). If this > > > sounds > > > OK, I am mucking about in that code anyway. Would you like me to > make > > > these > > > changes? > > > > > > -Larry > > > > > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> don't be an ignorant bastard on your own idea and its actual > implementation. Whatever dude... I am enlightened to users needs, to the needs of IT professionsals who need ease of configuration managment... I am enlightened to the possibilities of creating a super system around JBoss which will dynamiclly generate xml configuration for anonymous hosts in a mega cluster. I am thinking outside the box, outside the archive... and trying to get the usage of .sar back on track to what those fucking birds were saying... which was seperation of code and configuration. My email suggested that each service archive contain some config to show what classes of services were provided by it. So taking the jetty example it might have a list like [ "JettyService" ]. Then an *external* configuration system (be it xml, database, whatever) could be used to create an instance of that service. If say you have a database which stores this information you might then create a configuration entry name "MyJettyService", which is linked to the "JettyService" by name and has a text field for storing the actual xml config. When the system starts up it loads archives, finds the jetty-plugin.sar parses its descriptor, finds out that there is a "JettyService" service class in here, then asks the ConfigurationService for all configs for "JettyService" and starts up each instance it has. Now this isn't an ideal design, nor was the original months back, but one of the core concepts was seperation of configuration... or rather seperation of service instance configuration. Clearly we have lost that direction... which is why I wrote this thread and is why I have continued to respond trying to communicate why it is better for this seperation to exist and why we should ship our product with config seperated by default. * * * > |Take Jetty for example. I am a user and I want to change the > |port, or enable SSL or add a non-deployed webapp for > |development... how do I do that? I have to break open the > |jetty-plugin.sar, change jboss-service.xml, rejar it, then > |redeploy. What a huge pain in the ass! > > wow, which means it is the first time you use that (remember the mails from > Bill/me about 6 month ago?) and we already have a solution No I don't remeber the emails... is there a link in the forum? > just drop the jboss-service.xml in deploy > reference the jar that has the file in the classpath of the service.xml > they will be deployed as independent jar (and cycled accordingly) BUT MY POINT IS that we should ship like this BY DEFAULT... it is EASIER and SIMPILER for users to change the config... the alternative is only more complicated. Shipping components like this vilotates your beloved K.I.S.S. principle... unless you mean to say that we won't expect users to change the config at all... but that is just plain ignorance. > |I think that the concept of a SAR is still useful and we should > |not cast it aside, but there are some limited cases where we would use > one. > > As Frederick Brier pointed out in response to this, it is useful for > shipping self-contained configuration of beans. End of story, very useful, > get off the wanking box. + all the examples you give below. Yes, it is useflu I am not arguing that is isn't... I think that it would be better to have them cleanly seperated, but if you want them all in one, then go for it... (see BUT MY POINT IS) > |For example, SAR is good for grouping like .jar's together. There > |are several jars needed for Jetty to work, and it makes sence to > |group them together inside of a super archive. When used in this > |manner it makes it easy to create an explicit classload hierachy > |(when we have that capability). > | > |SAR is also good if you want to distribute a set of native > |libraries. In this usage you would put in a version of the lib > |for all supported platforms. > | > |SAR is good to provide a static filesystem, or the intial > |structure for a dynamic filesystem which is needed. > > Jason WTF are you doing, are you trying the negative publicity thing to > remind the group that the idea was yours and that it works??? why this > email. Whatever... I don't need to stoop to such levels to boost my ego... and if I did this would have been a rather backassward method todo so. I believe that we can make the system better, more managable & more coherent by keeping the seperation clean. I want to help move the core system in positive directions, which is why I wrote the email, not to remind anyone of anything. > |Serivce config MUST be seperate from the archives. This is a huge > |defficeny with the EJB-JAR, EAR & WAR formats from SUN. While it > |was a good idea to group the support files, it plain sucks ass to > |put the config in there too. > > IT IS ALREADY SEE ABOVE, SEE MY MAILS FROM THE BILL THREAD ON THE > "PACKAGING > NIGHTMARE"... GEEZUS No it isn't... not in the downloadable from SF.NET. Go download t
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> This is insanity... how is renumbering your deployment files > simipler/easier/faster/better than opening up a config file and listing the > order there? There is already a hacked sorting in the URLDeploymentScanner... but it stops at extension comparison. This proposition extends that just a little to give the users more control and more choices (with this, configuration-phobes would not have to modify the config file). Maybe it is not useful to everyone (I'm positive that I will not need this in my current job), but Marc has mentioned that many users did express this as a need. I don't really care, but if you want it, I am willing to do it. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Ok this is more insanity... who was it that thought that renaming files as the simiplest solution to ordering? Right and I am a goat "moo moo". It works as it is right now... leave it alone. There is no need for prefixed sorting or this cryptix semi-suffix sorting blah. If users want this maddness then implement a pluggable sorter/whatever and let the users complicate there lives. Lets not go renaming everything though just to meet this rather ridiculous rtequiremnt that Marc is demanding. Look at where this is going to be useful, who is going to be using it and what percentage of those users in those situations will need to make use of it to get around deployment problems. The pecentage is going to be very, very low... so why go changing a system that works? Especiall close to a final release... this is just plain madness. --jason Quoting Larry Sanderson <[EMAIL PROTECTED]>: > I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention > a little less likely to stumbled upon by unknowing users. I suggest: > jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for > "indexed" deployments first, and sort the remainder by type. This allows a > simple, global comparator, but removes the fine-grained support you > suggest. > So given the following within a directory: > > jetty.sar > my_ejb_ver4.jar > jar_jb5.jar > sar_jb10.sar > > This would order them thus: > jar_jb5.jar <-- all "indexed" deployments first > sar_jb10.sar > jetty.sar <-- all others second, in order of sar,rar,jar,war,ear > my_ejb_ver4.jar > > Hell, if they really need the flexibility you suggest then they can set up > a > second scanner, but I can't imagine any place where this is not sufficient. > > -Larry - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
This is insanity... how is renumbering your deployment files simipler/easier/faster/better than opening up a config file and listing the order there? How? --jason > I agree, so let's drop it. I want the simplest numbering available > 'UNIX-styleee' and for more advanced (read have time) then the xml based > deployer ordering. - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention a little less likely to stumbled upon by unknowing users. I suggest: jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for "indexed" deployments first, and sort the remainder by type. This allows a simple, global comparator, but removes the fine-grained support you suggest. So given the following within a directory: jetty.sar my_ejb_ver4.jar jar_jb5.jar sar_jb10.sar This would order them thus: jar_jb5.jar <-- all "indexed" deployments first sar_jb10.sar jetty.sar <-- all others second, in order of sar,rar,jar,war,ear my_ejb_ver4.jar Hell, if they really need the flexibility you suggest then they can set up a second scanner, but I can't imagine any place where this is not sufficient. -Larry > I'm not sure specifying the global sorter for a whole scanner is the way we > want to go... on the other hand extensibility is nice... Do we want to > encourage people to have lots of scanners? > > At the risk of making things more complicated than necessary, yet striving > for simplicity, how about > >name="jboss.deployment:type=DeploymentScanner,flavor=URL"> > > > 5000 > > > > > > > > > > > > > > jboss.system:service=MainDeployer > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I thought we discussed this before, where it was agreed that the simple solution was to have users explicitly list the users in the order they wanted rather than implement another sorting system in UDS. We already sort using DeploymentSorter (J/E/W/S as you called it), addinf this prefix numbering sort will just make it more complicated. Drop it already. --jason Quoting marc fleury <[EMAIL PROTECTED]>: > Ok you guys just talk without end and the simplest solution is still not > done, > > I will have to do it just so that we have something that works. > > Just pisses me off > > marcf > > |-Original Message- > |From: David Jencks [mailto:[EMAIL PROTECTED]] > |Sent: Sunday, April 21, 2002 9:45 AM > |To: marc fleury > |Cc: [EMAIL PROTECTED] > |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ? > | > | > | > |> Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING OF > |> DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER. > |> > |> If I do 01first.sar and 02second.war do I get 01 first and 02 second? > |> > |> YES=NO > |> > |> ? > | > | > |umm YES != No > | > |the answer is NO > | > |If you want deployments in a specific order list them in that order in the > |deployment scanner mbean. Otherwise we get into nonsense about conflicts > |between packaged type order and explicit alphabetical order --> you are > |forced to use alphabetical order even if you don't need it. Alphabetical > |order might look nice at first but it is really bad IMO. > | > |remember mbeans wait for their classes now... solves a lot of ordering > |problems. > | > |david jencks > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I'm not sure specifying the global sorter for a whole scanner is the way we want to go... on the other hand extensibility is nice... Do we want to encourage people to have lots of scanners? At the risk of making things more complicated than necessary, yet striving for simplicity, how about 5000 jboss.system:service=MainDeployer https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> As larry said (do you have rw yet?) Yup. I've already checked in at least one bug :-) > let's not shove it down people's throat > and let's document all of this. Case closed. Implementation needed :) Simple, and not too hacked implementation: Add MBean attribute to URLDeploymentScanner: URLComparator make default comparator point to: org.jboss.deployment.DeploymentSorter (make this a comparator that does the correct ordering) in scanDirectory, change: list = sorter.sortURLs(list); to: if (urlComparator != null) Collections.sort(list, urlComparator); This allows users unhappy with the ordering scheme to replace it with their own Comparator (or simply drop it to remove all ordering). If this sounds OK, I am mucking about in that code anyway. Would you like me to make these changes? -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
|Anyway I'm starting to think being able to order deployments this way is |probably a good idea, see my other post, just don't make it the only way. I agree, so let's drop it. I want the simplest numbering available 'UNIX-styleee' and for more advanced (read have time) then the xml based deployer ordering. As larry said (do you have rw yet?) let's not shove it down people's throat and let's document all of this. Case closed. Implementation needed :) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
On 2002.04.21 15:46:46 -0400 marc fleury wrote: > | | name="jboss.deployment:type=DeploymentScanner,flavor=URL"> > | > | > | |optional-attribute-name="Deployer">jboss.system:service=MainDeploye > |r > | > |5000 > | > | > | > | ./deploy/jar1.jar, > | ./deploy/sar2.sar, > | ./deploy/war3.war, > | ./deploy/jar4.jar, > | ./deploy > | > | > | > |Which is easier, setting it one place here or changing n names in your m > |ant build scripts, scattered all over your hard drive? Suppose you want > to > |change the order? Would you rather go to one config file or your nXm > |places in ant scripts? Please explain how distributing the deployment > |order over so many places is easier to use than concentrating it in one > |place. > > What are you talking about? > > CLEARLY say > 01jar1.jar > 02sar2.jar > 03war3.war > 04jar4.jar > > in a directory is CLEARLY SIMPLER > > end of story > > marcf What are _you_ talking about? Where do those nice filenames come from? YOUR ANT SCRIPT[S] and not just one place, at best in one file, 4 jar targets, at worst in 4 files spread out over 4 cvs projects on 4 sourceforge projects. That is obviously more spread out than one attribute in an mbean config, which is CLEARLY SIMPLER;-) Think about what you have to do to change the order... now where'd that jar come from anyway?? Anyway I'm starting to think being able to order deployments this way is probably a good idea, see my other post, just don't make it the only way. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
| | | |jboss.system:service=MainDeploye |r | |5000 | | | | ./deploy/jar1.jar, | ./deploy/sar2.sar, | ./deploy/war3.war, | ./deploy/jar4.jar, | ./deploy | | | |Which is easier, setting it one place here or changing n names in your m |ant build scripts, scattered all over your hard drive? Suppose you want to |change the order? Would you rather go to one config file or your nXm |places in ant scripts? Please explain how distributing the deployment |order over so many places is easier to use than concentrating it in one |place. What are you talking about? CLEARLY say 01jar1.jar 02sar2.jar 03war3.war 04jar4.jar in a directory is CLEARLY SIMPLER end of story marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> No in fact it is the contrary my pet idea was the directory names > first/second/third this is what the class in London decided was the simplest > to use (as opposed to going and setting mbean names left and right which is > the direction you are heading full speed). My 2 cents: For users who need this sort of behaviour, I think it would be nice, but I wouldn't want to force it down the throats of all users. Perhaps, deploy first any URLs whose names match the ordered deployment naming convention, then deploy everything else as it is done now. Was this what you had in mind? If this is the case, then I believe the naming scheme should be more mangled than just xxx1.jar, yyy2.ear, ... This could very easily be done on accident by unwary users (ex. myApp_ver3.jar). Perhaps force the name to be xxx_jborder_1.jar, or something else unlikely to be duplicated on accident. Also, I think that if a user does specify a particular ordering within the Scanners MBean config, then that should take precedence over anything else. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
All my problems with your idea of lexical ordering of deployment would go away if it was optional, per directory. I can see that sometimes it will be convenient. I don't want to have to number all the more-or-less required packages in deploy, however. How about if the deployment scanner mbean config looked like this: jboss.system:service=MainDeployer 5000 To deploy an exploded package, include it as an url. What do you think? Seems to me that it avoids problems with both extremes. thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
On 2002.04.21 14:02:40 -0400 marc fleury wrote: > > |just "I haven't taken the time to find out how the deployment works or > test > > I wrote the fucking deployment. Along with me, Jason, and Larry Sanderson, to name a few. > > |it, and my pet idea isn't implemented, so I'm going to bitch" > > No in fact it is the contrary my pet idea was the directory names > first/second/third this is what the class in London decided was the > simplest > to use (as opposed to going and setting mbean names left and right which > is > the direction you are heading full speed). David, you are really useless > when it comes to user input, I will take the input of 20 guys when it > comes > to usability any day. > > And now stop pissing me off. > > |What doesn't work now give an example! > > How do you say *simply* > > jar1 before sar2 before war3? > > marcf > > > jboss.system:service=MainDeployer 5000 ./deploy/jar1.jar, ./deploy/sar2.sar, ./deploy/war3.war, ./deploy/jar4.jar, ./deploy Which is easier, setting it one place here or changing n names in your m ant build scripts, scattered all over your hard drive? Suppose you want to change the order? Would you rather go to one config file or your nXm places in ant scripts? Please explain how distributing the deployment order over so many places is easier to use than concentrating it in one place. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
|just "I haven't taken the time to find out how the deployment works or test I wrote the fucking deployment. |it, and my pet idea isn't implemented, so I'm going to bitch" No in fact it is the contrary my pet idea was the directory names first/second/third this is what the class in London decided was the simplest to use (as opposed to going and setting mbean names left and right which is the direction you are heading full speed). David, you are really useless when it comes to user input, I will take the input of 20 guys when it comes to usability any day. And now stop pissing me off. |What doesn't work now give an example! How do you say *simply* jar1 before sar2 before war3? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
What problem are you trying to solve marc? You haven't indicated anything that doesn't work except your personal ordering preference. What actual deployment problem are you seeing right now with the current code? I haven't seen you say "this can't be done easily with the current code", just "I haven't taken the time to find out how the deployment works or test it, and my pet idea isn't implemented, so I'm going to bitch" What doesn't work now give an example! david jencks On 2002.04.21 13:37:59 -0400 marc fleury wrote: > Ok you guys just talk without end and the simplest solution is still not > done, > > I will have to do it just so that we have something that works. > > Just pisses me off > > marcf > > |-Original Message- > |From: David Jencks [mailto:[EMAIL PROTECTED]] > |Sent: Sunday, April 21, 2002 9:45 AM > |To: marc fleury > |Cc: [EMAIL PROTECTED] > |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ? > | > | > | > |> Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING > OF > |> DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER. > |> > |> If I do 01first.sar and 02second.war do I get 01 first and 02 second? > |> > |> YES=NO > |> > |> ? > | > | > |umm YES != No > | > |the answer is NO > | > |If you want deployments in a specific order list them in that order in > the > |deployment scanner mbean. Otherwise we get into nonsense about > conflicts > |between packaged type order and explicit alphabetical order --> you are > |forced to use alphabetical order even if you don't need it. > Alphabetical > |order might look nice at first but it is really bad IMO. > | > |remember mbeans wait for their classes now... solves a lot of ordering > |problems. > | > |david jencks > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Ok you guys just talk without end and the simplest solution is still not done, I will have to do it just so that we have something that works. Just pisses me off marcf |-Original Message- |From: David Jencks [mailto:[EMAIL PROTECTED]] |Sent: Sunday, April 21, 2002 9:45 AM |To: marc fleury |Cc: [EMAIL PROTECTED] |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ? | | | |> Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING OF |> DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER. |> |> If I do 01first.sar and 02second.war do I get 01 first and 02 second? |> |> YES=NO |> |> ? | | |umm YES != No | |the answer is NO | |If you want deployments in a specific order list them in that order in the |deployment scanner mbean. Otherwise we get into nonsense about conflicts |between packaged type order and explicit alphabetical order --> you are |forced to use alphabetical order even if you don't need it. Alphabetical |order might look nice at first but it is really bad IMO. | |remember mbeans wait for their classes now... solves a lot of ordering |problems. | |david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING OF > DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER. > > If I do 01first.sar and 02second.war do I get 01 first and 02 second? > > YES=NO > > ? umm YES != No the answer is NO If you want deployments in a specific order list them in that order in the deployment scanner mbean. Otherwise we get into nonsense about conflicts between packaged type order and explicit alphabetical order --> you are forced to use alphabetical order even if you don't need it. Alphabetical order might look nice at first but it is really bad IMO. remember mbeans wait for their classes now... solves a lot of ordering problems. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
