Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: depends optional-attribute-name - depends name
Date: Thu, 9 May 2002 08:34:34 -0700
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Can we please change optional-attribute-name
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: ShutdownHook MainDeployer.shutdown()
Date: Fri, 10 May 2002 09:54:21 -0700
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Can someone please explain to me why ServerImpl was changed
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: transaction module ClientUserTransaction
Date: Fri, 10 May 2002 11:58:25 -0700
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Who knows about ClientUserTransaction?
This class
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: org.jboss.ejb.plugins.TimedInstancePoolFeeder
Date: Fri, 10 May 2002 08:26:11 -0700
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Why is JBoss3 setup by default to use this feeder
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: Re: [JBoss-dev] JMX RMI Adapter JNDI binding
Date: Mon, 13 May 2002 19:59:24 +
From: Jason Dillon [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: EnityInstancePool not started or stopped
Date: Mon, 13 May 2002 21:26:44 +
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I am trying to track down a problem
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: TODO/FIXME/Not implemented yet methods in EJB conatiner classes
Date: Tue, 14 May 2002 05:59:06 +
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
What is the deal
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: TimedInstancePoolFeeder problem fixed
Date: Tue, 14 May 2002 07:51:32 +
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
It looks like the state of the entity container
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: Re: [JBoss-dev] HEAD ClassCircularityError
Date: Wed, 15 May 2002 00:16:57 +
From: Jason Dillon [EMAIL PROTECTED]
To: Sacha Labourey [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: Re: [JBoss-dev] HEAD ClassCircularityError
Date: Wed, 15 May 2002 00:24:22 +
From: Jason Dillon [EMAIL PROTECTED]
To: Sacha Labourey [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED
I found out today that my local sendmail config was messed up and was silently
failing to deliver mail. I have resolved the problem (I think) and resent
the relevent bits of mail that I wrote in the last few days.
--jason
___
Have
-0400 Jason Dillon wrote:
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: ShutdownHook MainDeployer.shutdown()
Date: Fri, 10 May 2002 09:54:21 -0700
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Can someone please
The JMX Connectors are not written for JBoss specific. Because JMX allows
you
to have more than one MBeanServer per JVM and there is a good chance that
a box have more than one JVM running this is not so far fetched. Especially
when
an external JNDI server is used.
Ok, that is fine, but
persistence to save
state
across server shutdown and restart.
david jencks
On 2002.05.14 22:39:31 -0400 Jason Dillon wrote:
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: ShutdownHook MainDeployer.shutdown
I wrote Bill an example of why it is important to handle exceptions properly
which I think is useful to the group at large, so I am copying it here too
(hope that is ok Bill)
snip
only find explicit handling useful when I need to do an action differently
for each exception type.
i.e.
Can someone point me to the spec where it states where in JNDI the JMX RMI
adapter should be bound to.
Currently we are binding to jmx:hostname:rmi which is fine when you are
working with the localhost, but will start to cause problems once used in a
multi-host environment.
For example,
,
Sacha
-Message d'origine-
De : Andreas Schaefer [mailto:[EMAIL PROTECTED]]
Envoyé : dimanche, 12 mai 2002 03:11
À : Sacha Labourey; Jason Dillon
Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Objet : Re: [JBoss-dev] HEAD
Can anyone on linux run the testsuite for cvs-rc3? I have tried several times
and it crashes the vm each time under 1.4 (have not yet tried 1.3.1). Seems to
happen alot in the jbossmq or jca tests, but I have no idea if that test is
tickling the vm or what.
My vm seems to be idling around 80
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 10, 2002 12:22 AM
Subject: [JBoss-dev] testsuite crashes vm on linux for cvs-rc3
Can anyone on linux run the testsuite for cvs-rc3? I have tried
several
times
Total time: 5 minutes 5 seconds
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 10, 2002 12:22 AM
Subject: [JBoss-dev
to see what
happen?
Cheers,
Sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Jason Dillon
Envoyé : jeudi, 9 mai 2002 10:29
À : [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc : [EMAIL PROTECTED]
Objet : [JBoss-dev
-
From: Jason Dillon [EMAIL PROTECTED]
To: Sacha Labourey [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, May 09, 2002 10:52 PM
Subject: RE: [JBoss-dev] HEAD ClassCircularityError
I have not yet tried removing deployments... but I just
This is not entierly true...
We provide a log4j.properties in run.jar which allows any component to use the
Log4j classes with out having to explictly configure the system.
This allows all components to use log4j with minimal effort and makes it simple
to change the configuration. There is
It is small... I don't have the exact numbers in front of me right now
(reinstalling laptop again... screw windows), but its small. It might not be
tiny in the o2-less sense which you speak of, but I think that it is better to
have a real logging system over System.out even if it means that it
It should be possible to define any sort of grammer with JavaCC.
Perhaps the root production does not have the proper terminators to
single the end of a selector?
--jason
Hiram Chirino wrote:
To all JavaCC Gurus,
The javacc grammar that JBossMQ is using has a problem. It can't
detect
Hopefully this won't happen soon... or we are gonna be in trouble...
--jason
marc fleury wrote:
|Have big pipes? SourceForge.net is looking for download mirrors. We supply
|the hardware. You get the recognition. Email Us:
|[EMAIL PROTECTED]
this is not looking good, we will stay as long as
Lets change the default port we use... or is there a reason we can't?
--jason
Francisco Reverbel wrote:
See this thread:
http://www.jboss.org/forums/thread.jsp?forum=66thread=13521
Either disable the SSDP Discovery Service on Windows XP or change
the IIOP port (OAPort) in
Why not change it to 8683 by default then?
--jason
Francisco Reverbel wrote:
As Adrian pointed out some time ago, the IIOP port in the
default config in HEAD and branch 3.0 (port 5000) conflicts
with a Windows XP service (SSDP Discovery Service, used for
Universal Plug and Play).
I
can modify the code).
|
|cheers
|
|
|
|Jason Dillon wrote:
| Hello, I have been looking into problems with trying to enable
|proper support
| for caching jsp pages running inside of Jetty... and I think I
|have found the
| problem... Jasper.
|
| The Jasper JSP servlet overrides service
Quoting David Jencks [EMAIL PROTECTED]:
It's a milestone, but ...
1. There are more bugs
2. this is only one jvm.
3. I think the testsuite should run twice with no errors (see bug 549775)
We should make sure that the state of the container is the same before and
after a test runs... I
WHAT!!!?? This is not cool... I am still early into reading 300+ messages for
today... one of which I think you posted saying things are cool... BUT
It is not cool to not update your workspace before committing. Marc has done
this before and it just ends up in lost work... some of my work...
merged then committed. Everything is fine.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
Dillon
Sent: Monday, April 29, 2002 3:28 AM
To: Bill Burke
Cc: Jboss-Dev
Subject: Re: [JBoss-dev] CVS HEAD in danger
WHAT
2:59 PM
|To: Jason Dillon
|Cc: Jboss-Dev
|Subject: RE: [JBoss-dev] CVS HEAD in danger
|
|
|Dude, I was in a bad mood this morning. Sorry for being harsh.
|
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
| Dillon
| Sent: Monday, April 29, 2002
I just double checked my app and I am closing senders, sessions and connections where
appropriate... and yet I am still getting XAExceptions like this:
WARN TxCapsule [SocketListener-1] (MailingManager) XAException: tx=XidImpl
[FormatId=257, GlobalId=eng-ecr3a//21, BranchQual=]
19:58:53,880 INFO [STDOUT] * putting invoker entity-rmi-invoker into
ApplicationMetaData
19:58:55,543 INFO [STDOUT] _ creating binding for
ejb/jmx/ejb/Adaptor:stateless-rmi-invoker
19:58:55,763 INFO [STDOUT] ---Binding Home ejb/jmx/ejb/Adaptor
Please use logging.
--jason
*
Hello, I have been looking into problems with trying to enable proper support
for caching jsp pages running inside of Jetty... and I think I have found the
problem... Jasper.
The Jasper JSP servlet overrides service(HttpServletRequest,
HttpServletResponse) (with a final version no less), that
I think this is a very bad idea...
Yet if it comes down to this then we will need to implement some xslt stuff
into the build system so that each module can contain the snippets of xml that
get merged into the huge monolithic config file otherwise managing the
configuration when running a
The fact is that for *production* the one file is good.
This is your assumption... not always the case... actuall should not matter
too much if the folks running thr show know what they are doing. Further more
the many file config now can be turned into a single file config if desired.
I
Perhaps we should not include this file... I will consider this when I
get to the next round of build system fixes/mods/changes.
--jason
Gerald Hewes wrote:
When I followed the build instruction in the guide,
my build command was failing with:
build/build.sh
Searching for build.xml ...
Ok... I think I could be loosing my mind. All uf a sudden this works now, with out
this hack. But now I get exceptions like this when using error pages:
01:12:58,093 WARN [Jetty] WARNING: GET /default.jsp HTTP/1.1
java.lang.NullPointerException
at
Really... that is odd. Are you testing on your latest CVS?
I have been using the version in JBoss CVS HEAD using the SiteMesh filter
(http://www.opensymphony.com/sitemesh/) and I could only get it to apply the
decorator to http://localhost:8080/index.jsp it would show the raw content
page
I show that your email address for this user is [EMAIL PROTECTED], is this
still correct?
It would be best to let the automatic reset fluff be used to change your
password... but I can set it if that does not work.
Let me know about your email address.
--jason
Luke Taylor wrote:
Hi all,
Hey, I am not sure if this is a real problem or if I just have my webapp
misconfigured... but it looks like there is a problem outside of my config.
I have been trying to setup a test environemnt for SiteMesh. SiteMesh uses servlet
filters to apply the decorator pattern to jsp pages... which
Great! So we can build web pages with xslt to make this readable. Do you
know what the timeline is for the next Ant release?
--jason
Quoting Dave [EMAIL PROTECTED]:
Also, in Ant 1.5 there is a new cvstagdiff / task that spits out a xml
formatted report.
It would appear this also happens with directories under /, like
http://localhost:8080:/test where http://localhost:8080:/test/index.jsp works fine.
=(
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13857
___
I just tried deploying under /foo and got the same results.
=(
I have alos cross posted the main thread to jetty-discuss.
--jason
-
This mail sent through IMP: http://horde.org/imp/
___
Shit so does XmlProperty.. but still no app level xml include? Or is it that I just
can not find it?
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13850
___
Jboss-development mailing list
[EMAIL PROTECTED]
CvsChangeLog also looks promising.
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13850
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
A release candidate has been release (april 16th), so it is getting ready to go final.
Anyone apposed to integrating for 3.1 (assuming there are no showstoppers).
If not anyone want to put in the work to migrate? Should be fairly simple...
--jason
* * *
View thread online:
regards
Mikael
-Oprindelig meddelelse-
Fra: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sendt: 24. april 2002 09:05
Til: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Emne: Re: SV: [JBoss-dev] Re: Jetty, Servlet Filters
url-pattern=/*
I just tried deploying under /foo and got
one. For now, the ugly method is the most portable:-
!DOCTYPE project [
!ENTITY IncludeBuildCore SYSTEM buildCore.xml
!ENTITY IncludeBuildSecondary SYSTEM buildSecondary.xml
]
target name=includedBuild
IncludeBuildCore;
Yes, I have been waiting for this... and there seems to be no end in sight at
the moment. Perhaps next year they... *sigh*
--jason
Quoting Dave [EMAIL PROTECTED]:
Also, app level xml includes will be in ant 2.0.
* * *
View thread online:
PROTECTED]:
On 24 Apr, Hiram Chirino wrote:
From: Peter Antman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Date: Wed, 24 Apr 2002 10:35:29 +0200 (CEST)
On 23 Apr, Jason Dillon wrote:
Hey, I have just started
I have not yet tested my systems with 3.0 yet... as the config change is a bit
too much for me to manage on top of the billion other things I have todo.
Though I may beforced to write a testsuite which reproduces my problem and
then test it under 3.0... though I would like to avoid that, even
Tyrex works in 3.0 (at least it did about 2 months ago when I patched it
up). I would not recommend Tyrex for work in distributed transactions,
because it would be very slow. It should work fine as a local TM as well
but, probably, it is slower than JBossTX. To get it to work you would have
Thanks... I got a warning of mail delayed earlier... perhaps it will
eventually bounce.
--jason
Brett Sealey wrote:
On Wed, 24 Apr 2002, Jason Dillon wrote:
I have alos cross posted the main thread to jetty-discuss.
It doesn't seem that way - I'll bounce a copy over there now.
Brett
It doesn't pretend to do logging, which is what you need for failure
recovery and reliable 2pc. Do you have any evidence that anything else is
ever causing problems in it? Much to my surprise, all the bugs I've
thought were definitely in the tx manager turned out to be in my code;-)
(OK,
For reference, since the forums can't handle some of these subject prefixes:
http://jboss.org/forums/thread.jsp?forum=66thread=13858
http://jboss.org/forums/thread.jsp?forum=66thread=13862
http://jboss.org/forums/thread.jsp?forum=66thread=13857
* * *
This has now made it to jetty-discuse...
The modify the build system to release them under build/output/jboss-*/etc/dtd
or something.
--jason
Quoting Dain Sundstrom [EMAIL PROTECTED]:
Yes I know they are in the jar. I mean we should include a copy in
loose form. It is very useful for developers to be able to easily see
the
Do you agree that this is a good idea, or are you just suggesting a
course of action for me?
Both. I would do but don't have time.
Does anyone dislike the idea of putting them in jboss-whatever/etc/dtd,
or is some other location better? (I really don't have an opinion)
either etc/dtd
Yes, I have sent mail about this before. Does it barf or just complain?
Do you see the final start message?
Fransico, put in a dummy jacob.properties in default/conf when IIOP
builds to avoid this mess please.
--jason
marc fleury wrote:
he...
did rm on the old stuff
then a CLEAN CO
then
Hey, I have just started integrating SwiftMQ for use in my production
environment at work and by doing so I have notice d that we might have
some issues with the JMS RA.
Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums
with a document he wrote about getting it to work:
Looking over the last bit of this doc about Xids and JBossTX...
JBossTX starts the global ID numbering from 1 each time it runs, so the global IDs
are not very unique. Needless to say, this could stand some improvement.
Why don't we use a org.jboss.util.id.UID or org.jboss.util.GUID here for
Someone (I think it might have been David) mentioned something about diffing the HEAD
and 3.0 branches.
Does anyone know if there is a good way todo this?
I am a little concerned that some fixes are going into HEAD and are not making it into
the 3.0 branch. If there is a nice tool that
Can someone look into why this started happening again. And if it is a
problem on the server side can we fix it so that it accuratly reports
when the server does not shutdown.
Please.
--jason
[EMAIL PROTECTED] wrote:
=
PS: instructions
remove your current codebase
cvs co jboss-all
I think this is extreme, but certainly won't hurt
build/sh build.sh
If you choose not to re-checkout then:
build/build.sh clean most
=)
--jason
___
Jboss-development mailing
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
Once again I tried to start working on the new website... but I have run into another
problem. Looks like we are trying to deploy some files under doco_files/ which are
failing. Which is good to know, since those doco files need to be updated or removed,
but why is MD trying to deploy them
3.0rc1 has the same issue... =[
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13628
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
]:
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
What? Because marc doesn't like system props (even if that is true) that
means that we get rid of them inside of the server? Whatever...
The new ServerLoader ServerConfig components make use of system properties
to control config. We should not try to get rid of this, as it is a simple
Whatever... I cleaned up the *muddled* property usage when I rewrote that
section of the system. It is not much more consistent and provides a better
method to expose and propagte that config.
Why do you continue to bad mouth code I have written when you have not even
looked at it?
Really?
The website is now updated with the links to SF... looks like they all
work too. Let me know if this is not the case.
--jason
Jason Dillon wrote:
are now up on SF.NET... I will change the links on the website to
direct users to the new download location.
I zipped these files
Does anyone know if the 'zoap' and 'zola' modules are still in use anywhere?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
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
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
Looks like my problems with SiteMesh are that some of the SiteMesh
servlets/tags/whatever need to call getOutputStream() and the Jasper JSP engine needs
to call getWriter() within the same dispatched request/response.
This can be fixed by changing JspWriterImpl.initOut() as so:
[code]
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
Is there a way to access properties from the tomcat config? If so it should
set the log dir in ${jboss.server.home.dir}/log
--jason
Quoting David Ward [EMAIL PROTECTED]:
I don't know the ins-and-outs of creating a change request, but was
wondering if for the next rc of jboss3-tomcat4 the
Can you do me a favoir and explain this in more detail... and example too. It
would save me the time to hunt down the relevent specs just to understand the
concept.
--jason
Quoting Matt Humphrey [EMAIL PROTECTED]:
You can do this with namespaces. The stuff outside the tag is scoped
with
Ok thanks... but why does this failure mess up the boot up sequence?
Can we change the port so that XP users don't have this problem?
--jason
Quoting Adrian Brock [EMAIL PROTECTED]:
Hi Jason,
There is a service on Windows XP that sits on port
5000 (same one used by iiop).
It is called
I am thinking that it should. Perhaps some of the other stuff under server
(org.jboss.jmx) too? Some stuff will have to stay (like the EJB adapter), but I think
that we should move what we can.
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13586
I thought we discussed this before, where it was agreed that the simple
solution was to have users explicitly list the users in the order they wanted
rather than implement another sorting system in UDS.
We already sort using DeploymentSorter (J/E/W/S as you called it), addinf this
prefix
I really don't like that we have to put stuff into run.jar to solve
IIOP/JacORB specific problems. Can we get around this? Or is this just to
make it work in IBM?
--jason
Quoting Francisco Reverbel [EMAIL PROTECTED]:
Sorry for the trouble. Port 5000 was just a random (and poor) choice I
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
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
A jacorb.properties in run.jar would just avoid this warning:
WARNING: no properties file found! This warning can be ignored for applets.
A file file called jacorb.properties or .jacorb_properties should be
present
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.
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,
as
you had before you shut down. But if _you_ change a config file, should
you have to undeploy and redeploy it to get the changes to stick? I don't
know.
Thanks
david jencks
On 2002.04.21 19:00:31 -0400 Jason Dillon wrote:
don't be an ignorant bastard on your own idea and its actual
to repack.
Jules
Jason Dillon wrote:
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
of the directories
by how they are listed in the single scanner.
With more than one scanner, this may be less deterministic, considering
each scanner runs in a separate thread (is this true?). Maybe there's a way
out, I haven't thought of it.
david jencks
On 2002.04.21 21:09:09 -0400 Jason
issue of storing the mbean attribute values is done, more or less, rather
elegantly. I just don't want to get back to the jboss-auto.jcml hell, and
am wondering how to think about the problem.
david jencks
On 2002.04.21 21:17:32 -0400 Jason Dillon wrote:
Quick thought
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
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
401 - 500 of 3862 matches
Mail list logo
