You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by ag...@globo.com on 2005/02/04 20:15:41 UTC
[i18n] status
Daniel and Oliver, please, this project will continue?
I sent a class diagram with changes (proposal changes) but I no receive
any response from both.
I know you are working on other projects (transaction, slide, etc ) but,
please, aswer me. I really wanna participate ...
Thanx again
Woody
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [i18n] proposals
Posted by Daniel Florey <da...@web.de>.
Hi Woody,
you pass over your code to me directly using my apache email address.
See comments inline...
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-67427-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-67427-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Anaximandro (Woody)
> Gesendet: Montag, 7. Februar 2005 06:12
> An: Jakarta Commons Developers List
> Betreff: Re: [i18n] proposals
>
> Hi Daniel,
>
> The ConfigManager in my idea is used for store specific configurations, as
> I
> see the MessageManager don't have this responsabilitie. If I store any
> configuration on MessageManager I will need specific instances of this guy
> for each thread with a diferent configuration.
>
> Well, in your code you don't let the user of this component to configure
> the
> behaviours of log, exceptions and default language. I do some code to do
> this in mine and, becouse this, I need to store these configurations on a
> "isolated" place. Store these guys inside MessageManager is not a good
> idea.
>
> The MessageManager only store the message providers and delegate calls to
> these providers.
>
> The main objective behind this is to write less code in cases wich I need
> to
> specify Locales differents than default Locale. Instead of write:
>
> Locale userLocale = getUserLocale( userId );
> LocalizedText txt1 = new LocalizedText( consts.ID1, userLocale ); //
> each
> message need to set the user locale
> LocalizedText txt2 = new LocalizedText( consts.ID2, userLocale ); //
> LocalizedText txtN = new LocalizedText( consts.IDN, userLocale ); //
The locale is not specified in the constructor. It is specified when you
retrieve a particular entry:
LocalizedText txt1 = new LocalizedText( consts.ID1 );
String translatedText = txt1.getText(Locale.DE);
The default locale should only be used when no user locale can be detected.
It might be a good idea to remove the methods dealing with the default
locale in order to avoid confusion.
>
> I think in write:
>
> String servletID = getServletUUID();
>
> ConfigManager config = new ConfigManager.getInstance( servletID );
> config.setLocale( getUserLocale( userId ) );
> // Only one place set the user locale
>
> LocalizedText txt1 = new LocalizedText( consts.ID1 );
> LocalizedText txt2 = new LocalizedText( consts.ID2 );
> LocalizedText txtN = new LocalizedText( consts.IDN );
>
> I agree with your idea, keep it simple here is the best thing to do, but
> how
> to setup aditional information without a mediator to store?
> The code in first example can be a problem, he multiply locale information
> (configuration) in many places where I have a message ...
>
> In my code I write:
>
> - In LocalizedText, LocalizedMessage, LocalizedError, LocalizedException I
> change the extensions. Instead of cascating extensios I do direct
> extensions
> (LocalizedText extends LocalizedBundle, LocalizedMessage extends
> LocalizedBundle, LocalizedError extends LocalizedBundle ...)
Why? Each extension adds some additional fields / methods.
> - new class: LocalizedRuntimeException (like your LocalizedException);
Good idea.
>
> * new class: ConfigManager (LocalizedBundle delegate to this class);
> - service locator;
> - code to config excetions and defaults ( useMessageIdAsDeafult(),
> useEntryIdAsDefault(), if both was false, then, we throw exceptions)
> - code to config log levels (setLevelLog2Info, setLevelLog2Warning and
> setLevelLog2Error);
> - code to setLocale (used by all messages in a given instance);
> - this class delegate calls to MessageManager;
Let me have a look at your code. Then it may become more clear ;-)
>
> * In MessageManager:
> - service locator;
> - methods to getProvider, removeProviders and reset/clear MessageManager;
> - move exception handling to ConfigManager (now it is configurable);
> - this class delegates class to each provider;
>
> * In XMLMessageProvider:
> - service locator;
> - move exception handling to ConfigManager;
> - more 2 xml formats (one file per message - as resource bundle does and a
> mix);
>
> * In ResourceBundleMessageProvider:
> - service locator;
> - move exception handling to ConfigManager;
>
> - In all classes I do some enhacements with final keyword;
>
> I do a lot of code and don't think is a good idea to put them here. How
> can
> I provide this to you? Did you have any email to I sent this? (sure, if
> you
> wish to see)
>
> Man, sorry by my english. Is more easy to me write code than write email
> ...
> If I write anything offensive, please, sorry and talk with me.
>
> Woody
>
> ----- Original Message -----
> From: "Daniel Florey" <da...@web.de>
> To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
> Sent: Saturday, February 05, 2005 5:58 AM
> Subject: AW: [i18n] status
>
>
> Hi Woody,
> Where did you post your proposals/patches? I'm very interested in
> improving
> the i18n/contract components.
> If you have any suggestions the best way is to describe the idea behind it
> so that it can be discussed in the mailing list. You can also post the
> related patches/files as attachment to a bugzilla entry (enhancement
> request).
> Please try to describe each single idea / enhancement and include some
> code
> snippets in the mail if it makes the idea clearer.
> Regarding the proposal of a ConfigManager:
> I'd like to keep the components as simple as possible. I've understood
> that
> we need to have the ability to have more than one MessageManager per VM.
> So
> my proposal would be just to add a getInstance(String messageManager)
> method
> to the MessageManager and get rid of the static methods.
> But perhaps I've missed the point. So it would be great if you could
> explain
> in more detail what the ConfigManager is for.
>
> Cheers,
> Daniel
>
> > -----Ursprüngliche Nachricht-----
> > Von: commons-dev-return-67318-daniel.florey=web.de@jakarta.apache.org
> > [mailto:commons-dev-return-67318-
> daniel.florey=web.de@jakarta.apache.org]
> > Im Auftrag von Anaximandro (Woody)
> > Gesendet: Samstag, 5. Februar 2005 06:03
> > An: Jakarta Commons Developers List; ozeigermann@apache.org
> > Betreff: Re: [i18n] status
> >
> > Thanx Oliver.
> >
> > I will wait for him, :o
> >
> > Woody
> >
> > ----- Original Message -----
> > From: "Oliver Zeigermann" <ol...@gmail.com>
> > To: "Anaximandro (Woody)" <ag...@globo.com>
> > Cc: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Friday, February 04, 2005 3:47 PM
> > Subject: Re: [i18n] status
> >
> >
> > > I am sure that your suggestions are valueable and you do not bore me
> > > at all. However, the proposals you made should be inspected by Daniel,
> > > as I have no deeper insight into neither contract nor i18n.
> > >
> > > Oliver
> > >
> > >
> > > On Fri, 4 Feb 2005 19:55:21 -0800, Anaximandro (Woody)
> > > <ag...@globo.com> wrote:
> > > > Oliver, I sent one proposal too (another class diagram, with a macro
> > vision
> > > > of my suggestions).
> > > >
> > > > The idea behind my suggestion is write one mediator (ConfigManager)
> to
> > > > retain one specific configuration (I can have many threads running
> > with
> > > > diferent configurations) and put one service locator in
> > MessageManager.
> > > >
> > > > Each message (LocalizedText, LocalizedMessage, etc) comunicates with
> > > > MessageManager through your configuration.
> > > >
> > > > I write a lot of code to test this ideas and to be more confident
> with
> > this
> > > > project, but now I stuck, this project is not mine and I need to
> take
> > easy
> > > > with ideas 8(
> > > >
> > > > You wanna see this class diagram? I'm boring you?
> > > >
> > > > Sorry
> > > >
> > > > Woody
> > > >
> > > > >
> > > > > I mainly work on xmlio, but am not aware of any proposed changes
> to
> > > > > the project. The class diagrams you sent have been put online by
> me.
> > > > >
> > > > > Oliver
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] proposals
Posted by "Anaximandro (Woody)" <ag...@globo.com>.
Hi Daniel,
The ConfigManager in my idea is used for store specific configurations, as I
see the MessageManager don't have this responsabilitie. If I store any
configuration on MessageManager I will need specific instances of this guy
for each thread with a diferent configuration.
Well, in your code you don't let the user of this component to configure the
behaviours of log, exceptions and default language. I do some code to do
this in mine and, becouse this, I need to store these configurations on a
"isolated" place. Store these guys inside MessageManager is not a good idea.
The MessageManager only store the message providers and delegate calls to
these providers.
The main objective behind this is to write less code in cases wich I need to
specify Locales differents than default Locale. Instead of write:
Locale userLocale = getUserLocale( userId );
LocalizedText txt1 = new LocalizedText( consts.ID1, userLocale ); // each
message need to set the user locale
LocalizedText txt2 = new LocalizedText( consts.ID2, userLocale ); //
LocalizedText txtN = new LocalizedText( consts.IDN, userLocale ); //
I think in write:
String servletID = getServletUUID();
ConfigManager config = new ConfigManager.getInstance( servletID );
config.setLocale( getUserLocale( userId ) );
// Only one place set the user locale
LocalizedText txt1 = new LocalizedText( consts.ID1 );
LocalizedText txt2 = new LocalizedText( consts.ID2 );
LocalizedText txtN = new LocalizedText( consts.IDN );
I agree with your idea, keep it simple here is the best thing to do, but how
to setup aditional information without a mediator to store?
The code in first example can be a problem, he multiply locale information
(configuration) in many places where I have a message ...
In my code I write:
- In LocalizedText, LocalizedMessage, LocalizedError, LocalizedException I
change the extensions. Instead of cascating extensios I do direct extensions
(LocalizedText extends LocalizedBundle, LocalizedMessage extends
LocalizedBundle, LocalizedError extends LocalizedBundle ...)
- new class: LocalizedRuntimeException (like your LocalizedException);
* new class: ConfigManager (LocalizedBundle delegate to this class);
- service locator;
- code to config excetions and defaults ( useMessageIdAsDeafult(),
useEntryIdAsDefault(), if both was false, then, we throw exceptions)
- code to config log levels (setLevelLog2Info, setLevelLog2Warning and
setLevelLog2Error);
- code to setLocale (used by all messages in a given instance);
- this class delegate calls to MessageManager;
* In MessageManager:
- service locator;
- methods to getProvider, removeProviders and reset/clear MessageManager;
- move exception handling to ConfigManager (now it is configurable);
- this class delegates class to each provider;
* In XMLMessageProvider:
- service locator;
- move exception handling to ConfigManager;
- more 2 xml formats (one file per message - as resource bundle does and a
mix);
* In ResourceBundleMessageProvider:
- service locator;
- move exception handling to ConfigManager;
- In all classes I do some enhacements with final keyword;
I do a lot of code and don't think is a good idea to put them here. How can
I provide this to you? Did you have any email to I sent this? (sure, if you
wish to see)
Man, sorry by my english. Is more easy to me write code than write email ...
If I write anything offensive, please, sorry and talk with me.
Woody
----- Original Message -----
From: "Daniel Florey" <da...@web.de>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Saturday, February 05, 2005 5:58 AM
Subject: AW: [i18n] status
Hi Woody,
Where did you post your proposals/patches? I'm very interested in improving
the i18n/contract components.
If you have any suggestions the best way is to describe the idea behind it
so that it can be discussed in the mailing list. You can also post the
related patches/files as attachment to a bugzilla entry (enhancement
request).
Please try to describe each single idea / enhancement and include some code
snippets in the mail if it makes the idea clearer.
Regarding the proposal of a ConfigManager:
I'd like to keep the components as simple as possible. I've understood that
we need to have the ability to have more than one MessageManager per VM. So
my proposal would be just to add a getInstance(String messageManager) method
to the MessageManager and get rid of the static methods.
But perhaps I've missed the point. So it would be great if you could explain
in more detail what the ConfigManager is for.
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-67318-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-67318-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Anaximandro (Woody)
> Gesendet: Samstag, 5. Februar 2005 06:03
> An: Jakarta Commons Developers List; ozeigermann@apache.org
> Betreff: Re: [i18n] status
>
> Thanx Oliver.
>
> I will wait for him, :o
>
> Woody
>
> ----- Original Message -----
> From: "Oliver Zeigermann" <ol...@gmail.com>
> To: "Anaximandro (Woody)" <ag...@globo.com>
> Cc: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, February 04, 2005 3:47 PM
> Subject: Re: [i18n] status
>
>
> > I am sure that your suggestions are valueable and you do not bore me
> > at all. However, the proposals you made should be inspected by Daniel,
> > as I have no deeper insight into neither contract nor i18n.
> >
> > Oliver
> >
> >
> > On Fri, 4 Feb 2005 19:55:21 -0800, Anaximandro (Woody)
> > <ag...@globo.com> wrote:
> > > Oliver, I sent one proposal too (another class diagram, with a macro
> vision
> > > of my suggestions).
> > >
> > > The idea behind my suggestion is write one mediator (ConfigManager) to
> > > retain one specific configuration (I can have many threads running
> with
> > > diferent configurations) and put one service locator in
> MessageManager.
> > >
> > > Each message (LocalizedText, LocalizedMessage, etc) comunicates with
> > > MessageManager through your configuration.
> > >
> > > I write a lot of code to test this ideas and to be more confident with
> this
> > > project, but now I stuck, this project is not mine and I need to take
> easy
> > > with ideas 8(
> > >
> > > You wanna see this class diagram? I'm boring you?
> > >
> > > Sorry
> > >
> > > Woody
> > >
> > > >
> > > > I mainly work on xmlio, but am not aware of any proposed changes to
> > > > the project. The class diagrams you sent have been put online by me.
> > > >
> > > > Oliver
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [i18n] status
Posted by Daniel Florey <da...@web.de>.
Hi Woody,
Where did you post your proposals/patches? I'm very interested in improving
the i18n/contract components.
If you have any suggestions the best way is to describe the idea behind it
so that it can be discussed in the mailing list. You can also post the
related patches/files as attachment to a bugzilla entry (enhancement
request).
Please try to describe each single idea / enhancement and include some code
snippets in the mail if it makes the idea clearer.
Regarding the proposal of a ConfigManager:
I'd like to keep the components as simple as possible. I've understood that
we need to have the ability to have more than one MessageManager per VM. So
my proposal would be just to add a getInstance(String messageManager) method
to the MessageManager and get rid of the static methods.
But perhaps I've missed the point. So it would be great if you could explain
in more detail what the ConfigManager is for.
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-67318-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-67318-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Anaximandro (Woody)
> Gesendet: Samstag, 5. Februar 2005 06:03
> An: Jakarta Commons Developers List; ozeigermann@apache.org
> Betreff: Re: [i18n] status
>
> Thanx Oliver.
>
> I will wait for him, :o
>
> Woody
>
> ----- Original Message -----
> From: "Oliver Zeigermann" <ol...@gmail.com>
> To: "Anaximandro (Woody)" <ag...@globo.com>
> Cc: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, February 04, 2005 3:47 PM
> Subject: Re: [i18n] status
>
>
> > I am sure that your suggestions are valueable and you do not bore me
> > at all. However, the proposals you made should be inspected by Daniel,
> > as I have no deeper insight into neither contract nor i18n.
> >
> > Oliver
> >
> >
> > On Fri, 4 Feb 2005 19:55:21 -0800, Anaximandro (Woody)
> > <ag...@globo.com> wrote:
> > > Oliver, I sent one proposal too (another class diagram, with a macro
> vision
> > > of my suggestions).
> > >
> > > The idea behind my suggestion is write one mediator (ConfigManager) to
> > > retain one specific configuration (I can have many threads running
> with
> > > diferent configurations) and put one service locator in
> MessageManager.
> > >
> > > Each message (LocalizedText, LocalizedMessage, etc) comunicates with
> > > MessageManager through your configuration.
> > >
> > > I write a lot of code to test this ideas and to be more confident with
> this
> > > project, but now I stuck, this project is not mine and I need to take
> easy
> > > with ideas 8(
> > >
> > > You wanna see this class diagram? I'm boring you?
> > >
> > > Sorry
> > >
> > > Woody
> > >
> > > >
> > > > I mainly work on xmlio, but am not aware of any proposed changes to
> > > > the project. The class diagrams you sent have been put online by me.
> > > >
> > > > Oliver
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] status
Posted by "Anaximandro (Woody)" <ag...@globo.com>.
Thanx Oliver.
I will wait for him, :o
Woody
----- Original Message -----
From: "Oliver Zeigermann" <ol...@gmail.com>
To: "Anaximandro (Woody)" <ag...@globo.com>
Cc: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, February 04, 2005 3:47 PM
Subject: Re: [i18n] status
> I am sure that your suggestions are valueable and you do not bore me
> at all. However, the proposals you made should be inspected by Daniel,
> as I have no deeper insight into neither contract nor i18n.
>
> Oliver
>
>
> On Fri, 4 Feb 2005 19:55:21 -0800, Anaximandro (Woody)
> <ag...@globo.com> wrote:
> > Oliver, I sent one proposal too (another class diagram, with a macro
vision
> > of my suggestions).
> >
> > The idea behind my suggestion is write one mediator (ConfigManager) to
> > retain one specific configuration (I can have many threads running with
> > diferent configurations) and put one service locator in MessageManager.
> >
> > Each message (LocalizedText, LocalizedMessage, etc) comunicates with
> > MessageManager through your configuration.
> >
> > I write a lot of code to test this ideas and to be more confident with
this
> > project, but now I stuck, this project is not mine and I need to take
easy
> > with ideas 8(
> >
> > You wanna see this class diagram? I'm boring you?
> >
> > Sorry
> >
> > Woody
> >
> > >
> > > I mainly work on xmlio, but am not aware of any proposed changes to
> > > the project. The class diagrams you sent have been put online by me.
> > >
> > > Oliver
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] status
Posted by Oliver Zeigermann <ol...@gmail.com>.
I am sure that your suggestions are valueable and you do not bore me
at all. However, the proposals you made should be inspected by Daniel,
as I have no deeper insight into neither contract nor i18n.
Oliver
On Fri, 4 Feb 2005 19:55:21 -0800, Anaximandro (Woody)
<ag...@globo.com> wrote:
> Oliver, I sent one proposal too (another class diagram, with a macro vision
> of my suggestions).
>
> The idea behind my suggestion is write one mediator (ConfigManager) to
> retain one specific configuration (I can have many threads running with
> diferent configurations) and put one service locator in MessageManager.
>
> Each message (LocalizedText, LocalizedMessage, etc) comunicates with
> MessageManager through your configuration.
>
> I write a lot of code to test this ideas and to be more confident with this
> project, but now I stuck, this project is not mine and I need to take easy
> with ideas 8(
>
> You wanna see this class diagram? I'm boring you?
>
> Sorry
>
> Woody
>
> >
> > I mainly work on xmlio, but am not aware of any proposed changes to
> > the project. The class diagrams you sent have been put online by me.
> >
> > Oliver
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] status
Posted by "Anaximandro (Woody)" <ag...@globo.com>.
Oliver, I sent one proposal too (another class diagram, with a macro vision
of my suggestions).
The idea behind my suggestion is write one mediator (ConfigManager) to
retain one specific configuration (I can have many threads running with
diferent configurations) and put one service locator in MessageManager.
Each message (LocalizedText, LocalizedMessage, etc) comunicates with
MessageManager through your configuration.
I write a lot of code to test this ideas and to be more confident with this
project, but now I stuck, this project is not mine and I need to take easy
with ideas 8(
You wanna see this class diagram? I'm boring you?
Sorry
Woody
>
> I mainly work on xmlio, but am not aware of any proposed changes to
> the project. The class diagrams you sent have been put online by me.
>
> Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] status
Posted by Oliver Zeigermann <ol...@gmail.com>.
Woody,
I mainly work on xmlio, but am not aware of any proposed changes to
the project. The class diagrams you sent have been put online by me.
Oliver
On Fri, 4 Feb 2005 16:15:41 -0300, agodinhost@globo.com
<ag...@globo.com> wrote:
> Daniel and Oliver, please, this project will continue?
> I sent a class diagram with changes (proposal changes) but I no receive
> any response from both.
> I know you are working on other projects (transaction, slide, etc ) but,
> please, aswer me. I really wanna participate ...
>
> Thanx again
>
> Woody
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org