Bill Barker wrote:
It certainly made Gump unhappy :).
Ooops, yes, it's going to be a problem. It's quite hard to build my
custom JAR :(
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL P
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, August 11, 2004 11:04 AM
Subject: Re: [5.next] Progress, more ideas and native connector benchmarks
Some updates ...
Rem
Some updates ...
Remy Maucherat wrote:
* Default global and per-host configurations:
- conf///context.xml.default
- conf///web.xml.default
- conf/context.xml
- conf/web.xml
This will lead to the removal of the DefaultContext interface, since
this will fully replace the functionality (while being v
Shapira, Yoav wrote:
Hi,
You know, I've been meaning to address the "Undeploy considered dangerous" bugzilla item by adding a JavaScript confirmation dialog around the undeploy action in the HTML manager. Too bad I hadn't gotten around to it before your mishap ;(
I would have clicked "yes": I w
Research Informatics
>-Original Message-
>From: Remy Maucherat [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, July 28, 2004 6:27 AM
>To: Tomcat Developers List
>Subject: Re: [5.next] Progress, more ideas and native connector benchmarks
>
>Remy Maucherat wrote:
>
>&g
Remy Maucherat wrote:
Bill Barker wrote:
- Remove Deployer and DefaultContext. The new stuff looks like a better
replacement.
I did that but didn't commit yet. The management side for the default
context would need to be redone (it's not very difficult, I think).
The clustering will need updates,
Bill Barker wrote:
I'll volunteer for the admin webapp stuff. I enjoy deleting stuff from
there ;-).
It's at the end of my list right now, so I wont't get there for a while.
I committed a few things:
- The new deployer is getting there. Missing is the support for the
manager webapp, but this wo
I'll volunteer for the admin webapp stuff. I enjoy deleting stuff from
there ;-).
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, July 26, 2004 9:27 AM
Subject: Re: [5.
I committed a few things:
- The new deployer is getting there. Missing is the support for the
manager webapp, but this won't be too hard to write.
- I redid partially the naming. Now the NamingResource object is the
main object, and Context is not polluted.
My list is:
- Update manager webapp, a
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation,
but with finer control over what is exported/imported and pretty
strong versioning. In addition osgi
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation,
but with finer control over what is exported/imported and pretty
strong versioning. In addition osgi supports permissions o
Remy Maucherat wrote:
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation,
but with finer control over what is exported/imported and pretty
strong versioning. In addition osgi supports permissions on importing
packages.
T
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation,
but with finer control over what is exported/imported and pretty
strong versioning. In addition osgi supports permissions on importing
packages.
The reloading of module
Costin Manolache wrote:
Don't know what "dependency injection" is, but I hope the next spec
won't invent yet another way to do configuration.
Sorry for using hype words. I got contaminated, it can happen to
anyone. I'll try to shake it off now. I apologise to the community
for that, and I won't
Shapira, Yoav wrote:
* Default global and per-host configurations:
- conf///context.xml.default
- conf///web.xml.default
- conf/context.xml
- conf/web.xml
This will lead to the removal of the DefaultContext interface, since
this will fully replace the functionality (while being very simple to
imple
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Quick question - did you had any discussion on class loaders for
5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
I'll tweak the StandardCL to do a bit th
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Quick question - did you had any discussion on class loaders for
5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
I'll tweak the StandardCL to do a bit the same as the WebappCL
THIS IS AN AUTOMATED RESPONSE FROM CDZONE
Thank you for contacting us.
If your enquiry is covered by the list below please visit
our web site at http://www.cdzone.co.uk/accounts where you can:
* Check your order status - we are unable to provide any more
detailed information about delivery
Remy Maucherat wrote:
Costin Manolache wrote:
Quick question - did you had any discussion on class loaders for 5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
I'll tweak the StandardCL to do a bit the same as the WebappCL (ie, try
to make it fas
Costin Manolache wrote:
Quick question - did you had any discussion on class loaders for 5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
I'll tweak the StandardCL to do a bit the same as the WebappCL (ie, try
to make it faster). I'll also remove
Shapira, Yoav wrote:
Hola,
* Redo naming resources configuration using setAllProperties rule to
make the XML less verbose.
Example:
type="com.mycompany.MyBean"
factory="org.apache.naming.factory.BeanFactory"
bar="23"/>
I personally really like this (and use setAllProper
Quick question - did you had any discussion on class loaders for 5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
BTW - another feature idea would be to extend the JMX configuration into
the webapps, i.e. allow jmx apps to view and configure cont
Hola,
>* Redo naming resources configuration using setAllProperties rule to
>make the XML less verbose.
>Example:
> type="com.mycompany.MyBean"
>factory="org.apache.naming.factory.BeanFactory"
>bar="23"/>
I personally really like this (and use setAllProperties extensivel
I've had a few more feature ideas (actually, it's more tweaks and simple
things than big development for the most part), and I'm refining the way
I'll be implementing the new deployer.
* Parse element Context (if context config file) in HostConfig, for
className, path and docBase attributes.
*
t: Saturday, July 17, 2004 1:05 PM
To: Tomcat Developers List
Subject: Re: [5.next] Progress
Filip Hanik (lists) wrote:
> hi Remy,
> Time will open up in a week or so. And yes, I am wide open to any ideas.
> My personal feeling about the farm deployer, is that it would work exactly
>
Filip Hanik (lists) wrote:
hi Remy,
Time will open up in a week or so. And yes, I am wide open to any ideas.
My personal feeling about the farm deployer, is that it would work exactly
like auto deployment to Tomcat, and maybe just an entry in web.xml makes it
send to other servers.
Yes for the firs
fragments of data sent across the
wire, so that we don't take up too much RAM.
Let me put together a todo list for review next week!
Filip
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 12:11 PM
To: Tomcat Developers List
Subject: Re: [5
On Thu, 15 Jul 2004, Remy Maucherat wrote:
| Jess Holle wrote:
| > Just a note:
| >
| > Please allow the anti-locking stuff to be skipped on Windows as well.
| > [Some of us value performance over deployment convenience.]
|
| Yes, of course. In production, many people don't use hot deployment (it
Remy Maucherat wrote:
Jess Holle wrote:
Just a note:
Please allow the anti-locking stuff to be skipped on Windows as
well. [Some of us value performance over deployment convenience.]
Yes, of course. In production, many people don't use hot deployment
(it doesn't give good enough QoS right now,
Jess Holle wrote:
Just a note:
Please allow the anti-locking stuff to be skipped on Windows as well.
[Some of us value performance over deployment convenience.]
Yes, of course. In production, many people don't use hot deployment (it
doesn't give good enough QoS right now, IMO).
- Possibly requi
Remy Maucherat wrote:
My updated TODO. So I'll do the deployer next, followed by trying to
optimize startup time.
Then, there's tweaking.
Filip, do you have time to refactor the clustering soon ? I think we
should tweak your farming feature as well, as it should likely be done
the way the manag
My updated TODO. So I'll do the deployer next, followed by trying to
optimize startup time.
Then, there's tweaking.
Filip, do you have time to refactor the clustering soon ? I think we
should tweak your farming feature as well, as it should likely be done
the way the manager servlet is (rather,
Hello Jess,
I have made a test with MX4J 2.0.1 and JSR 160 Connector.
See my patches
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259
Testet with MC4J Console and works very well.
regards
Peter
Jess Holle schrieb:
Remy Maucherat wrote:
Jess Holle wrote:
In my case even with 1.5 I need a plug
Remy Maucherat wrote:
Jess Holle wrote:
In my case even with 1.5 I need a pluggable (2) from above. Why?
Because I need to work with port ranges and grab the first free port
(with MBeans then proxied to a daemon with a consistent port #). 1.5
has no automatic machinery for this as best I can
Jess Holle wrote:
In my case even with 1.5 I need a pluggable (2) from above. Why?
Because I need to work with port ranges and grab the first free port
(with MBeans then proxied to a daemon with a consistent port #). 1.5
has no automatic machinery for this as best I can tell.
It's true that
Remy Maucherat wrote:
Jess Holle wrote:
I'll play with this as I have time, but I'll be doing the same sort
of thing with our own app first.
As I see it (and I could be offbase, of course, as I've not had time
to code this), one just needs a pluggable SPI sort of interface
responsible for:
1
Jess Holle wrote:
Though I also really like Java 5's [yep, another neat numbering change
from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see
a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5).
Is this the plan/hope? At a high level it does not look to
Jess Holle wrote:
I'll play with this as I have time, but I'll be doing the same sort of
thing with our own app first.
As I see it (and I could be offbase, of course, as I've not had time to
code this), one just needs a pluggable SPI sort of interface responsible
for:
1. A singleton get-or-c
Remy Maucherat wrote:
Jess Holle wrote:
Though I also really like Java 5's [yep, another neat numbering
change from Sun :-)] built-MBeans for JVM monitoring, I'd *really*
like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and
Java 1.5 (aka 5).
Is this the plan/hope? At a high le
- Possibly require JDK 1.5 (cleaner code, annotations, integrated
JMX and JMX
remote, etc)
I have made prototype for mx4J JSR 160 support it looks very nice.
Can't we refactor the ServerLifecycleListener also?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259
No, that listener needs to go I
Remy Maucherat wrote, On 7/2/2004 2:13 AM:
Jeanfrancois Arcand wrote:
Remy Maucherat wrote:
Speaking of which, does anyone know any OSes (besides Windows) which
lock files ?
NFS sometimes lock file (I did see a similar problem with Solaris)
Thanks for the tip. I'll code in Windows by default, and
Jeanfrancois Arcand wrote:
Remy Maucherat wrote:
Remy Maucherat wrote:
My upcoming change list:
- Attempt to redo a bit the deployer:
* remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes); when enabling
anti locking
code, move ev
Remy Maucherat wrote:
Remy Maucherat wrote:
My upcoming change list:
- Attempt to redo a bit the deployer:
* remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes); when enabling
anti locking
code, move everything to a temp "deploy
Remy Maucherat wrote:
My upcoming change list:
- Attempt to redo a bit the deployer:
* remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes); when enabling anti
locking
code, move everything to a temp "deploy" folder where everythi
Peter Rossbach wrote:
Hey Remy,
OK, I am do my best that the save factory implementation work at weekend.
A good patch is better than a rushed patch ;)
I'm so tired of Windows right now ...
But few of the developers wan't work at linux :-\ ...
Yes, but the fact that M$ failed to address core issu
Hey Remy,
OK, I am do my best that the save factory implementation work at weekend.
s. comments...
Regards
Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
Hello,
I have start a Server saved implementation.
- Externalize configuration saving out of StandardServer
features:
* splitt implementat
quot;Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, June 30, 2004 8:47 AM
Subject: Re: [5.next] Progress
> Peter Rossbach wrote:
>
> > Hello,
> >
> > I have start a Server saved implementation.
> >
> > - Externalize configuration saving out
Peter Rossbach wrote:
Hello,
I have start a Server saved implementation.
- Externalize configuration saving out of StandardServer
features:
* splitt implementation from StandardServer class
* refactor the current save methods to some helper classes
* every save element from server.xml dialect
Hello,
I have start a Server saved implementation.
- Externalize configuration saving out of StandardServer
features:
* splitt implementation from StandardServer class
* refactor the current save methods to some helper classes
* every save element from server.xml dialect has it own save facto
My upcoming change list:
- Attempt to redo a bit the deployer:
* remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes); when enabling anti
locking
code, move everything to a temp "deploy" folder where everything will be
referenced
50 matches
Mail list logo
