<[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, July 30, 2004 11:57 AM
Subject: Re: [5.next] Refactoring save-to-XML
Shapira, Yoav wrote:
>Hi,
>I think a gradual transition might be OK. Server.xml, as Remy said, nicely conveys
&g
Shapira, Yoav wrote:
Hi,
I think a gradual transition might be OK. Server.xml, as Remy said, nicely conveys
the structure of the server's configuration. That's possible to replicate in a JMX-
or JBoss-style configuration file, but it tends to look uglier and more verbose IMHO.
However, your d
---
>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache
>Sent: Friday, July 30, 2004 2:24 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [5.next] Refactoring save-to-XML
>
>Remy Maucherat wrote:
>> Costin Manolache wrote:
>>
>>> The major problem is
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
The major problem is intercepting the changes. It can be done:
- inside the jmx impl ( interceptors, etc )
- using the property changed events
- by wrapping each mbean when it is registered.
One important question is if we need t
Remy Maucherat wrote:
Costin Manolache wrote:
The major problem is intercepting the changes. It can be done:
- inside the jmx impl ( interceptors, etc )
- using the property changed events
- by wrapping each mbean when it is registered.
One important question is if we need to save server.xml, or
ju
Costin Manolache wrote:
The major problem is intercepting the changes. It can be done:
- inside the jmx impl ( interceptors, etc )
- using the property changed events
- by wrapping each mbean when it is registered.
One important question is if we need to save server.xml, or
just say that server.xml
Costin Manolache wrote:
Remy Maucherat wrote:
Hi,
I'd like to make this feature less hardcoded (right now, it's ugly ;)
). A first step would be to extract the code to another helper class,
but that's all I can think of. Does anyone have any ideas ?
What I tried earlier ( but didn't finish ), and
On Thu, 29 Jul 2004 16:55:39 +0200, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> I think it's a start. You identified the downsides well enough, but
> unfortunately, they're a showstopper for me. Additional tweaks are
> needed. I see that others suggested other technologies, but we'd have
> many iss
Remy Maucherat wrote:
Hi,
I'd like to make this feature less hardcoded (right now, it's ugly ;) ).
A first step would be to extract the code to another helper class, but
that's all I can think of. Does anyone have any ideas ?
What I tried earlier ( but didn't finish ), and I still think is a good
Shapira, Yoav wrote:
Hi,
I've done a bit of work in this space. One approach that I've seen work with very complex object graphs is:
- Have an interface, e.g. XMLRepresentationI, with one method,
String toXML();
- Have every object along the graph that needs to be saved implement this interface,
Hi,
I've done a bit of work in this space. One approach that I've seen work with very
complex object graphs is:
- Have an interface, e.g. XMLRepresentationI, with one method,
String toXML();
- Have every object along the graph that needs to be saved implement this interface,
e.g. Context, Host,
XPull?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
hey remy,
have you tried XStream? the API is super simple and it's quite fast.
Not sure if it would work, but we recently changed JMeter to use
XStream instead.
peter
>
> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: 7/29/2004 6:56:40 AM
> To: [EMAIL PROTECTED]
> Subject: [5.ne
This is a computer-generated response confirming that your e-mail
message was received by There. Please do not respond to this message.
Thank you for contacting us. We will make every effort to respond to
your message as soon as possible.
Please do not send multiple e-mail messages (regarding the
14 matches
Mail list logo
