Re: [JBoss-dev] Where should the Jasper jar live ?
OK, It looks like I have been bludgeoned into seperating Jetty config and impl. Just for the record, Jason, I still don't think you have taken in my suggestion. You seem to think that I am belligerently hanging onto the idea of delivering Jetty in a single file, which needs unpacking, editing and repacking in order to change the port number. If this is not the case - apologies If it is - WAKE UP (I'm allowed to raise my voice here, because I am following precedent). I have suggested delivering the jetty-plugin UNPACKED numerous times (as you will now find it if you build HEAD). There is NO unpack/repack needed to edit the configuration. You just edit deploy/jetty-plugin.sar/META-INF/jboss-service.xml. If I see one more reference to having to pack/repack the sar, I will go mad. The only difference between what you suggest and I suggest is the location of the Jetty files. You want to split them up (into 2 different dirs) across the JBoss distrib. I want to keep them together (in 1 dir), so that it is clearer exactly which parts of JBoss constitute Jetty, in order that anyone can replace that module trivially. I can't make it much clearer than that. I don't think that anyone has made a decent case for not having the Jetty impl present in the deploy directory. The plugin (impl and cfg) IS a deployable. However in the interests of conformity and world peace, I shall fall on my sword and repackage Jetty according to a greater wisdom. Ouch :-) Jules P.S. Did anyone actually have anything constructive to say about where Jasper should go ? Jason Dillon wrote: dislcaimer, a few beers in me after the laker game... The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Who gives a fuck? My point from the begining was that you are forcing users to unpack the fucking sar to change the config... which they will want todo. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Again who cares... j2ee blah. Likewise, the sar is a nice extension of the J2EE packaging metaphor. Sar is nice when you need to group jars... or if you want to lock config. I am not saying that sar is bad... only that our usage of it with jetty is. WE EXPECT PEOPLE TO CHANGE THE JETTY CONFIG... in fact all of the times I have used JBoss3 in production (both at work and for the website) I have had to change the config. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Dude... what is the problem with a .sar/.jar + .xml? 2 files... big deal... tell me what the problem is and we can work a solution. I have already told you over and over and now over agaion of the problem of shipping the jetty config inside of a sar. I am sorry if I seem harsh, but I think that the answere is obvious... but you are still balking on it... why? --jason - This mail sent through IMP: http://horde.org/imp/ ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
I have suggested delivering the jetty-plugin UNPACKED numerous times (as you will now find it if you build HEAD). Unpacked means there is a deploy/jetty-plugin/* I have not looked, but I was hoping to avoid this type of inconsitency in the default release. Personally I think the unpacked stuff is a hack... sure some people want it, and we have it so they can use it, but I think it is ugly and confusing and we should avoid using it in the default release. Or do you mean something else by unpacked? There is NO unpack/repack needed to edit the configuration. You just edit deploy/jetty-plugin.sar/META-INF/jboss-service.xml. Yes, I see, so this is what I wanted to avoid... now we have just complicated the configuration of the system even more... thanks. How does this make it any easier for a user to manage the configuration? Should we now unpack all sars like this so things are consistent? No this is garbage. If I see one more reference to having to pack/repack the sar, I will go mad. Well, the problem is not pack/repack anymore... The only difference between what you suggest and I suggest is the location of the Jetty files. Right so do you not see that you have special cased Jetty, based on a hack, which will only confuse users... why, why, why? You want to split them up (into 2 different dirs) across the JBoss distrib. I want to keep them together (in 1 dir), so that it is clearer exactly which parts of JBoss constitute Jetty, in order that anyone can replace that module trivially. I can't make it much clearer than that. Ok, so you keep sidestepping the solution which seems to make the most sence. 2 files, jetty-plugin jetty-service. This is still easier to manage and maintain than the unpacked version. It even provides better isolation, so that the files in the plugin archive are consistent. Really, who benifits from the exploded archive? Who? However in the interests of conformity and world peace, I shall fall on my sword and repackage Jetty according to a greater wisdom. Ouch :-) This has very little todo with world peace Jules... perhaps the sanity and learning curve of users... the ease of use by administrators and the simplification of release documentation. Fuck me... I get yelled at for using an abstract class (which was fully justified and isolated the thread logic)... with wild crys for how much I have complicated the system... blah, whatever. This is where the complication comes in. Special casing configuration of a core component... um for what reason? Because you can? You can and therefor you did complicate the configuration of the system? Tell me Jules, how does this simplify the user/admins expercence (which is what I have been pushing for all this time)? It seems that it only simplifies the release management, which I think should be simple, but there are alternatives to simplify both... you just do not want to listen to them. Why? --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
To recap: deployment type | Advantages |Disadvantages - .sar archive | 1 file | Pain in the ass to configure | digital signature | | It already works| - exploded sar | All files organized | Multiple files are exposed |within one directory |(potentially many jar files) | Uses same structure as | Can not use jar-signing |.sar archive |techniques | Easy to configure | | It already works| - external config | 2 files | Must distribute as 2 files | Easy to configure | Not set up like j2ee archives | | Doesn't work yet - I propose we allow the following: For any configuration file (or deployment descriptor) that exists within an archive, we allow an external version to override it. Ex: jetty.sar (fully compressed, with META-INF/jboss-service.xml) jetty_jboss-service_override.xml (Or something. I suck at coming up with names.) This would give us the best of all solutions. Sar's can be shipped with an embedded factory default configuration, and the user can easily override those settings by adding a configuration if they need it. Also, this gives a simple place for MBean configuration changes to be persisted. What do you think? -Larry ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
Thanks for the recap, but it is in correct. deployment type | Advantages |Disadvantages --- - - .sar archive | 1 file | Pain in the ass to configure | digital signature | | It already works| digi sigs will not work when you need to change the config. it is only useful if you have static config and want to ensure that the contents do not change. the second you need to chagne the config, you must resign... exploded sar | All files organized | Multiple files are exposed |within one directory |(potentially many jarfiles) | Uses same structure as | Can not use jar-signing |.sar archive |techniques | Easy to configure | | It already works| The major disadvantage of this is the added complextity of the configuration... there are no other directories in deploy... there do not need to be more directories there. Using an explosed archive here just complicates. Though this does simplify, it does not simplify completly... there is still some complexity to be factored out. external config | 2 files | Must distribute as 2 files | Easy to configure | Not set up like j2ee | archives | | | Doesn't work yet So, this does work. Why do you believe it does not? Fuck J2EE config, that is a fucking mess. If you want J2EE-like config then put it back in the single .sar. I belive that users would rather have easy to config, easy to understand than J2EE-like... fuck that. This is the situation where digi signature could be used to ensure the validitiy of the impl code and resources and allow the config to vary. Consider a company which provides a plugin and they provide support for it. They could sign the impl archive to ensure that users have not mucked with it. An must distribute as 2 files? What? Now you are talking about distribution, or do you mean deployment? For distribution you will want to zip/tgz these up with a simple install guide, other docs, whatever. For deployment, copy files x and y to deploy/... big deal. This is the most complicated part of this option... copying 2 files. All of the are significantly more complex. I propose we allow the following: For any configuration file (or deployment descriptor) that exists within an archive, we allow an external version to override it. Ex: jetty.sar (fully compressed, with META-INF/jboss-service.xml) jetty_jboss-service_override.xml (Or something. I suck at coming up with names.) No, why do we need this at all? Who are we trying to cater too here? Who will beninfit most from the simple solution (option c), and how will beninift from the others. I am not suggesting we make it impossible to get a or b if they want... but I am suggestion that users who want a or b have specific needs which we can not and must not assume that all of our users will have. This would give us the best of all solutions. Sar's can be shipped with an embedded factory default configuration, and the user can easily override those settings by adding a configuration if they need it. Also, this gives a simple place for MBean configuration changes to be persisted. What do you think? Um... users can already override each of these... all of the above are possible with JBoss3 today... ALL OF THEM. The matter is which is the simplest... which is going to be the easiest and most intuitive for the largest number of users who download the release. We want to make JBoss easy to use for the masses... and configurable todo as you please for everyone else. Option C, 2 files, provides the most coverage for all of these problems, and does not introduce any added release management complexity. It is the clear and simple solution... why complicate any further? --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where should the Jasper jar live ?
that is fine as it will show the usage of unpacked directories to deploy and it is a good option as well marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jules |Gosnell |Sent: Monday, June 03, 2002 1:58 PM |To: [EMAIL PROTECTED] |Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jan Bartel; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Where should the Jasper jar live ? | | |OK, | |It looks like I have been bludgeoned into seperating Jetty config and impl. | |Just for the record, Jason, I still don't think you have taken in my |suggestion. | |You seem to think that I am belligerently hanging onto the idea of |delivering Jetty in a single file, which needs unpacking, editing and |repacking in order to change the port number. | |If this is not the case - apologies | |If it is - WAKE UP (I'm allowed to raise my voice here, because I am |following precedent). | |I have suggested delivering the jetty-plugin UNPACKED numerous times (as |you will now find it if you build HEAD). | |There is NO unpack/repack needed to edit the configuration. You just |edit deploy/jetty-plugin.sar/META-INF/jboss-service.xml. | |If I see one more reference to having to pack/repack the sar, I |will go mad. | |The only difference between what you suggest and I suggest is the |location of the Jetty files. | |You want to split them up (into 2 different dirs) across the JBoss distrib. | |I want to keep them together (in 1 dir), so that it is clearer exactly |which parts of JBoss constitute Jetty, in order that anyone can replace |that module trivially. | |I can't make it much clearer than that. | |I don't think that anyone has made a decent case for not having the |Jetty impl present in the deploy directory. The plugin (impl and cfg) IS |a deployable. | |However in the interests of conformity and world peace, I shall fall on |my sword and repackage Jetty according to a greater wisdom. | |Ouch :-) | | |Jules | | |P.S. | |Did anyone actually have anything constructive to say about where Jasper |should go ? | | |Jason Dillon wrote: | dislcaimer, a few beers in me after the laker game... | | |The natural progression of all this separation of config and |implementation is that we will begin encouraging people to take all the |resources out of their ears and deploy them in lib/, then just drop the |dds into deploy/. | | | Who gives a fuck? My point from the begining was that you are |forcing users to | unpack the fucking sar to change the config... which they will want todo. | | |Ok, so they can edit their descriptors - but it's not J2EE, is it ? | | | Again who cares... j2ee blah. | | |Likewise, the sar is a nice extension of the J2EE packaging metaphor. | | | Sar is nice when you need to group jars... or if you want to |lock config. I am | not saying that sar is bad... only that our usage of it with jetty is. | | WE EXPECT PEOPLE TO CHANGE THE JETTY CONFIG... in fact all of |the times I have | used JBoss3 in production (both at work and for the website) I |have had to | change the config. | | |It may not be perfect, but this is the platform that we are |implementing, and I think consistency is important. | |Comments ? | | | Dude... what is the problem with a .sar/.jar + .xml? 2 files... |big deal... | tell me what the problem is and we can work a solution. I have |already told you | over and over and now over agaion of the problem of shipping the |jetty config | inside of a sar. | | I am sorry if I seem harsh, but I think that the answere is |obvious... but you | are still balking on it... why? | | --jason | | | - | This mail sent through IMP: http://horde.org/imp/ | | ___ | | Don't miss the 2002 Sprint PCS Application Developer's Conference | August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
What? This is insane... we do not need to complicate the default configuration as an example... Really... how do you come to these conclusions? Do you flip a coin, heads it stays, tails it goes? This is complexity... Mr. KISS is going for the complex solution... and why? --jason On Monday 03 June 2002 03:16 pm, marc fleury wrote: that is fine as it will show the usage of unpacked directories to deploy and it is a good option as well marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jules |Gosnell |Sent: Monday, June 03, 2002 1:58 PM |To: [EMAIL PROTECTED] |Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jan Bartel; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Where should the Jasper jar live ? | | |OK, | |It looks like I have been bludgeoned into seperating Jetty config and | impl. | |Just for the record, Jason, I still don't think you have taken in my |suggestion. | |You seem to think that I am belligerently hanging onto the idea of |delivering Jetty in a single file, which needs unpacking, editing and |repacking in order to change the port number. | |If this is not the case - apologies | |If it is - WAKE UP (I'm allowed to raise my voice here, because I am |following precedent). | |I have suggested delivering the jetty-plugin UNPACKED numerous times (as |you will now find it if you build HEAD). | |There is NO unpack/repack needed to edit the configuration. You just |edit deploy/jetty-plugin.sar/META-INF/jboss-service.xml. | |If I see one more reference to having to pack/repack the sar, I |will go mad. | |The only difference between what you suggest and I suggest is the |location of the Jetty files. | |You want to split them up (into 2 different dirs) across the JBoss | distrib. | |I want to keep them together (in 1 dir), so that it is clearer exactly |which parts of JBoss constitute Jetty, in order that anyone can replace |that module trivially. | |I can't make it much clearer than that. | |I don't think that anyone has made a decent case for not having the |Jetty impl present in the deploy directory. The plugin (impl and cfg) IS |a deployable. | |However in the interests of conformity and world peace, I shall fall on |my sword and repackage Jetty according to a greater wisdom. | |Ouch :-) | | |Jules | | |P.S. | |Did anyone actually have anything constructive to say about where Jasper |should go ? | |Jason Dillon wrote: | dislcaimer, a few beers in me after the laker game... | |The natural progression of all this separation of config and |implementation is that we will begin encouraging people to take all the |resources out of their ears and deploy them in lib/, then just drop the |dds into deploy/. | | Who gives a fuck? My point from the begining was that you are | |forcing users to | | unpack the fucking sar to change the config... which they will want | todo. | |Ok, so they can edit their descriptors - but it's not J2EE, is it ? | | Again who cares... j2ee blah. | |Likewise, the sar is a nice extension of the J2EE packaging metaphor. | | Sar is nice when you need to group jars... or if you want to | |lock config. I am | | not saying that sar is bad... only that our usage of it with jetty is. | | WE EXPECT PEOPLE TO CHANGE THE JETTY CONFIG... in fact all of | |the times I have | | used JBoss3 in production (both at work and for the website) I | |have had to | | change the config. | |It may not be perfect, but this is the platform that we are |implementing, and I think consistency is important. | |Comments ? | | Dude... what is the problem with a .sar/.jar + .xml? 2 files... | |big deal... | | tell me what the problem is and we can work a solution. I have | |already told you | | over and over and now over agaion of the problem of shipping the | |jetty config | | inside of a sar. | | I am sorry if I seem harsh, but I think that the answere is | |obvious... but you | | are still balking on it... why? | | --jason | | | - | This mail sent through IMP: http://horde.org/imp/ | | ___ | | Don't miss the 2002 Sprint PCS Application Developer's Conference | August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where should the Jasper jar live ?
|Really... how do you come to these conclusions? if jetty is configured through jetty.xml then we need to use the directory if jetty is configured through jboss-service.xml then we need to use a jetty-service.xml End of story. what file are we talking about? marcf ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where should the Jasper jar live ?
yes this is correct, Is jetty configured through the jboss-service.xml? if yes -- jetty-service.xml if no -- use diretory structure exploded marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Monday, June 03, 2002 3:16 PM |To: [EMAIL PROTECTED]; lsanders |Subject: Re: [JBoss-dev] Where should the Jasper jar live ? | | |Thanks for the recap, but it is in correct. | | deployment type | Advantages |Disadvantages | |--- |- - | .sar archive | 1 file | Pain in the ass |to configure | | | digital signature | | | It already works| | |digi sigs will not work when you need to change the config. it is |only useful |if you have static config and want to ensure that the contents do |not change. |the second you need to chagne the config, you must resign... | | exploded sar | All files organized | Multiple files are exposed | | |within one directory |(potentially |many jarfiles) | | Uses same structure as | Can not use jar-signing | |.sar archive |techniques | | Easy to configure | | | It already works| | |The major disadvantage of this is the added complextity of the |configuration... there are no other directories in deploy... there do not |need to be more directories there. Using an explosed archive here just |complicates. Though this does simplify, it does not simplify completly... |there is still some complexity to be factored out. | | external config | 2 files | Must distribute as 2 files | | | Easy to configure | Not set up like j2ee | | archives | | | | | Doesn't work yet | | |So, this does work. Why do you believe it does not? | |Fuck J2EE config, that is a fucking mess. If you want J2EE-like |config then |put it back in the single .sar. I belive that users would rather |have easy |to config, easy to understand than J2EE-like... fuck that. | |This is the situation where digi signature could be used to ensure the |validitiy of the impl code and resources and allow the config to vary. |Consider a company which provides a plugin and they provide |support for it. |They could sign the impl archive to ensure that users have not mucked with |it. | |An must distribute as 2 files? What? Now you are talking about |distribution, |or do you mean deployment? For distribution you will want to |zip/tgz these |up with a simple install guide, other docs, whatever. | |For deployment, copy files x and y to deploy/... big deal. This |is the most |complicated part of this option... copying 2 files. All of the are |significantly more complex. | | I propose we allow the following: For any configuration file (or | deployment descriptor) that exists within an archive, we allow |an external | version to override it. Ex: | | jetty.sar (fully compressed, with META-INF/jboss-service.xml) | jetty_jboss-service_override.xml (Or something. I suck at |coming up with | names.) | |No, why do we need this at all? Who are we trying to cater too |here? Who |will beninfit most from the simple solution (option c), and how |will beninift |from the others. I am not suggesting we make it impossible to get |a or b if |they want... but I am suggestion that users who want a or b have specific |needs which we can not and must not assume that all of our users will have. | | This would give us the best of all solutions. Sar's can be |shipped with an | embedded factory default configuration, and the user can easily override | those settings by adding a configuration if they need it. Also, |this gives | a simple place for MBean configuration changes to be persisted. What do | you think? | |Um... users can already override each of these... all of the above are |possible with JBoss3 today... ALL OF THEM. | |The matter is which is the simplest... which is going to be the |easiest and |most intuitive for the largest number of users who download the release. | |We want to make JBoss easy to use for the masses... and |configurable todo as |you please for everyone else. | |Option C, 2 files, provides the most coverage for all of these |problems, and |does not introduce any added release management complexity. | |It is the clear and simple solution... why complicate any further? | |--jason | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss
Re: [JBoss-dev] Where should the Jasper jar live ?
So there are 3 different possible locations for the configuration of jetty? How is this not complex to you? --jason On Monday 03 June 2002 03:25 pm, marc fleury wrote: |Really... how do you come to these conclusions? if jetty is configured through jetty.xml then we need to use the directory if jetty is configured through jboss-service.xml then we need to use a jetty-service.xml End of story. what file are we talking about? marcf ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where should the Jasper jar live ?
|So there are 3 different possible locations for the configuration |of jetty? no the configuration of jetty is done with jboss-service.xml marcf ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
Guys, I've already said that I would alter Jetty's packaging for Jason. Jason, where do you want Jetty's jars to go ? I just tried them in lib/ with a jetty-service.xml in deploy/ - it didn't work - I got a nice message telling me jetty-service.xml is being deployed - then nothing (this is on HEAD). Touching jetty-service.xml just gives: 23:47:05,423 INFO [MainDeployer] Starting deployment of package: file:/home/jules/cvs/JBoss/HEAD/build/output/jboss-3.1.0alpha/server/default/deploy/jetty-service.xml 23:47:05,433 INFO [SARDeployer] Created ServiceModule: null No errors - no nothing. I could move all the jars into deploy, as well - is this how you intend for it to be done ? Simply flatten the sar hierarchy into deploy ? Jules Jason Dillon wrote: So there are 3 different possible locations for the configuration of jetty? How is this not complex to you? --jason On Monday 03 June 2002 03:25 pm, marc fleury wrote: |Really... how do you come to these conclusions? if jetty is configured through jetty.xml then we need to use the directory if jetty is configured through jboss-service.xml then we need to use a jetty-service.xml End of story. what file are we talking about? marcf ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
It is becoming clear that reason is not a key player in this issue, perhaps others as well. It has been lost to cyrptic and non-sensical rambilings of a complicated world of cascading locations for configuration files. For all of you who are math buffs out there, if you sit down and think through the steps a users must go through for each of the possible options, it should be clear what direction to move in. It is simple math, shit I can even do it with out a calculator. My experence as a system administrator, managing clusters of machines across the US, managing the configuration and distribution mechanisms for updating code and config, must have alluded the mass of you at some point. Even my work on the website, where I painfully had to deal with the issues of config inside .sars, and even at my job where I had to write a layer ontop of the 2.x config system to make it work in a multi vm/multi host environment... until I rewrote it to make more sence... and still no one listens to me. Well, fuck it. Do as you do. It is very clear that my words do not hold any place in your minds as you go about your buisness of complication. I do believe that all of you have missed the point. I have spent several weeks trying to show you the error of your ways and I have grown tired, so very tired. Do as you do... --jason On Monday 03 June 2002 03:27 pm, marc fleury wrote: yes this is correct, Is jetty configured through the jboss-service.xml? if yes -- jetty-service.xml if no -- use diretory structure exploded marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Monday, June 03, 2002 3:16 PM |To: [EMAIL PROTECTED]; lsanders |Subject: Re: [JBoss-dev] Where should the Jasper jar live ? | | |Thanks for the recap, but it is in correct. | | deployment type | Advantages |Disadvantages | |-- |- | |- - | .sar archive | 1 file | Pain in the ass | |to configure | | | digital signature | | | It already works| | |digi sigs will not work when you need to change the config. it is |only useful |if you have static config and want to ensure that the contents do |not change. |the second you need to chagne the config, you must resign... | | exploded sar | All files organized | Multiple files are | exposed | | |within one directory |(potentially | |many jarfiles) | | | Uses same structure as | Can not use jar-signing | |.sar archive |techniques | | Easy to configure | | | It already works| | |The major disadvantage of this is the added complextity of the |configuration... there are no other directories in deploy... there do not |need to be more directories there. Using an explosed archive here just |complicates. Though this does simplify, it does not simplify completly... |there is still some complexity to be factored out. | | external config | 2 files | Must distribute as 2 | files | | | Easy to configure | Not set up like j2ee | | archives | | | | | Doesn't work yet | |So, this does work. Why do you believe it does not? | |Fuck J2EE config, that is a fucking mess. If you want J2EE-like |config then |put it back in the single .sar. I belive that users would rather |have easy |to config, easy to understand than J2EE-like... fuck that. | |This is the situation where digi signature could be used to ensure the |validitiy of the impl code and resources and allow the config to vary. |Consider a company which provides a plugin and they provide |support for it. |They could sign the impl archive to ensure that users have not mucked with |it. | |An must distribute as 2 files? What? Now you are talking about |distribution, |or do you mean deployment? For distribution you will want to |zip/tgz these |up with a simple install guide, other docs, whatever. | |For deployment, copy files x and y to deploy/... big deal. This |is the most |complicated part of this option... copying 2 files. All of the are |significantly more complex. | | I propose we allow the following: For any configuration file (or | deployment descriptor) that exists within an archive, we allow | |an external | | version to override it. Ex: | | jetty.sar (fully compressed, with META-INF/jboss-service.xml) | jetty_jboss-service_override.xml (Or something. I suck at | |coming up with | | names.) | |No, why do we need this at all? Who are we trying to cater too |here? Who |will beninfit most from the simple solution (option c), and how
Re: [JBoss-dev] Where should the Jasper jar live ?
digi sigs will not work when you need to change the config. it is only useful if you have static config and want to ensure that the contents do not change. the second you need to chagne the config, you must resign... Right. The point is, it can be distributed with a signature, as long as you don't need to do any custom configuration. The major disadvantage of this is the added complextity of the configuration... I (and it sounds like Marc and Jules are with me) will forever disagree with you on the usefulness of exploded archives. I find them useful - you don't. I do agree that they are not the perfect solution, and you also agree that it simplifies things at least a little. I'm content to leave it at that. So, this does work. Why do you believe it does not? Mental hicup. Of course you are right, the separate configurations do indeed work. Fuck J2EE config, that is a fucking mess. I am inclined to agree with you here - configuring an ejb is a pain in the ass. I listed it as a disadvantage simply because it is different than what users are used to. An must distribute as 2 files? What? Now you are talking about distribution, or do you mean deployment? There are a number of deployments that rarely (or never) need any custom configuration. In these cases, the best solution is the traditional .sar with config included. To make them shuffle 2 files is not a huge deal, but I do count it as a disadvantage. I propose we allow the following: For any configuration file (or deployment descriptor) that exists within an archive, we allow an external version to override it. Ex: jetty.sar (fully compressed, with META-INF/jboss-service.xml) jetty_jboss-service_override.xml (Or something. I suck at coming up with names.) No, why do we need this at all? Who are we trying to cater too here? Who will beninfit most from the simple solution (option c), and how will beninift from the others. I am not suggesting we make it impossible to get a or b if they want... but I am suggestion that users who want a or b have specific needs which we can not and must not assume that all of our users will have. Option a is best for those deployment's where you never need to touch a configuration file. Option b is best for people developing something that will eventually be deployed as an Option a. Option c is best for 3rd party deployments where custom configuration is needed. I think we agree here, yes? My proposal offers a solution to two additional problems. 1) How do we persist configuration changes 2) What's the best way to distribute a deployment that rarely needs configuration. We need to solve the persistent configuration problem anyway. The solution that jumps to mind (support an external configuration file that overrides the internal one) also happens to provide an answer for problem 2. -Larry ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where should the Jasper jar live ?
what the fuck is your problem? stop throwing your experience around, I am not the bad widtch around here, what I am saying in my mail is | Is jetty configured through the jboss-service.xml? | | if yes -- jetty-service.xml | if no -- use diretory structure exploded and the jetty service is configured through jetty-service.xml you are not a math-buff, just a sys-admin, but if you turned the common sense on, the only material worth anything in the first place (I know a math buff that lack a lot of it :) you would see that the above statement and bla bla is saying... you are right. so get off the heroin of insecurity, sniff the brain common sense and stop feeling so lonely marcf | | marcf | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason | |Dillon | |Sent: Monday, June 03, 2002 3:16 PM | |To: [EMAIL PROTECTED]; lsanders | |Subject: Re: [JBoss-dev] Where should the Jasper jar live ? | | | | | |Thanks for the recap, but it is in correct. | | | | deployment type | Advantages |Disadvantages | | | ||-- | |- | | | |- - | | .sar archive | 1 file | Pain in the ass | | | |to configure | | | | | digital signature | | | | It already works| | | | |digi sigs will not work when you need to change the config. it is | |only useful | |if you have static config and want to ensure that the contents do | |not change. | |the second you need to chagne the config, you must resign... | | | | exploded sar | All files organized | Multiple files are | | exposed | | | | |within one directory |(potentially | | | |many jarfiles) | | | | | Uses same structure as | Can not use jar-signing | | |.sar archive |techniques | | | Easy to configure | | | | It already works| | | | |The major disadvantage of this is the added complextity of the | |configuration... there are no other directories in deploy... |there do not | |need to be more directories there. Using an explosed archive here just | |complicates. Though this does simplify, it does not simplify |completly... | |there is still some complexity to be factored out. | | | | external config | 2 files | Must distribute as 2 | | files | | | | | Easy to configure | Not set up like j2ee | | | archives | | | | | | | Doesn't work yet | | | |So, this does work. Why do you believe it does not? | | | |Fuck J2EE config, that is a fucking mess. If you want J2EE-like | |config then | |put it back in the single .sar. I belive that users would rather | |have easy | |to config, easy to understand than J2EE-like... fuck that. | | | |This is the situation where digi signature could be used to ensure the | |validitiy of the impl code and resources and allow the config to vary. | |Consider a company which provides a plugin and they provide | |support for it. | |They could sign the impl archive to ensure that users have not |mucked with | |it. | | | |An must distribute as 2 files? What? Now you are talking about | |distribution, | |or do you mean deployment? For distribution you will want to | |zip/tgz these | |up with a simple install guide, other docs, whatever. | | | |For deployment, copy files x and y to deploy/... big deal. This | |is the most | |complicated part of this option... copying 2 files. All of the are | |significantly more complex. | | | | I propose we allow the following: For any configuration file (or | | deployment descriptor) that exists within an archive, we allow | | | |an external | | | | version to override it. Ex: | | | | jetty.sar (fully compressed, with META-INF/jboss-service.xml) | | jetty_jboss-service_override.xml (Or something. I suck at | | | |coming up with | | | | names.) | | | |No, why do we need this at all? Who are we trying to cater too | |here? Who | |will beninfit most from the simple solution (option c), and how | |will beninift | |from the others. I am not suggesting we make it impossible to get | |a or b if | |they want... but I am suggestion that users who want a or b |have specific | |needs which we can not and must not assume that all of our users will | | have. | | | | This would give us the best of all solutions. Sar's can be | | | |shipped with an | | | | embedded factory default configuration, and the user can |easily override | | those settings by adding a configuration if they need it. Also, | | | |this gives | | | | a simple place for MBean configuration changes to be |persisted. What do | | you think? | | | |Um... users can already override each of these... all of the above are | |possible with JBoss3 today... ALL OF THEM. | | | |The matter is which
Re: [JBoss-dev] Where should the Jasper jar live ?
I am not a sys-admin anymore. And your emails about jetty.xml, jboss-service.xml and jetty-service.xml make no sense... perhaps you have meant something different, but as you have written (several times and inconsistently) makes no sense. My problem is that I care to much about getting things done right... and I believe that I am right... that is my problem. Any ways... I have given up trying to explain. I will go work on something else and leave this to someone else... --jason On Monday 03 June 2002 05:02 pm, marc fleury wrote: what the fuck is your problem? stop throwing your experience around, I am not the bad widtch around here, what I am saying in my mail is | Is jetty configured through the jboss-service.xml? | | if yes -- jetty-service.xml | if no -- use diretory structure exploded and the jetty service is configured through jetty-service.xml you are not a math-buff, just a sys-admin, but if you turned the common sense on, the only material worth anything in the first place (I know a math buff that lack a lot of it :) you would see that the above statement and bla bla is saying... you are right. so get off the heroin of insecurity, sniff the brain common sense and stop feeling so lonely marcf | marcf | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On Behalf Of | | Jason Dillon | |Sent: Monday, June 03, 2002 3:16 PM | |To: [EMAIL PROTECTED]; lsanders | |Subject: Re: [JBoss-dev] Where should the Jasper jar live ? | | | | | |Thanks for the recap, but it is in correct. | | | | deployment type | Advantages |Disadvantages || ||- ||- || | |- | | | |- - | | .sar archive | 1 file | Pain in the ass | | | |to configure | | | | | digital signature | | | | It already works| | | | |digi sigs will not work when you need to change the config. it is | |only useful | |if you have static config and want to ensure that the contents do | |not change. | |the second you need to chagne the config, you must resign... | | | | exploded sar | All files organized | Multiple files are | | exposed | | | | |within one directory |(potentially | | | |many jarfiles) | | | | | Uses same structure as | Can not use | | | jar-signing .sar archive |techniques | | | Easy to configure | | | | It already works| | | | |The major disadvantage of this is the added complextity of the | |configuration... there are no other directories in deploy... | |there do not | | |need to be more directories there. Using an explosed archive here just | |complicates. Though this does simplify, it does not simplify | |completly... | | |there is still some complexity to be factored out. | | | | external config | 2 files | Must distribute as 2 | | files | | | | | Easy to configure | Not set up like j2ee | | | archives | | | | | | | Doesn't work yet | | | |So, this does work. Why do you believe it does not? | | | |Fuck J2EE config, that is a fucking mess. If you want J2EE-like | |config then | |put it back in the single .sar. I belive that users would rather | |have easy | |to config, easy to understand than J2EE-like... fuck that. | | | |This is the situation where digi signature could be used to ensure the | |validitiy of the impl code and resources and allow the config to vary. | |Consider a company which provides a plugin and they provide | |support for it. | |They could sign the impl archive to ensure that users have not | |mucked with | | |it. | | | |An must distribute as 2 files? What? Now you are talking about | |distribution, | |or do you mean deployment? For distribution you will want to | |zip/tgz these | |up with a simple install guide, other docs, whatever. | | | |For deployment, copy files x and y to deploy/... big deal. This | |is the most | |complicated part of this option... copying 2 files. All of the are | |significantly more complex. | | | | I propose we allow the following: For any configuration file (or | | deployment descriptor) that exists within an archive, we allow | | | |an external | | | | version to override it. Ex: | | | | jetty.sar (fully compressed, with META-INF/jboss-service.xml) | | jetty_jboss-service_override.xml (Or something. I suck at | | | |coming up with | | | | names.) | | | |No, why do we need this at all? Who are we trying to cater too | |here? Who | |will beninfit most from the simple solution (option c), and how | |will beninift | |from the others. I am not suggesting we make it impossible to get
Re: [JBoss-dev] Where should the Jasper jar live ?
Maybe having to install and learn to manage emacs and custom edit the emacs config to modify the Jetty log system (for example) is a bit too much for the average Windows user. Not my case (I use emacs every now and then), but I see this as a major handicap for spreading use of the JBoss/Jetty bundle and subsequent world domination :). I see Scott point of view more practical. OTOH, I also agree that this approach should not be the general case, but necesary for this. I say this because I have to modify every now and then Jetty files and having them on a SAR by default is a PITA. James Higginbotham wrote: David, You can add any extension to the archive mode with the following code in your .emacs: (setq auto-mode-alist (cons '(\\.sar$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.war$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.ear$ . archive-mode) auto-mode-alist)) Share and Enjoy, James -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:07 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I still like the sar concept. I notice that emacs can edit files in jars (such as ejb-jar.xml) and save them back into the jar. Anyone know enough elisp to figure out how to make it edit .sar, .ear, .war, etc the same way? (I presume it just means recognizing the file format/extension as zip-like) Then there won't be anything to complain about having to repack for small changes. For large changes you'll be doing an ant build anyway. david jencks On 2002.05.31 21:04:26 -0400 Jules Gosnell wrote: The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Likewise, the sar is a nice extension of the J2EE packaging metaphor. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Jules Scott M Stark wrote: That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp
RE: [JBoss-dev] Where should the Jasper jar live ?
|take all the | |resources out of their ears and deploy them in lib/, then | |just drop the | |dds into deploy/. | |Ok, so they can edit their descriptors - but it's not J2EE, is it ? This is the future yes, for all the deployment types. marcf ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where should the Jasper jar live ?
WinZip 8.1 allows you to click on a file to edit it. When you are done, it prompts you whether you want to update the file in the archive. The only braindead thing is it only works with files in the root directory of the archive. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ignacio Coloma Sent: Sunday, June 02, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where should the Jasper jar live ? Maybe having to install and learn to manage emacs and custom edit the emacs config to modify the Jetty log system (for example) is a bit too much for the average Windows user. Not my case (I use emacs every now and then), but I see this as a major handicap for spreading use of the JBoss/Jetty bundle and subsequent world domination :). I see Scott point of view more practical. OTOH, I also agree that this approach should not be the general case, but necesary for this. I say this because I have to modify every now and then Jetty files and having them on a SAR by default is a PITA. James Higginbotham wrote: David, You can add any extension to the archive mode with the following code in your .emacs: (setq auto-mode-alist (cons '(\\.sar$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.war$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.ear$ . archive-mode) auto-mode-alist)) Share and Enjoy, James -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:07 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I still like the sar concept. I notice that emacs can edit files in jars (such as ejb-jar.xml) and save them back into the jar. Anyone know enough elisp to figure out how to make it edit .sar, .ear, .war, etc the same way? (I presume it just means recognizing the file format/extension as zip-like) Then there won't be anything to complain about having to repack for small changes. For large changes you'll be doing an ant build anyway. david jencks On 2002.05.31 21:04:26 -0400 Jules Gosnell wrote: The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Likewise, the sar is a nice extension of the J2EE packaging metaphor. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Jules Scott M Stark wrote: That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL
Re: [JBoss-dev] Where should the Jasper jar live ?
Why have a sar of jars and a separate service.xml ? You might as well do as Scott suggests and collapse all the jars into one. Besides, if a sar is not deployable (because it has no dd) and therefore does not encapsulate a JMX service - why call it a sar ? A sar of jars is a convient construct with respect to the build system. No need to use crappy jlink task or to unjar/rejar which will cause thr build to make a new target archive each time. I assume you are suggesting this is order that people can easily edit the jetty-service.xml ? Um yes... bingo. Users will want to and need to change the Jetty config. Both of you guys... I have been asked several times why I do not separate jetty implementation and configuration... I do not recall you ever asking to seperate, only requesting not too for release management reasons. I see the Jetty plugin as a module of the JBoss MicroKernel. That module should be self-contained, so that e.g. you could swap out Jetty and swap in Tomcat, or just swap out your web-container if you do not want it. Yes, it is... but so is everything else. Does this mean that we should make every deployable into an .sar? Certainly not, asd that will be a royal pain in the buttocks. ;) If you just swap out the config, you are left with a load of classes in your tree which you are not using. Certainly, but this back to the one vs. two file problem. I belive that when enducated users can handle the extra file. I believe they will appreciate the seperation... and if they don't they are free to make it one. If you are upgrading versions of a plugin, it is simpler to copy in one file than two. Please... this is a very, very, very weak argument dude. If a user is upgrading the chances are very high that the configuration will differ in the new config... not that the default Jetty config changed, but that the user changed it so if you break it down into steps, 2 files is less work than 1 .sar. Do the math, if you need me to spell it out I will. Jetty is still an independant project, with it's own release schedules, and this is a useful feature for us. Yes, but it is also imported into our sources, which removes the release problem... actully replace that problem with a few more (import change management, module integration and build system maintenence). But that is a completly different story. As I preemtively struck in my first mail - run the sar unpacked, if you need quick access to the config. We could even distribute the jetty-plugin unpacked. A unpacked .sar is the .jars in lib/ and the config in deploy/, which gets us back to more than 2 files and thus an mangement problem. I think that the sar is a nice encapsulation of a JBoss service, the natural way to deploy services on the JBoss MicroKernel. It is and it is not. It is because it is a natural mechanism to group files and can be used to seal configuration for static services or where jar signing is used to ensure the config integrety. It is not, because it make more work for our users (you know the folks we put all the work in for... that includes folks who give us money too). It makes a desicion for them based on asumptions which may not be true. I assert that the cases where sar with config is useful is relativly minor compaired to the alternative. Jetty sar + config is only useful for people who are fine running on 8080 and are fine with the request log and don't need ssl or anything else. Why do we provide in the default release a component (actually a few components) which are a pain in the ass to configure. The world needs less pain... and if pain is what they want they can .sar it themselves. Why then are the chief architect and the guy who came up with the idea no longer backing it ? The service archive/service controller idea I pitched months ago was very specific about keeping configuration seperate from impl classes and resources. VERY SPECIFIFC. I have been working with configuration manegment for close to 10 years.. well could be 8 but whos counting. Binging config up with impl is a nice feature, but is does not make the job of setting up and managing the configuration of a system and easier.. in fact with out tools to automate the work involved with keeping and maintaining config in a sar it is a nightmare. So how does one fix this... well they either write a config system around this (which if you read my original birds email that is what I was leaning twords, a programatical aproache to linking server impl to config) or you unpack all of the sars and manage your own jboss dist... making it more work to update when a new rev is out. * * * There is no reason to put the jetty service config in the plugin sar... there are only reasons not to. As for .sar w/ .jars or a single .jar I don't care. This is like night and day to me. I have looked at this from all sides and the best option is a .sar/fat .jar + service.xml. I
RE: [JBoss-dev] Where should the Jasper jar live ?
David, You can add any extension to the archive mode with the following code in your .emacs: (setq auto-mode-alist (cons '(\\.sar$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.war$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.ear$ . archive-mode) auto-mode-alist)) Share and Enjoy, James -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:07 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I still like the sar concept. I notice that emacs can edit files in jars (such as ejb-jar.xml) and save them back into the jar. Anyone know enough elisp to figure out how to make it edit .sar, .ear, .war, etc the same way? (I presume it just means recognizing the file format/extension as zip-like) Then there won't be anything to complain about having to repack for small changes. For large changes you'll be doing an ant build anyway. david jencks On 2002.05.31 21:04:26 -0400 Jules Gosnell wrote: The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Likewise, the sar is a nice extension of the J2EE packaging metaphor. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Jules Scott M Stark wrote: That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las
Re: [JBoss-dev] Where should the Jasper jar live ?
Jules, how about making the jetty-plugin.sar just contain the jars and have a seperate jetty-service.xml? --jason On Friday 31 May 2002 04:31 pm, Jules Gosnell wrote: Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
I had a feeling I would never sneak this through without opening a can of worms. Jason, Why have a sar of jars and a separate service.xml ? You might as well do as Scott suggests and collapse all the jars into one. Besides, if a sar is not deployable (because it has no dd) and therefore does not encapsulate a JMX service - why call it a sar ? Scott, I assume you are suggesting this is order that people can easily edit the jetty-service.xml ? Both of you guys... I have been asked several times why I do not separate jetty implementation and configuration... I see the Jetty plugin as a module of the JBoss MicroKernel. That module should be self-contained, so that e.g. you could swap out Jetty and swap in Tomcat, or just swap out your web-container if you do not want it. If you just swap out the config, you are left with a load of classes in your tree which you are not using. If you are upgrading versions of a plugin, it is simpler to copy in one file than two. Jetty is still an independant project, with it's own release schedules, and this is a useful feature for us. As I preemtively struck in my first mail - run the sar unpacked, if you need quick access to the config. We could even distribute the jetty-plugin unpacked. I think that the sar is a nice encapsulation of a JBoss service, the natural way to deploy services on the JBoss MicroKernel. Why then are the chief architect and the guy who came up with the idea no longer backing it ? Jules Jason Dillon wrote: Jules, how about making the jetty-plugin.sar just contain the jars and have a seperate jetty-service.xml? --jason On Friday 31 May 2002 04:31 pm, Jules Gosnell wrote: Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Likewise, the sar is a nice extension of the J2EE packaging metaphor. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Jules Scott M Stark wrote: That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
Ultimately the configuration of every mbean is going to be seperate from its implementation to support persistence of changes made through the management interface. Install the jetty sar as an unpackaged distribution then since the web service is the most likely item users will want to configure off the default. Sar vs service.xml + jar are the same in my book and trying to define one as superior to other in all cases is just mental masterbation. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Jan Bartel [EMAIL PROTECTED]; jason [EMAIL PROTECTED] Sent: Friday, May 31, 2002 5:59 PM Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I had a feeling I would never sneak this through without opening a can of worms. Jason, Why have a sar of jars and a separate service.xml ? You might as well do as Scott suggests and collapse all the jars into one. Besides, if a sar is not deployable (because it has no dd) and therefore does not encapsulate a JMX service - why call it a sar ? Scott, I assume you are suggesting this is order that people can easily edit the jetty-service.xml ? Both of you guys... I have been asked several times why I do not separate jetty implementation and configuration... I see the Jetty plugin as a module of the JBoss MicroKernel. That module should be self-contained, so that e.g. you could swap out Jetty and swap in Tomcat, or just swap out your web-container if you do not want it. If you just swap out the config, you are left with a load of classes in your tree which you are not using. If you are upgrading versions of a plugin, it is simpler to copy in one file than two. Jetty is still an independant project, with it's own release schedules, and this is a useful feature for us. As I preemtively struck in my first mail - run the sar unpacked, if you need quick access to the config. We could even distribute the jetty-plugin unpacked. I think that the sar is a nice encapsulation of a JBoss service, the natural way to deploy services on the JBoss MicroKernel. Why then are the chief architect and the guy who came up with the idea no longer backing it ? Jules ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
Scott M Stark wrote: Ultimately the configuration of every mbean is going to be seperate from its implementation to support persistence of changes made through the management interface. So will this persistant configuration be laid over the static dd one, or will it replace the dd ? If config and implementation version are tightly bound - e.g. I release a new version of the impl that requires particular attributes set in it's config, will there be a mechanism for shipping them together - say, across the web (netboot) or around a cluster ? Jules Install the jetty sar as an unpackaged distribution then since the web service is the most likely item users will want to configure off the default. Sar vs service.xml + jar are the same in my book and trying to define one as superior to other in all cases is just mental masterbation. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Jan Bartel [EMAIL PROTECTED]; jason [EMAIL PROTECTED] Sent: Friday, May 31, 2002 5:59 PM Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I had a feeling I would never sneak this through without opening a can of worms. Jason, Why have a sar of jars and a separate service.xml ? You might as well do as Scott suggests and collapse all the jars into one. Besides, if a sar is not deployable (because it has no dd) and therefore does not encapsulate a JMX service - why call it a sar ? Scott, I assume you are suggesting this is order that people can easily edit the jetty-service.xml ? Both of you guys... I have been asked several times why I do not separate jetty implementation and configuration... I see the Jetty plugin as a module of the JBoss MicroKernel. That module should be self-contained, so that e.g. you could swap out Jetty and swap in Tomcat, or just swap out your web-container if you do not want it. If you just swap out the config, you are left with a load of classes in your tree which you are not using. If you are upgrading versions of a plugin, it is simpler to copy in one file than two. Jetty is still an independant project, with it's own release schedules, and this is a useful feature for us. As I preemtively struck in my first mail - run the sar unpacked, if you need quick access to the config. We could even distribute the jetty-plugin unpacked. I think that the sar is a nice encapsulation of a JBoss service, the natural way to deploy services on the JBoss MicroKernel. Why then are the chief architect and the guy who came up with the idea no longer backing it ? Jules ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
Scott M Stark wrote: Ultimately the configuration of every mbean is going to be seperate from its implementation to support persistence of changes made through the management interface. So will this persistant configuration be laid over the static dd one, or will it replace the dd ? If config and implementation version are tightly bound - e.g. I release a new version of the impl that requires particular attributes set in it's config, will there be a mechanism for shipping them together - say, across the web (netboot) or around a cluster ? Jules There will have to be some notion of config version so that the persistent data either takes precendence, or will be overwritten or even merged. An updated deployment may even specify a xslt transform that dictates this. Who knows, its in the ever brighter future of JBoss where even more is possible. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
I still like the sar concept. I notice that emacs can edit files in jars (such as ejb-jar.xml) and save them back into the jar. Anyone know enough elisp to figure out how to make it edit .sar, .ear, .war, etc the same way? (I presume it just means recognizing the file format/extension as zip-like) Then there won't be anything to complain about having to repack for small changes. For large changes you'll be doing an ant build anyway. david jencks On 2002.05.31 21:04:26 -0400 Jules Gosnell wrote: The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Likewise, the sar is a nice extension of the J2EE packaging metaphor. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Jules Scott M Stark wrote: That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
I agree here completly. In most cases users will want to change the config for jetty... a split impl and config lets them do this with relative ease. This does not compremise and of the release seperation that Jules has the jones for either, instead of one file to manage he now has 2, big deal. Sar with nested jars is a little easier from the build system perspective, as the jlink taks, which is unsed to merger jars is still kinda wacky. But I don't care one jar or sar w/jars. I do care that the servic.xml is outside of that though... it is the logical and resonable thing todo... so lets do it! --jason Quoting Scott M Stark [EMAIL PROTECTED]: Ultimately the configuration of every mbean is going to be seperate from its implementation to support persistence of changes made through the management interface. Install the jetty sar as an unpackaged distribution then since the web service is the most likely item users will want to configure off the default. Sar vs service.xml + jar are the same in my book and trying to define one as superior to other in all cases is just mental masterbation. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Jan Bartel [EMAIL PROTECTED]; jason [EMAIL PROTECTED] Sent: Friday, May 31, 2002 5:59 PM Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I had a feeling I would never sneak this through without opening a can of worms. Jason, Why have a sar of jars and a separate service.xml ? You might as well do as Scott suggests and collapse all the jars into one. Besides, if a sar is not deployable (because it has no dd) and therefore does not encapsulate a JMX service - why call it a sar ? Scott, I assume you are suggesting this is order that people can easily edit the jetty-service.xml ? Both of you guys... I have been asked several times why I do not separate jetty implementation and configuration... I see the Jetty plugin as a module of the JBoss MicroKernel. That module should be self-contained, so that e.g. you could swap out Jetty and swap in Tomcat, or just swap out your web-container if you do not want it. If you just swap out the config, you are left with a load of classes in your tree which you are not using. If you are upgrading versions of a plugin, it is simpler to copy in one file than two. Jetty is still an independant project, with it's own release schedules, and this is a useful feature for us. As I preemtively struck in my first mail - run the sar unpacked, if you need quick access to the config. We could even distribute the jetty-plugin unpacked. I think that the sar is a nice encapsulation of a JBoss service, the natural way to deploy services on the JBoss MicroKernel. Why then are the chief architect and the guy who came up with the idea no longer backing it ? Jules ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
dislcaimer, a few beers in me after the laker game... The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Who gives a fuck? My point from the begining was that you are forcing users to unpack the fucking sar to change the config... which they will want todo. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Again who cares... j2ee blah. Likewise, the sar is a nice extension of the J2EE packaging metaphor. Sar is nice when you need to group jars... or if you want to lock config. I am not saying that sar is bad... only that our usage of it with jetty is. WE EXPECT PEOPLE TO CHANGE THE JETTY CONFIG... in fact all of the times I have used JBoss3 in production (both at work and for the website) I have had to change the config. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Dude... what is the problem with a .sar/.jar + .xml? 2 files... big deal... tell me what the problem is and we can work a solution. I have already told you over and over and now over agaion of the problem of shipping the jetty config inside of a sar. I am sorry if I seem harsh, but I think that the answere is obvious... but you are still balking on it... why? --jason - This mail sent through IMP: http://horde.org/imp/ ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
