Re: [JBoss-dev] ordering proposal
this is great, this is today in cvs, unless a certain someone removed this as well. =P The problem is a painful russian doll structure. 3- however there are 3 static directories deploy/first, deploy/second, deploy/third, actually i could call them deploy/deploy1, deploy/deploy2/deploy3... and allow for arbitrary numbers but we would provide at least 3. AND if you drop something in deploy and deploy1 deploy2 for example deploy/sar deploy1/jar deploy2/war, sar1 deploy3/ jar2, ear, xml you get deploy1-deploy2-deploy3-deploy with ordering from 2 and 1 above so jar, sar1, war, jar2, xml, ear, sar So, if I have an ejb-jar which depends on some code deployed from an xml, which is all used by a service deployed by a sar... where do my files go? This may simplify the code which has to deal with depdenencies... by basically avoiding the problem... but it complicates the user configuration... voila! no dependency explicitely set but a very simple way of putting stuff in the right order. It will do the trick. I'll code it if a certain someone doesn't. With the recent mod to UDS this will work... just list new directory urls in jboss-service.xml. rc1-rc6 has been in Unix for 20 years, so let's stop fucking around Um... ya... well there have already been several others who have commented on this... lets not get confused over runlevels and Sn|Kn ordering... which are there only because the system does not have the capacity to define or ask the services started from the script what the dependecies are. The problem of solving the dependecies automatically inside of the server aren't really that huge... just a bit tricky here and there. We are almost there, with the depends element... but we need to finish off the job... by extending that to j2ee deployables (which can be done by adding support and config to jboss.xml) and by changing the system to wait for all dependencies to be meet before attempting to install any of the service into the spine. Perhaps dependecies should be rethought all together... not that I particularly want to spend any time there... but perhaps someone should. In the mean time I don't think we should move the complexity on to configuration/users. Short-term, sorting ala UDS for scanned directories is enabled. This should fix the issues we have seen... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ordering proposal
Sorry for the late response, but this doesn't exist right now, but could be implemented to add jboss dependency managmenet to j2ee deployables. Probably just depends:SomeObjectName/depends... --jason Bill Burke wrote: Can you put a dependency tag in jboss.xml? What's the syntax? -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 5:53 PM To: Bill Burke Cc: marc fleury; Scott M Stark; Jboss-Development @ Lists . Sourceforge . Net Subject: Re: [JBoss-dev] ordering proposal A directory based short-term solution (which does not hint at any sysv-like functionality) is probably the easiest to implement and mange. It will however complicate the management of the system dramatically... actually any of the solutions/hacks which have been mentiond will only complicate. Take the N* prefix method, now the scanners need to make sure they sort by prefix, such that 05 comes becore 06 and so on. When two deployables share the same prefix and one depends on the other, then you must reorder. Depending on how complicated your deployment is, this could be a pain. For directories, if you start out with a small number, system, user-support, user (or whatever), then if a dependency between a component in user-support and user exists, where user-support c depends on user c, then you have to artificually create a third directory to resolve the conflict. So, as a user... where do I put my deployable? Does it matter that my deployable is of type x? Some users might like N*, some might like directories... the system should be able to handle both... lets not force one or the other. For the previous example, where beans loaded before the datasource, couldn't that be handled by putting a dependency tag in jboss.xml? Or is there more to the dependency problem than that? --jason Bill Burke wrote: directory solution is better and easier to maintain IMHO than the SXX stuff. My gut feeling tells me that with the SXX solution you'll constantly be changing filenames and will create headaches for everyone. Directoy ordering and depends should be good enough for the implicit and explicit ordering you need, no? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Wednesday, March 13, 2002 11:00 AM To: Scott M Stark; Jboss-Development @ Lists . Sourceforge . Net Subject: RE: [JBoss-dev] ordering proposal |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Wednesday, March 13, 2002 8:00 AM |To: Jboss-Development @ Lists . Sourceforge . Net |Subject: Re: [JBoss-dev] ordering proposal | | |Or equivalently, mirror the deploy1, deploy2, ... etc structure in |the ear. | |Case 1: |ear/ |--deploy1/sar |--deploy1/war | |Case 2: |ear/ |--deploy1/war |--deploy2/sar yes, and i actually now prefer the explicit SXX solution for naming, doing away with rc.d structures. We just order by number SIMPLE, ultra SIMPLE in the abscence of numbering we deploy after the numbers. marcf | |Then you have the same ordering logic for the fixed directories and |application deployment units. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | |- Original Message - |From: Scott M Stark [EMAIL PROTECTED] |To: Jboss-Development @ Lists . Sourceforge . Net |[EMAIL PROTECTED] |Sent: Wednesday, March 13, 2002 7:47 AM |Subject: Re: [JBoss-dev] ordering proposal | | | | - Original Message - | From: marc fleury [EMAIL PROTECTED] | To: marc fleury [EMAIL PROTECTED]; David Jencks | [EMAIL PROTECTED] | Cc: Jboss-Development @ Lists . Sourceforge . Net | [EMAIL PROTECTED] | Sent: Wednesday, March 13, 2002 5:42 AM | Subject: RE: [JBoss-dev] ordering proposal | | | ok, | | so i will implement the following | | deploy directory remains there, you can drop anything in deploy. | | 3 rules: | jar/ | ---sar | ---war/ | --jar2 | 1- There is an ordering in deploy xmlsarwarearjar or whatever i had |in | there before. | | 2-if you deploy a bean with dependencies, whatever they may be, i.e. | sar/ear/war/rar/jar containment is enough to order. The inner stuff is | deployed first | so | | | will result in the following order | jar2sarwarjar | | this is great, this is today in cvs, unless a certain someone removed |this | as well. | | The problem is a painful russian doll structure. | This is using Ant as the deployment language. If the sar depends on the | war because it is adapting a legacy protocol to soap for example, you | would then need to repackage the above to: | | jar/ | ---war/ | --sar | --jar2 | | I would rather see an ear as the standalone deployment package and | include a jboss-application.xml descriptor that allows for the |specification | of deployment ordering
Re: [JBoss-dev] ordering proposal
I don't think so. Implement one or the other but supporting both is going to be a nightmare from a maintenance standpoint. Imagine a user using the numbered order in a directory configuration. *shiver* So, my point was to fix the system such that neither is needed for deployment to function correctly. Let users complicate there deployment environment as needed, but don't force the system into one flavor or another. Alternative: make it pluggable and support EITHER the one OR the other but not both. And leave the ability of the user just dropping an arbitrarily named [j|e|w|s]ar file into deploy/ w/o thinking about dependencies. This is still one of my top-10 favorite features from JBoss: just drop the archive into deploy/ and *boom* you're up and running. Yes, but I don't believe that any of this should be needed, thus I don't want to spend much time writting a pluggable system to handle it. I am confident that we can get the system internals to cope with these dependency issues... its just a matter of time. As Marc points out repeatedly: KISS. Giving a choice of two methods is going to lead into problems sooner or later. My personal vote would be for a ordered by number solution as you can quickly see the order of deployment by just typing 'ls' or 'dir' instead of having to watch N separate directories. This would be the simplest to implement, perhaps even a non-op depending on how File.list() works by default. Unfortunatly I don't think this is simple for users to comprehend and maintain. Plus, I think that if we do change the deployment configuration for 3.0, then users might expect it to stick around... and I really don't think we want either of the two major options long term. Better to just hack the system asis and make it transparent for now. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ordering proposal
|This can be done today simply by including the list of 3 or whatever |directories in the URLDeploymentScanner. Jason just needs to sort each |directory separately when he puts the sorting back in. right, let's just do that, it is simple and will cover 99% cases. we need to 1- document the deployer of the deployer would get it right away 2- as you point out the key is ordering first/second and third separately which is not the way i remember i coded it (i would order the full set) and then we are done. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ordering proposal
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Wednesday, March 13, 2002 12:19 AM |To: David Jencks |Cc: Jboss-Development @ Lists . Sourceforge . Net |Subject: RE: [JBoss-dev] ordering proposal | | ||This can be done today simply by including the list of 3 or whatever ||directories in the URLDeploymentScanner. Jason just needs to sort each ||directory separately when he puts the sorting back in. | |right, let's just do that, it is simple and will cover 99% cases. | |we need to |1- document the deployer of the deployer would get it right away never write emails with no sleep... i meant 1- document the deployer, much confusion is due to lack of basic understanding due to lack of doco. It is actually easy, so people would get it right away. marcf |2- as you point out the key is ordering first/second and third separately |which is not the way i remember i coded it (i would order the full set) and |then we are done. | |marcf | | | |___ |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: [JBoss-dev] ordering proposal
ok, so i will implement the following deploy directory remains there, you can drop anything in deploy. 3 rules: 1- There is an ordering in deploy xmlsarwarearjar or whatever i had in there before. 2-if you deploy a bean with dependencies, whatever they may be, i.e. sar/ear/war/rar/jar containment is enough to order. The inner stuff is deployed first so jar/ ---sar ---war/ --jar2 will result in the following order jar2sarwarjar this is great, this is today in cvs, unless a certain someone removed this as well. The problem is a painful russian doll structure. 3- however there are 3 static directories deploy/first, deploy/second, deploy/third, actually i could call them deploy/deploy1, deploy/deploy2/deploy3... and allow for arbitrary numbers but we would provide at least 3. AND if you drop something in deploy and deploy1 deploy2 for example deploy/sar deploy1/jar deploy2/war, sar1 deploy3/ jar2, ear, xml you get deploy1-deploy2-deploy3-deploy with ordering from 2 and 1 above so jar, sar1, war, jar2, xml, ear, sar voila! no dependency explicitely set but a very simple way of putting stuff in the right order. It will do the trick. I'll code it if a certain someone doesn't. rc1-rc6 has been in Unix for 20 years, so let's stop fucking around marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Wednesday, March 13, 2002 5:26 AM |To: marc fleury; David Jencks |Cc: Jboss-Development @ Lists . Sourceforge . Net |Subject: RE: [JBoss-dev] ordering proposal | | | | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED]]On Behalf Of marc ||fleury ||Sent: Wednesday, March 13, 2002 12:19 AM ||To: David Jencks ||Cc: Jboss-Development @ Lists . Sourceforge . Net ||Subject: RE: [JBoss-dev] ordering proposal || || |||This can be done today simply by including the list of 3 or whatever |||directories in the URLDeploymentScanner. Jason just needs to sort each |||directory separately when he puts the sorting back in. || ||right, let's just do that, it is simple and will cover 99% cases. || ||we need to ||1- document the deployer of the deployer would get it right away | |never write emails with no sleep... | |i meant | |1- document the deployer, much confusion is due to lack of basic |understanding due to lack of doco. It is actually easy, so people would get |it right away. | |marcf | ||2- as you point out the key is ordering first/second and third separately ||which is not the way i remember i coded it (i would order the |full set) and ||then we are done. || ||marcf || || || ||___ ||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: [JBoss-dev] ordering proposal
|Why doesn't depends handle this? because marcf | |--jason | | | |___ |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: [JBoss-dev] ordering proposal
On 13 Mar, marc fleury wrote: [...] The problem is a painful russian doll structure. 3- however there are 3 static directories deploy/first, deploy/second, deploy/third, actually i could call them deploy/deploy1, deploy/deploy2/deploy3... and allow for arbitrary numbers but we would provide at least 3. AND if you drop something in deploy and deploy1 deploy2 for example deploy/sar deploy1/jar deploy2/war, sar1 deploy3/ jar2, ear, xml you get deploy1-deploy2-deploy3-deploy with ordering from 2 and 1 above so jar, sar1, war, jar2, xml, ear, sar voila! no dependency explicitely set but a very simple way of putting stuff in the right order. It will do the trick. I'll code it if a certain someone doesn't. rc1-rc6 has been in Unix for 20 years, so let's stop fucking around marcf Well, rc1-rc6 has nothing with ordering to do, but is the different runlevels. For example, when you start in rc3 this mean server/network and certain services should be started, runlevel 5 is for X11 support and perhaps a different or additional set of services should be started. runlevel 6 will reboot the system and so on. The order in which the services should be started is NOT decied by the number on the runlevel or directory, but by the number and symbol the service start and stop script have (normaly a symlink to a script without any numbers), ie: /etc/rc.d/rc3.d/S10network will start before /etc/rc.d/rc3.d/S80sendmail because 10 commes before 80. however /etc/rc.d/rc1.d/S20random will not start after (nor before) S10network because there is no S10network in rc1.d and if the runlevel is 1 then the scripts in rc3.d will never be run. This is at least how I have learn Unix and the idea of runlevels in SysV inspired systems. //Peter -- Peter AntmanChief Systems Architect, Business Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ordering proposal
- Original Message - From: marc fleury [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED]; David Jencks [EMAIL PROTECTED] Cc: Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 5:42 AM Subject: RE: [JBoss-dev] ordering proposal ok, so i will implement the following deploy directory remains there, you can drop anything in deploy. 3 rules: 1- There is an ordering in deploy xmlsarwarearjar or whatever i had in there before. 2-if you deploy a bean with dependencies, whatever they may be, i.e. sar/ear/war/rar/jar containment is enough to order. The inner stuff is deployed first so jar/ ---sar ---war/ --jar2 will result in the following order jar2sarwarjar this is great, this is today in cvs, unless a certain someone removed this as well. The problem is a painful russian doll structure. This is using Ant as the deployment language. If the sar depends on the war because it is adapting a legacy protocol to soap for example, you would then need to repackage the above to: jar/ ---war/ --sar --jar2 I would rather see an ear as the standalone deployment package and include a jboss-application.xml descriptor that allows for the specification of deployment ordering in there. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ordering proposal
|/etc/rc.d/rc3.d/S10network will start before /etc/rc.d/rc3.d/S80sendmail |because 10 commes before 80. whatever, stuff in rc2 is started before stuff in rc3 also the S10network before the S80sendmail is a convention that is actually great, it is an explicit ordering of deployments and is maybe complementary to the extension implicit ordering that was removed. Scott mentioned that we need a testsuite test to test these ordering and I agree I have missed coding that in the rush but we should really do at least 10 funky scenario to make sure this works well. The point is that with a simple structure like the directory and ordering inside (whatever it may be, possibly the UNIX one, let's copy these guys) then we are making the ordering of deployments really simple and intuitive until we build a more highlevel solution based on 77 dependencies at the objectname level. the other thing that i like about the solution is the lack of any xml mumbo jumbo dependencies, it is quite straightforward. and again, unix is good :) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ordering proposal
Or equivalently, mirror the deploy1, deploy2, ... etc structure in the ear. Case 1: ear/ --deploy1/sar --deploy1/war Case 2: ear/ --deploy1/war --deploy2/sar Then you have the same ordering logic for the fixed directories and application deployment units. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 7:47 AM Subject: Re: [JBoss-dev] ordering proposal - Original Message - From: marc fleury [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED]; David Jencks [EMAIL PROTECTED] Cc: Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 5:42 AM Subject: RE: [JBoss-dev] ordering proposal ok, so i will implement the following deploy directory remains there, you can drop anything in deploy. 3 rules: jar/ ---sar ---war/ --jar2 1- There is an ordering in deploy xmlsarwarearjar or whatever i had in there before. 2-if you deploy a bean with dependencies, whatever they may be, i.e. sar/ear/war/rar/jar containment is enough to order. The inner stuff is deployed first so will result in the following order jar2sarwarjar this is great, this is today in cvs, unless a certain someone removed this as well. The problem is a painful russian doll structure. This is using Ant as the deployment language. If the sar depends on the war because it is adapting a legacy protocol to soap for example, you would then need to repackage the above to: jar/ ---war/ --sar --jar2 I would rather see an ear as the standalone deployment package and include a jboss-application.xml descriptor that allows for the specification of deployment ordering in there. ___ 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: [JBoss-dev] ordering proposal
|This is using Ant as the deployment language. If the sar depends on the |war because it is adapting a legacy protocol to soap for example, you |would then need to repackage the above to: | |jar/ |---war/ |--sar |--jar2 that is correct, | |I would rather see an ear as the standalone deployment package and |include a jboss-application.xml descriptor that allows for the |specification |of deployment ordering in there. it is limited to ears scott, we need something that works across of deployment units. the right way (TM) is with 77 (objectname) dependencies when everything is an mbean with an objectname in 77 but 1- this is ways off and requires some work in all the layers 2- this requires xml coding, you need to code the exact names to achieve the right order, and these are jmx like object names that are subject to fucking up... i wasn't shooting for the stars, just something to start with and make sure we reach final with a foolproof way of explaining how to do dependencies. i am actually partial to the solution below 1- deployN directories as rcN 2- war/jar/sar/xml as implicit ordering within one directory (we are j2ee after all) 3- the S00MyJAR.jar numbering of unix within one directory as this will enable us to move to straight xml files, where we would have S78my-service.xml, S92mybean.xml (with unified xml a la david jencks), S333mywar.xml the need to package an ear as implicit unit then sorts of dissapear if we have a way to specify the URL context, which david unified proposal does. we have an explicit way of ordering them JUST BY NAME, you look at the directory and you know what is going on. i am sold... going back to training marcf PS: actually i think we can even REMOVE the deployN (rc.d) and just go with straightnumbering and voila... hmmm simpler. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ordering proposal
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Wednesday, March 13, 2002 8:00 AM |To: Jboss-Development @ Lists . Sourceforge . Net |Subject: Re: [JBoss-dev] ordering proposal | | |Or equivalently, mirror the deploy1, deploy2, ... etc structure in |the ear. | |Case 1: |ear/ |--deploy1/sar |--deploy1/war | |Case 2: |ear/ |--deploy1/war |--deploy2/sar yes, and i actually now prefer the explicit SXX solution for naming, doing away with rc.d structures. We just order by number SIMPLE, ultra SIMPLE in the abscence of numbering we deploy after the numbers. marcf | |Then you have the same ordering logic for the fixed directories and |application deployment units. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | |- Original Message - |From: Scott M Stark [EMAIL PROTECTED] |To: Jboss-Development @ Lists . Sourceforge . Net |[EMAIL PROTECTED] |Sent: Wednesday, March 13, 2002 7:47 AM |Subject: Re: [JBoss-dev] ordering proposal | | | | - Original Message - | From: marc fleury [EMAIL PROTECTED] | To: marc fleury [EMAIL PROTECTED]; David Jencks | [EMAIL PROTECTED] | Cc: Jboss-Development @ Lists . Sourceforge . Net | [EMAIL PROTECTED] | Sent: Wednesday, March 13, 2002 5:42 AM | Subject: RE: [JBoss-dev] ordering proposal | | | ok, | | so i will implement the following | | deploy directory remains there, you can drop anything in deploy. | | 3 rules: | jar/ | ---sar | ---war/ | --jar2 | 1- There is an ordering in deploy xmlsarwarearjar or whatever i had |in | there before. | | 2-if you deploy a bean with dependencies, whatever they may be, i.e. | sar/ear/war/rar/jar containment is enough to order. The inner stuff is | deployed first | so | | | will result in the following order | jar2sarwarjar | | this is great, this is today in cvs, unless a certain someone removed |this | as well. | | The problem is a painful russian doll structure. | This is using Ant as the deployment language. If the sar depends on the | war because it is adapting a legacy protocol to soap for example, you | would then need to repackage the above to: | | jar/ | ---war/ | --sar | --jar2 | | I would rather see an ear as the standalone deployment package and | include a jboss-application.xml descriptor that allows for the |specification | of deployment ordering in there. | | | | ___ | 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: [JBoss-dev] ordering proposal
Hi, On Wed, 2002-03-13 at 16:47, marc fleury wrote: |/etc/rc.d/rc3.d/S10network will start before /etc/rc.d/rc3.d/S80sendmail |because 10 commes before 80. whatever, stuff in rc2 is started before stuff in rc3 this is not correct when looked upon from the UNIX perspective. My system boots up in runlevel 3, thus everything under 'rc3.d' is run sequenced by the numbers (S10 before S11, etc.). SysV doesn't care what is in the other rcX.d directories, it just looks into the directory that it is switching runlevel to. When switching in between runlevels (i.e. upon system boot), it also looks in the current runlevel directory and runs any script called Kxx (xx again a sequence number) to shutdown any services currently running. After this has been done it will start everything that is in the next runlevels directory. When switching e.g. from level 3 to level 5, SysV 1. runs all 'Kxx' scripts from rc3.d (K is for KILL) 2. runs all 'Sxx' scripts from rc5.d also the S10network before the S80sendmail is a convention that is actually great, it is an explicit ordering of deployments and is maybe complementary to the extension implicit ordering that was removed. +1 the other thing that i like about the solution is the lack of any xml mumbo jumbo dependencies, it is quite straightforward. +1 and again, unix is good :) +2 ;) Christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ordering proposal
directory solution is better and easier to maintain IMHO than the SXX stuff. My gut feeling tells me that with the SXX solution you'll constantly be changing filenames and will create headaches for everyone. Directoy ordering and depends should be good enough for the implicit and explicit ordering you need, no? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Wednesday, March 13, 2002 11:00 AM To: Scott M Stark; Jboss-Development @ Lists . Sourceforge . Net Subject: RE: [JBoss-dev] ordering proposal |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Wednesday, March 13, 2002 8:00 AM |To: Jboss-Development @ Lists . Sourceforge . Net |Subject: Re: [JBoss-dev] ordering proposal | | |Or equivalently, mirror the deploy1, deploy2, ... etc structure in |the ear. | |Case 1: |ear/ |--deploy1/sar |--deploy1/war | |Case 2: |ear/ |--deploy1/war |--deploy2/sar yes, and i actually now prefer the explicit SXX solution for naming, doing away with rc.d structures. We just order by number SIMPLE, ultra SIMPLE in the abscence of numbering we deploy after the numbers. marcf | |Then you have the same ordering logic for the fixed directories and |application deployment units. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | |- Original Message - |From: Scott M Stark [EMAIL PROTECTED] |To: Jboss-Development @ Lists . Sourceforge . Net |[EMAIL PROTECTED] |Sent: Wednesday, March 13, 2002 7:47 AM |Subject: Re: [JBoss-dev] ordering proposal | | | | - Original Message - | From: marc fleury [EMAIL PROTECTED] | To: marc fleury [EMAIL PROTECTED]; David Jencks | [EMAIL PROTECTED] | Cc: Jboss-Development @ Lists . Sourceforge . Net | [EMAIL PROTECTED] | Sent: Wednesday, March 13, 2002 5:42 AM | Subject: RE: [JBoss-dev] ordering proposal | | | ok, | | so i will implement the following | | deploy directory remains there, you can drop anything in deploy. | | 3 rules: | jar/ | ---sar | ---war/ | --jar2 | 1- There is an ordering in deploy xmlsarwarearjar or whatever i had |in | there before. | | 2-if you deploy a bean with dependencies, whatever they may be, i.e. | sar/ear/war/rar/jar containment is enough to order. The inner stuff is | deployed first | so | | | will result in the following order | jar2sarwarjar | | this is great, this is today in cvs, unless a certain someone removed |this | as well. | | The problem is a painful russian doll structure. | This is using Ant as the deployment language. If the sar depends on the | war because it is adapting a legacy protocol to soap for example, you | would then need to repackage the above to: | | jar/ | ---war/ | --sar | --jar2 | | I would rather see an ear as the standalone deployment package and | include a jboss-application.xml descriptor that allows for the |specification | of deployment ordering in there. | | | | ___ | 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ordering proposal
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Wednesday, March 13, 2002 12:50 PM To: Bill Burke; Scott M Stark; Jboss-Development @ Lists . Sourceforge . Net Subject: RE: [JBoss-dev] ordering proposal |directory solution is better and easier to maintain IMHO than the |SXX stuff. i feel it is the other way around (even though it was my original proposal), i will run it by the class tomorrow and get a show of hands. I like this I'll ask the class. How many other software projects have the actual developers talking to the user base? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ordering proposal
|I like this I'll ask the class. How many other software |projects have the |actual developers talking to the user base? you moron, our user base of today will spawn our developers of tomorrow. it is our best recruitment ground. you should see the class, the jboss boot-camp for developers, they are just great all enthusiastic, really, all professionals and already fixing bugs in the class. it is always a great stimulant to be in front a talented class. you should have seen Sacha give the training on security, it was BRILLANT, just brillant, he got an ovation at the end. the kid is just fucking brillant, take care marcf | | | |___ |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: [JBoss-dev] ordering proposal
I'm not following what SXX is a reference to. Deploy1, deploy2, ...? There are two deployment constructs, deploying from a set of directories and deploying a self contained archive. I'm talking about the self contained archive. I don't want this to be arbitrary Russian doll that controls deployment ordering. To deploy a self contained archive, create an ear that contains the requires sars, rars, xml service descriptors, j2ee components etc., and use the same ordered directory structure to define the deployment ordering. There is no renaming of files, only positioning within the flat deployment structure of the ear. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED]; Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 8:35 AM Subject: RE: [JBoss-dev] ordering proposal directory solution is better and easier to maintain IMHO than the SXX stuff. My gut feeling tells me that with the SXX solution you'll constantly be changing filenames and will create headaches for everyone. Directoy ordering and depends should be good enough for the implicit and explicit ordering you need, no? Bill |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Wednesday, March 13, 2002 8:00 AM |To: Jboss-Development @ Lists . Sourceforge . Net |Subject: Re: [JBoss-dev] ordering proposal | | |Or equivalently, mirror the deploy1, deploy2, ... etc structure in |the ear. | |Case 1: |ear/ |--deploy1/sar |--deploy1/war | |Case 2: |ear/ |--deploy1/war |--deploy2/sar yes, and i actually now prefer the explicit SXX solution for naming, doing away with rc.d structures. We just order by number SIMPLE, ultra SIMPLE in the abscence of numbering we deploy after the numbers. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ordering proposal
Ok, so were talking about actually using the rc.x ordering convention based on filenames. That is fine but as Christian says this is not a multi-directory thing. Each rx.x directory is effectively an independent configuration. This would also map to an ear and give a perflectly flat single level structure to the ear with the contained archive names definining the startup ordering. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Christian Riege [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED] Cc: JBoss Dev list [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 8:19 AM Subject: RE: [JBoss-dev] ordering proposal Hi, On Wed, 2002-03-13 at 16:47, marc fleury wrote: |/etc/rc.d/rc3.d/S10network will start before /etc/rc.d/rc3.d/S80sendmail |because 10 commes before 80. whatever, stuff in rc2 is started before stuff in rc3 this is not correct when looked upon from the UNIX perspective. My system boots up in runlevel 3, thus everything under 'rc3.d' is run sequenced by the numbers (S10 before S11, etc.). SysV doesn't care what is in the other rcX.d directories, it just looks into the directory that it is switching runlevel to. When switching in between runlevels (i.e. upon system boot), it also looks in the current runlevel directory and runs any script called Kxx (xx again a sequence number) to shutdown any services currently running. After this has been done it will start everything that is in the next runlevels directory. When switching e.g. from level 3 to level 5, SysV 1. runs all 'Kxx' scripts from rc3.d (K is for KILL) 2. runs all 'Sxx' scripts from rc5.d also the S10network before the S80sendmail is a convention that is actually great, it is an explicit ordering of deployments and is maybe complementary to the extension implicit ordering that was removed. +1 the other thing that i like about the solution is the lack of any xml mumbo jumbo dependencies, it is quite straightforward. +1 and again, unix is good :) +2 ;) Christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ordering proposal
Having to nest jars in a particular manner to achieve the correct deployment ordering certainly is not simple. Here your talking about the static deployment directories while all of the current issues are with self-contained deployment units of j2ee components and services. We need a simple mechanism for handling the ordering of component deployment within a xar. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 12, 2002 6:56 PM Subject: [JBoss-dev] ordering proposal ok, it is 3 am in london and i drank a bit too much beer with jules and sacha however, can't we simply do a deploy/first/ deploy/second/ deploy/third/ a la 'init.d/rc1-2-3' and we first deploy the stuff from 'first' then 'second' then 'third' so we can **simply explain to people that if they need something first then they put it in first, then if they need something in second they put it in second. simple... simple to explain a bit more complex to code but would be worth it... marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ordering proposal
This can be done today simply by including the list of 3 or whatever directories in the URLDeploymentScanner. Jason just needs to sort each directory separately when he puts the sorting back in. david jencks On 2002.03.12 21:56:01 -0500 marc fleury wrote: ok, it is 3 am in london and i drank a bit too much beer with jules and sacha however, can't we simply do a deploy/first/ deploy/second/ deploy/third/ a la 'init.d/rc1-2-3' and we first deploy the stuff from 'first' then 'second' then 'third' so we can **simply explain to people that if they need something first then they put it in first, then if they need something in second they put it in second. simple... simple to explain a bit more complex to code but would be worth it... marcf ___ 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: [JBoss-dev] ordering proposal
Are you sure it is that hard to understand or do? Usually the default order of peer subpackages works fine: if you want something else you can use nesting. I think that if we can convert jndi dependencies into mbean dependencies a lot of problems will go away without any more deployment descriptors such as an explicit list of what order to deploy subpackages in. For instance, I would like to convert a resource-ref into an mbean dependency on the e.g. connection factory so the ejb won't deploy until the connection factory is set up. Similarly, ejb-links can be converted into mbean dependencies so the ejb will just wait to start until all the others it uses are available. david jencks On 2002.03.12 22:21:40 -0500 Scott M Stark wrote: Having to nest jars in a particular manner to achieve the correct deployment ordering certainly is not simple. Here your talking about the static deployment directories while all of the current issues are with self-contained deployment units of j2ee components and services. We need a simple mechanism for handling the ordering of component deployment within a xar. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 12, 2002 6:56 PM Subject: [JBoss-dev] ordering proposal ok, it is 3 am in london and i drank a bit too much beer with jules and sacha however, can't we simply do a deploy/first/ deploy/second/ deploy/third/ a la 'init.d/rc1-2-3' and we first deploy the stuff from 'first' then 'second' then 'third' so we can **simply explain to people that if they need something first then they put it in first, then if they need something in second they put it in second. simple... simple to explain a bit more complex to code but would be worth it... marcf ___ 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: [JBoss-dev] ordering proposal
Ordering should not be a function of the packaging. I should be able to create an ear with a flat hiearchy of sars, jars, wars and specify the startup order. I don't see the need to allow arbitrary composition of packages. We flattened the class loader heirarchy because it was a pain to get right. Why not do the same for deployment packages. The maxium packaging depth would be ear/war/jar as this is allowed by the j2ee spec. The standard j2ee descriptor references are not sufficient to cover the dependencies. The ejb has no direct knowledege that it is using a custom JRMPInvoker service. Likewise, if a service is using an ejb or servlet how is this specified? - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 12, 2002 7:39 PM Subject: Re: [JBoss-dev] ordering proposal Are you sure it is that hard to understand or do? Usually the default order of peer subpackages works fine: if you want something else you can use nesting. I think that if we can convert jndi dependencies into mbean dependencies a lot of problems will go away without any more deployment descriptors such as an explicit list of what order to deploy subpackages in. For instance, I would like to convert a resource-ref into an mbean dependency on the e.g. connection factory so the ejb won't deploy until the connection factory is set up. Similarly, ejb-links can be converted into mbean dependencies so the ejb will just wait to start until all the others it uses are available. david jencks On 2002.03.12 22:21:40 -0500 Scott M Stark wrote: Having to nest jars in a particular manner to achieve the correct deployment ordering certainly is not simple. Here your talking about the static deployment directories while all of the current issues are with self-contained deployment units of j2ee components and services. We need a simple mechanism for handling the ordering of component deployment within a xar. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ordering proposal
deploy/first/ deploy/second/ deploy/third/ a la 'init.d/rc1-2-3' Not such a hot idea. There was talk about this a while ago What is the real issue here? Why doesn't the depends attribute handle it? a bit more complex to code but would be worth it... Does not seem like any code to implement, just add ordered directory structure in UDS... but I have not thought it out fully. Why doesn't depends handle this? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ordering proposal
ok, the packaging ordering/nesting is clearly defined in the current deployer (at least until jason removed ordering on his own). clearly inner packages are deployed before outer. and there was an order at the same level xmlsarrarearwarejb or something like this. btw jason, we really need this back, THEN, yes i agree that forcing order through containment needs to be enhanced by some explicit dependency order. Until we get the full xml dependency at the jsr77 or mbean level, we can use the deploy/first/second third which should cover most if not all cases. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, March 12, 2002 9:33 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] ordering proposal | | | |Ordering should not be a function of the packaging. I should |be able to create an ear with a flat hiearchy of sars, jars, |wars and specify the startup order. I don't see the need to |allow arbitrary composition of packages. We flattened the |class loader heirarchy because it was a pain to get right. Why |not do the same for deployment packages. The maxium packaging |depth would be ear/war/jar as this is allowed by the j2ee spec. | |The standard j2ee descriptor references are not sufficient to cover |the dependencies. The ejb has no direct knowledege that it is using a |custom JRMPInvoker service. Likewise, if a service is using an |ejb or servlet how is this specified? | |- Original Message - |From: David Jencks [EMAIL PROTECTED] |To: [EMAIL PROTECTED] |Sent: Tuesday, March 12, 2002 7:39 PM |Subject: Re: [JBoss-dev] ordering proposal | | | Are you sure it is that hard to understand or do? Usually the default | order of peer subpackages works fine: if you want something else you can | use nesting. | | I think that if we can convert jndi dependencies into mbean |dependencies a | lot of problems will go away without any more deployment descriptors such | as an explicit list of what order to deploy subpackages in. | | For instance, I would like to convert a resource-ref into an mbean | dependency on the e.g. connection factory so the ejb won't deploy until |the | connection factory is set up. Similarly, ejb-links can be converted into | mbean dependencies so the ejb will just wait to start until all |the others | it uses are available. | | david jencks | | On 2002.03.12 22:21:40 -0500 Scott M Stark wrote: | Having to nest jars in a particular manner to achieve the correct | deployment ordering certainly is not simple. Here your talking | about the static deployment directories while all of the current | issues are with self-contained deployment units of j2ee components | and services. We need a simple mechanism for handling the | ordering of component deployment within a xar. | | | | |___ |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
