il 21, 2002 3:10 PM
> |To: [EMAIL PROTECTED]
> |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> |
> |
> |I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention
> |a little less likely to stumbled upon by unknowing users. I suggest:
>
I am checking out of this bullshit,
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
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 ca
On 2002.04.22 11:26:06 -0400 Larry Sanderson wrote:
> > Anyway, I think there is a real bug nearby that we
> > need to fix. See
> >
> > http://jboss.org/forums/thread.jsp?forum=46&thread=1346&start=0&msRange=15
> >
> > If a jar file references a nonexistent jar file in
> > the manifest classpat
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 correc
> Anyway, I think there is a real bug nearby that we
> need to fix. See
>
> http://jboss.org/forums/thread.jsp?forum=46&thread=1346&start=0&msRange=15
>
> If a jar file references a nonexistent jar file in
> the manifest classpath
> entry, something (the scanner???) goes haywire and
> keeps try
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
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.wa
> > 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 wi
> 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
>
> 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 sort
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
> 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 thes
> 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 j
Also..
I think we need a way of feeding configuration change scripts into the
server. For example, config snippets showing only the changed values for
the mbeans. Furthermore eventually we should make this transactional...
all changes succeed or you get back to your original state.
david jencks
On 2002.04.22 01: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
> 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 t
What is the hell about jboss-auto.jcml? Is it that you never quite know what
config is used? If so, then all of these solutions will result in this hell.
Though some like it hot... and for them we can provid some abstraction to
implement a file based persistence or jdbc or whatever. Then the
> > 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 ma
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 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 t
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 determi
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 serv
> 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 shoul
Jason, thanks for trying to get this discussion back to something useful.
There's another thing I've mentioned a couple of times that I think is
relevant.
What's the relationship between the initial config supplied by
*-service.xml files and the possibly modified config in the mbean server?
If
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,
inste
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
> 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 co
I think the claims of this being requested by users are suspect. Marc
presented some alternatives in the London training, and this one won a
vote. I don't think that means anyone asked for it or would find it
useful. It means it looked good after Marc's presentation.
Anyway, I think there is a
I agree, lets get a real use case then see what the simplest solution is. In
the mean time I don't see any reason not to make this pluggable, so that users
can come up with any arbitrary complexity for deployment scanning which they
have a jones for as long as we leave the default config s
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
1. I think marc wanted the numbers at the beginning
1myjar.jar
2mysar.sar
3myear.jar
etc.
2. I don't think mixing ordering schemes within 1 directory has any chance
of working.
3. I'd like to have an actual user ask for this over explicitly listing the
files in the deployment scanner.
david jen
> don't be an ignorant bastard on your own idea and its actual
> implementation.
Whatever dude... I am enlightened to users needs, to the needs of IT
professionsals who need ease of configuration managment... I am enlightened to
the possibilities of creating a super system around JBoss which wi
> 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
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 ma
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) the
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
simp
> Just pisses me off
>
> marcf
>
> |-Original Message-
> |From: David Jencks [mailto:[EMAIL PROTECTED]]
> |Sent: Sunday, April 21, 2002 9:45 AM
> |To: marc fleury
> |Cc: [EMAIL PROTECTED]
> |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> |
&g
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
> 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: UR
|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
deploy
On 2002.04.21 15:46:46 -0400 marc fleury wrote:
> | | name="jboss.deployment:type=DeploymentScanner,flavor=URL">
> |
> |
> | |optional-attribute-name="Deployer">jboss.system:service=MainDeploye
> |r
> |
> |5000
> |
> |
> |
> | ./deploy/jar1.jar,
> | ./deploy/
|
|
|
|jboss.system:service=MainDeploye
|r
|
|5000
|
|
|
| ./deploy/jar1.jar,
| ./deploy/sar2.sar,
| ./deploy/war3.war,
| ./deploy/jar4.jar,
| ./deploy
|
|
|
|Which is easier, setting it one place here or changing n names in your m
|ant bui
> 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
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 c
On 2002.04.21 14:02:40 -0400 marc fleury wrote:
>
> |just "I haven't taken the time to find out how the deployment works or
> test
>
> I wrote the fucking deployment.
Along with me, Jason, and Larry Sanderson, to name a few.
>
> |it, and my pet idea isn't implemented, so I'm going to bitch"
>
|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 deci
ROTECTED]]
> |Sent: Sunday, April 21, 2002 9:45 AM
> |To: marc fleury
> |Cc: [EMAIL PROTECTED]
> |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
> |
> |
> |
> |> Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING
> OF
> |> DEPLOYMENTS
fleury
|Cc: [EMAIL PROTECTED]
|Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
|
|
|
|> Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING OF
|> DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER.
|>
|> If I do 01first.sar and 02second.war do I get 01 first a
> Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING OF
> DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER.
>
> If I do 01first.sar and 02second.war do I get 01 first and 02 second?
>
> YES=NO
>
> ?
umm YES != No
the answer is NO
If you want deployments in a specific order li
50 matches
Mail list logo
