giant snip, obscuring the problem that I don't understand what the
problems with the current deployer design or scanner design are or why it
should be changed... seems fine to me
David, if you are reading this... and got this far down... what is the
plan to
have this issue tied down and
But this thread was started by you, whose original complaint was that it is
difficult to configure packaged archives. The answer is staring you in the
face and you can't see it... Deploy these as exploded archives, and modify
the configurations whenever you want.
I don't want to manage the
David, if you are reading this... and got this far down... what is the
plan to
have this issue tied down and solved once and for all. I think the
approche
that dain, you and I discussed in Tahoe is along the correct lines.
Do you have any idea when the wrinkles will be sorted
On Sun, Apr 21, 2002 at 07:11:52PM -0400, David Jencks wrote:
3. I'd like to have an actual user ask for this over explicitly listing the
files in the deployment scanner.
I'm an actual user, and just the thought of reording by typing a bunch of
% mv 05my-application.war 06my-application.war
On Sun, Apr 21, 2002 at 04:27:14PM -0700, Jason Dillon wrote:
Think if we wanted
to start signing these performing cert verificatrion to ensure users have
valid plugins. We can't have them changing the contents then.
This is a very good point which seems to have gotten lost in the thread.
Michael Robinson wrote:
On Sun, Apr 21, 2002 at 07:11:52PM -0400, David Jencks wrote:
3. I'd like to have an actual user ask for this over explicitly listing the
files in the deployment scanner.
I'm an actual user, and just the thought of reording by typing a bunch of
% mv
So then you did like the way jboss-auto.jcml worked. I did not.
Regards,
Hiram
From: Jason Dillon [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
Date: Sun, 21 Apr 2002 22:18
Anyway, I think there is a real bug nearby that we
need to fix. See
http://jboss.org/forums/thread.jsp?forum=46thread=1346start=0msRange=15
If a jar file references a nonexistent jar file in
the manifest classpath
entry, something (the scanner???) goes haywire and
keeps trying to
On 2002.04.22 02:41:50 -0400 Jason Dillon wrote:
David, if you are reading this... and got this far down... what is
the
plan to
have this issue tied down and solved once and for all. I think the
approche
that dain, you and I discussed in Tahoe is along the correct lines.
On 2002.04.22 11:26:06 -0400 Larry Sanderson wrote:
Anyway, I think there is a real bug nearby that we
need to fix. See
http://jboss.org/forums/thread.jsp?forum=46thread=1346start=0msRange=15
If a jar file references a nonexistent jar file in
the manifest classpath
entry,
PROTECTED]
|Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
|
|
|I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention
|a little less likely to stumbled upon by unknowing users. I suggest:
|jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for
|indexed
I am checking out of this bullshit,
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
]
|Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
|
|
|I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention
|a little less likely to stumbled upon by unknowing users. I suggest:
|jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for
|indexed
]:
So then you did like the way jboss-auto.jcml worked. I did not.
Regards,
Hiram
From: Jason Dillon [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
Date: Sun, 21 Apr
1. Related to these problems is the question of how we should store
persistent mbean attributes and the desired relationship between these
persistent attributes from storage and those from a possibly modified
config file. Remember the bad old days of jboss-auto.jcml? That is gone
but no
1. Related to these problems is the question of how we should store
persistent mbean attributes and the desired relationship between these
persistent attributes from storage and those from a possibly modified
config file. Remember the bad old days of jboss-auto.jcml? That is gone
but no
I am afraid I beg to differ. I think that the SAR is an excellent concept
and approach. First of all it is simple. Simple is good. Sometimes
simple doesn't cover all the bases, but being too complex can make
something unusable. In JBoss 2.4x, I had created an alternate solution,
but it
Here is an alternate idea, something that would co-exist with the .sar
concept. Each MBean has a name that makes it unique. Build an XML file
with a name space, essentially an element for each MBean that has had its
configuration changed from the original .sar archive's jboss-service.xml
Ok, so I was wrong about my seperated Jetty working...
I setup a webapp with:
Call name=addWebApplication
Arg//Arg ArgSystemPropertyname=jboss.server.home.dir//webapp/Arg
Set name=extractWARfalse/Set
/Call
Then I extracted an example .war at that path, hit a .html, which worked fine... then
a
I weighed up the pros and cons of how Jetty should be distributed and
decided to leave it in a sar for the time being because it makes it much
easier to redistribute and install updated versions of Jetty and Jetty
is an independant project with a seperate release cycle, so this is a
I weighed up the pros and cons of how Jetty should be distributed and
decided to leave it in a sar for the time being because it makes it much
easier to redistribute and install updated versions of Jetty and Jetty
is an independant project with a seperate release cycle, so this is a
don't be an ignorant bastard on your own idea and its actual implementation.
|Take Jetty for example. I am a user and I want to change the
|port, or enable SSL or add a non-deployed webapp for
|development... how do I do that? I have to break open the
|jetty-plugin.sar, change
I currently deploy jetty-plugin.sar as an exploded archive. Best of both
worlds: convenient organization, ability to modify jboss-service.xml on the
fly, will automatically redeploy whenever the xml is touched.
-Larry
Well, perhaps not completly sucky, but as it is now it does suck. When I
snip the rant
Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING OF
DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER.
If I do 01first.sar and 02second.war do I get 01 first and 02 second?
YES=NO
?
umm YES != No
the answer is NO
If you want deployments in a specific
Jason Dillon wrote:
I weighed up the pros and cons of how Jetty should be distributed and
decided to leave it in a sar for the time being because it makes it much
easier to redistribute and install updated versions of Jetty and Jetty
is an independant project with a seperate release cycle, so
Thanks, Larry,
This is exactly the approach that I was suggesting.
Jules
Larry Sanderson wrote:
I currently deploy jetty-plugin.sar as an exploded archive. Best of both
worlds: convenient organization, ability to modify jboss-service.xml on the
fly, will automatically redeploy whenever
yes clearly best of both worlds.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Larry
|Sanderson
|Sent: Sunday, April 21, 2002 9:13 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
|
|
|I currently deploy jetty
??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
|
|
|snip the rant
| Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING
OF
| DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER.
|
| If I do 01first.sar and 02second.war do I get 01 first and 02 second?
|
| YES=NO
|
| ?
|
|
|umm YES
|just I haven't taken the time to find out how the deployment works or test
I wrote the fucking deployment.
|it, and my pet idea isn't implemented, so I'm going to bitch
No in fact it is the contrary my pet idea was the directory names
first/second/third this is what the class in London
All my problems with your idea of lexical ordering of deployment would go
away if it was optional, per directory. I can see that sometimes it will
be convenient. I don't want to have to number all the more-or-less
required packages in deploy, however.
How about if the deployment scanner mbean
No in fact it is the contrary my pet idea was the directory names
first/second/third this is what the class in London decided was the
simplest
to use (as opposed to going and setting mbean names left and right which
is
the direction you are heading full speed).
My 2 cents:
For users who
| mbean code=org.jboss.deployment.scanner.URLDeploymentScanner
|name=jboss.deployment:type=DeploymentScanner,flavor=URL
|
|!-- Uncomment (and comment/remove version below) to enable usage of
|the DeploymentCache
|depends
On 2002.04.21 15:46:46 -0400 marc fleury wrote:
| mbean code=org.jboss.deployment.scanner.URLDeploymentScanner
| name=jboss.deployment:type=DeploymentScanner,flavor=URL
|
|!-- Uncomment (and comment/remove version below) to enable usage of
|the DeploymentCache
|depends
|Anyway I'm starting to think being able to order deployments this way is
|probably a good idea, see my other post, just don't make it the only way.
I agree, so let's drop it. I want the simplest numbering available
'UNIX-styleee' and for more advanced (read have time) then the xml based
As larry said (do you have rw yet?)
Yup. I've already checked in at least one bug :-)
let's not shove it down people's throat
and let's document all of this. Case closed. Implementation needed :)
Simple, and not too hacked implementation:
Add MBean attribute to URLDeploymentScanner:
I'm not sure specifying the global sorter for a whole scanner is the way we
want to go... on the other hand extensibility is nice... Do we want to
encourage people to have lots of scanners?
At the risk of making things more complicated than necessary, yet striving
for simplicity, how about
|-Original Message-
|From: David Jencks [mailto:[EMAIL PROTECTED]]
|Sent: Sunday, April 21, 2002 9:45 AM
|To: marc fleury
|Cc: [EMAIL PROTECTED]
|Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
|
|
|snip the rant
| Ok I am really tired of everything/everyone DOES
I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention
a little less likely to stumbled upon by unknowing users. I suggest:
jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for
indexed deployments first, and sort the remainder by type. This allows a
This is insanity... how is renumbering your deployment files
simipler/easier/faster/better than opening up a config file and listing the
order there?
How?
--jason
I agree, so let's drop it. I want the simplest numbering available
'UNIX-styleee' and for more advanced (read have time) then
Ok this is more insanity... who was it that thought that renaming files as the
simiplest solution to ordering? Right and I am a goat moo moo.
It works as it is right now... leave it alone. There is no need for prefixed
sorting or this cryptix semi-suffix sorting blah.
If users want this
This is insanity... how is renumbering your deployment files
simipler/easier/faster/better than opening up a config file and listing
the
order there?
There is already a hacked sorting in the URLDeploymentScanner... but it
stops at extension comparison. This proposition extends that just a
But we don't do this... Jetty is part of the release, it is not a seperate
component which users download and configure.
until the next release/important-bug-fix of Jetty.
I thought your whole point was that they DO configure it ?
My point was much larger than Jetty, with respect to
Yes. The current UDS has a hacked sorting blah (which I was not found of, but
is required for the system to work as it stands now). If you want to make the
URLCompa* change to make this optional and pluggable then go for it. I would
leave the default J/E/W/S comparitor in the default config
I think the claims of this being requested by users are suspect. Marc
presented some alternatives in the London training, and this one won a
vote. I don't think that means anyone asked for it or would find it
useful. It means it looked good after Marc's presentation.
Anyway, I think there is
Yes. The current UDS has a hacked sorting blah (which I was not found of,
but
is required for the system to work as it stands now). If you want to make
the
URLCompa* change to make this optional and pluggable then go for it. I
would
leave the default J/E/W/S comparitor in the default
Why?
--jason
Quoting Larry Sanderson [EMAIL PROTECTED]:
Yes. The current UDS has a hacked sorting blah (which I was not found
of,
but
is required for the system to work as it stands now). If you want to
make
the
URLCompa* change to make this optional and pluggable then go for it.
I want a distinction between directories to be scanned, and URLs to be
deployed. This goes back to an earlier patch (that I never checked in) for
URLDeploymentScanner. If you specify a URL that is the base of an exploded
archive, then currently the scanner scans that directory. It should,
So :
persist any SPECIFIC settings made through the JMX agent and overlay
them on top of the DEFAULT settings contained in
.sar/META-INF/jboss-service.xml.
but desist from the 'it's such a pain to unpack/repack' argument,
because, as we have shown, there is no need to repack.
Jules
On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote:
So :
persist any SPECIFIC settings made through the JMX agent and overlay
them on top of the DEFAULT settings contained in
.sar/META-INF/jboss-service.xml.
This might be doable if we are really careful however in the bad old
days of
persist any SPECIFIC settings made through the JMX agent and overlay
them on top of the DEFAULT settings contained in
.sar/META-INF/jboss-service.xml.
The system in 3.0 can not do this. And I am not refering to using the JMX
agent at all.
In my production usage of JBoss, I use ant to
I want a distinction between directories to be scanned, and URLs to be
deployed. This goes back to an earlier patch (that I never checked in) for
URLDeploymentScanner. If you specify a URL that is the base of an exploded
archive, then currently the scanner scans that directory. It should,
Quick thought... if there was a pluggable interceptor in the config service
which would filter values as well as some JMX interceptor that would persist
attribute changes...
Or even a pluggable interceptor around JMX attribute changes (for get config
service, cause it will just invoke the
Lets not force every user down that path... lets make it possible then let the
user choose.
--jason
Quoting David Jencks [EMAIL PROTECTED]:
On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote:
So :
persist any SPECIFIC settings made through the JMX agent and overlay
them on top of
I really hope I'm not throwing more fuel on any fires...
If you have one scanner whose scanned directories can be ordered
individually, you still get to specify the startup order of the directories
by how they are listed in the single scanner.
With more than one scanner, this may be less
The jmx part of this is the persistence service, which is pretty highly
configurable. I think jbossmx has an xml-based persistence service
implementation. I also think it works best with xmbeans or at least
modelmbeans, another reason to migrate soon. So I think the technical
issue of storing
],
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
Date: Sun, 21 Apr 2002 20:35:32 -0400
On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote:
So :
persist any SPECIFIC settings made through the JMX agent and overlay
them on top of the DEFAULT settings contained in
.sar/META
I am not sure what you mean. Can you explain more?
--jason
Quoting David Jencks [EMAIL PROTECTED]:
I really hope I'm not throwing more fuel on any fires...
If you have one scanner whose scanned directories can be ordered
individually, you still get to specify the startup order of the
The solution you presented at the time was to create an alternate
scanner
for this purpose. I don't like that since it violates the concept of
exploded archives being treated just like their packaged counterparts.
What? No it does not at all. It is just the same, it is just a matter of
What is the hell about jboss-auto.jcml? Is it that you never quite know what
config is used? If so, then all of these solutions will result in this hell.
Though some like it hot... and for them we can provid some abstraction to
implement a file based persistence or jdbc or whatever. Then
raw access to the data file should not be allowed.
Regards,
Hiram
From: David Jencks [EMAIL PROTECTED]
To: Jules Gosnell [EMAIL PROTECTED]
CC: Jason Dillon [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
Date: Sun, 21 Apr 2002 20:35:32 -0400
PROTECTED]
Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
Date: Sun, 21 Apr 2002 20:35:32 -0400
On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote:
So :
persist any SPECIFIC settings made through the JMX agent and
overlay
them on top of the DEFAULT settings contained
Multiple scanners make it difficult at best to define deployment ordering.
URLDeploymentScanner is already written (by you, I might add) to handle two
Thanks for reminding me of the obvious...
forms of deployment: Directory scanning and direct URL deployment. I am
trying very hard NOT to
On 2002.04.22 01:06:14 -0400 Jason Dillon wrote:
I am not sure what you mean. Can you explain more?
--jason
scanner1 looks at dir1 with jar1, jar2jar 100 in it
scanner 2 looks at dir2 with jar101...jar200 in it.
I haven't checked recently but I thought scanning happened in its own
]
Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
Date: Sun, 21 Apr 2002 20:35:32 -0400
On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote:
So :
persist any SPECIFIC settings made through the JMX agent and
overlay
them on top of the DEFAULT settings contained in
.sar
Also..
I think we need a way of feeding configuration change scripts into the
server. For example, config snippets showing only the changed values for
the mbeans. Furthermore eventually we should make this transactional...
all changes succeed or you get back to your original state.
david
scanner1 looks at dir1 with jar1, jar2jar 100 in it
scanner 2 looks at dir2 with jar101...jar200 in it.
I haven't checked recently but I thought scanning happened in its own
thread.
Yes each DS which extends from ADS gets its own thread.
scanner1 starts, new thread deploys jar1...
You are trying very hard to implement exploded archives... which I
personally
have little need for.
But this thread was started by you, whose original complaint was that it is
difficult to configure packaged archives. The answer is staring you in the
face and you can't see it... Deploy these
Yes, agreeded, but lets put this off until some of the other problems are
fixed.
There is nothing pressing us for this feature at the moment. Lets hold off
until the deployment and dependency system is fixed.
Either that or find a way to clone yourself.
--jason
Quoting David Jencks [EMAIL
Well, perhaps not completly sucky, but as it is now it does suck. When I wrote that
email long ago about those pesky birds, which eventually lead to .sar (and other
things), I did not have this in mind.
The idea was to make it *easier* to configuration components not complicate it. SAR
as
69 matches
Mail list logo
