Re: [Proposal] Migrate to Dependency on commons-resources

[Martin Cooper]

On Mon, 13 Jan 2003, Ted Husted wrote:

> Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and
> Message element [o.a.s.a.ActionMessages] to Commons Resources?

+1

>
> The idea being a domain logic object may like to return a collection of
> Messages to the presentation tier. (At least mine would!)
>
> I'm thinking someone should be able to offload the whole
> ActionForm.validate() mechanism to the domain tier, and just use Struts
> to reconcile and display the messages according to the client's locale.
>
> I've actually already started to generalize ActionMessage/s. for this
> purpose. At one time, I think Martin and I were talking about putting it
> somewhere in the Commons, but I forget which package now. Resources
> makes sense to me. =:0)

That would be this thread:

http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg08356.html

You sold me on Resources. ;-) See the thread for the various naming
options we discussed.

--
Martin Cooper


>
> So, then, ActionMessages would also become a wrapper around a Commons
> class and would also encapsulate the Struts globals.
>
> Of course, I am volunteering to port the code, if that's what we want to do.
>
> -Ted.
>
>
> Craig R. McClanahan wrote:
> > As we've discussed a couple of times, the last major functionality change
> > we had discussed for Struts 1.1 was to migrate to dependence on
> > commons-resources, rather than the proprietary message resource facilities
> > inside og.apache.struts.util.  As you might recall, Michael Schacter took
> > a first crack at factoring out the Struts resources classes out to create
> > this commons package, which is currently in the sandbox.
> >
> > I've recently gone through it, and did a major refactoring of
> > commons-resources, to the point where I'm now ready to propose that we
> > modify Struts to depend on it.  I'd like the other committers to evaluate
> > the current state of commons-resources, and my proposed integration plan
> > below, to see what they think of this idea.
> >
> > The nightly build of commons-resources.jar included in recent Struts
> > nightly builds is the code that I'm proposing.  You can see the Javadocs
> > for this code at:
> >
> >   http://jakarta.apache.org/commons/resources/api/
> >
> > and get the sources via either CVS (from jakarta-commons-sandbox) or
> > nightly snapshots:
> >
> >   http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/
> >
> > In terms of Struts integration, I propose:
> >
> > (1) Most Struts classes declare a static MessageResources instance
> > for the messages unique to that Struts package.  For example,
> > org.apache.struts.taglib.bean.CookieTag has this:
> >
> > protected static MessageResources messages =
> >   MessageResources.getMessageResources
> >   ("org.apache.struts.taglib.bean.LocalStrings");
> >
> > This would be migrated to the new Messages class from commons-resources:
> >
> > protected static Messages messages =
> >   Messages.getMessages("org.apache.struts.taglib.bean");
> >
> > The calls to actually retrieve message strings are compatible with
> > the existing code, as well as the properties files used to acquire
> > the message strings, so no other changes should be required.
> >
> > (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
> > around equivalent functionality from commons-resources (much like
> > GenericDataSource now wraps commons-dbcp), and deprecate them.
> > This protects existing apps that are customizing these APIs,
> > but allows us to remove the o.a.s.u classes in a future version.
> >
> > (3) Modify the  initialization element to allow
> > the selection and configuration of an appropriate
> > ResourcesFactory from commons-resources, wrapped by a Messages
> > instance.  This is primarily a change in the interpretation of
> > the "factory" attribute, and should not affect anyone that uses
> > the current default.
> >
> > (4) Modify all internal uses (including in tag libraries) of
> > org.apache.struts.util.MessageResources to use
> > org.apache.commons.resources.Messages instead.  This will be
> > transparent to users that use the standard implementations, but
> > will require folks who have subclassed the MessageResources
> > classes to migrate their code as well.
> >
> > What do you think?  Should we go ahead and do this migration?  Is the
> > commons-resources package as it stands now as complete and functional as
> > it needs to be (obviously, it'll need to be promoted to a standard Commons
> > package and released so we can rely on it, which will require a couple of
> > volunteers willing to help me maintain it).  Should we do the entire
> > migration outlined above, or maybe only part of it?
> >
> > Thoughts, please.
> >
> > Craig
> >
> >
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail:

Re: [Proposal] Migrate to Dependency on commons-resources

[Martin Cooper]

I'm +1 on the principle of going for the whole enchilada. I haven't had a
chance to look over the latest changes to Commons Resources yet, but I'm a
committer on Resources, so I can always fix any problems I see. ;-) And
you can count me in as a volunteer willing to help maintain it (and +1 the
move to Proper and the release).

--
Martin Cooper


On Sun, 12 Jan 2003, Craig R. McClanahan wrote:

> As we've discussed a couple of times, the last major functionality change
> we had discussed for Struts 1.1 was to migrate to dependence on
> commons-resources, rather than the proprietary message resource facilities
> inside og.apache.struts.util.  As you might recall, Michael Schacter took
> a first crack at factoring out the Struts resources classes out to create
> this commons package, which is currently in the sandbox.
>
> I've recently gone through it, and did a major refactoring of
> commons-resources, to the point where I'm now ready to propose that we
> modify Struts to depend on it.  I'd like the other committers to evaluate
> the current state of commons-resources, and my proposed integration plan
> below, to see what they think of this idea.
>
> The nightly build of commons-resources.jar included in recent Struts
> nightly builds is the code that I'm proposing.  You can see the Javadocs
> for this code at:
>
>   http://jakarta.apache.org/commons/resources/api/
>
> and get the sources via either CVS (from jakarta-commons-sandbox) or
> nightly snapshots:
>
>   http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/
>
> In terms of Struts integration, I propose:
>
> (1) Most Struts classes declare a static MessageResources instance
> for the messages unique to that Struts package.  For example,
> org.apache.struts.taglib.bean.CookieTag has this:
>
> protected static MessageResources messages =
>   MessageResources.getMessageResources
>   ("org.apache.struts.taglib.bean.LocalStrings");
>
> This would be migrated to the new Messages class from commons-resources:
>
> protected static Messages messages =
>   Messages.getMessages("org.apache.struts.taglib.bean");
>
> The calls to actually retrieve message strings are compatible with
> the existing code, as well as the properties files used to acquire
> the message strings, so no other changes should be required.
>
> (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
> around equivalent functionality from commons-resources (much like
> GenericDataSource now wraps commons-dbcp), and deprecate them.
> This protects existing apps that are customizing these APIs,
> but allows us to remove the o.a.s.u classes in a future version.
>
> (3) Modify the  initialization element to allow
> the selection and configuration of an appropriate
> ResourcesFactory from commons-resources, wrapped by a Messages
> instance.  This is primarily a change in the interpretation of
> the "factory" attribute, and should not affect anyone that uses
> the current default.
>
> (4) Modify all internal uses (including in tag libraries) of
> org.apache.struts.util.MessageResources to use
> org.apache.commons.resources.Messages instead.  This will be
> transparent to users that use the standard implementations, but
> will require folks who have subclassed the MessageResources
> classes to migrate their code as well.
>
> What do you think?  Should we go ahead and do this migration?  Is the
> commons-resources package as it stands now as complete and functional as
> it needs to be (obviously, it'll need to be promoted to a standard Commons
> package and released so we can rely on it, which will require a couple of
> volunteers willing to help me maintain it).  Should we do the entire
> migration outlined above, or maybe only part of it?
>
> Thoughts, please.
>
> Craig
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Requested modification of InsertTag.java

[Martin Cooper]

Enhancement requests should be posted to the bug database, as described
here:

http://jakarta.apache.org/struts/using.html#Bugs

That will make sure it doesn't get lost, and will be addressed at some
point.

--
Martin Cooper


On 13 Jan 2003, Jay wrote:

> Requested modification of tiles/InsertTag.java
>
> I appreciate your ExceptionHandler concept and use it for capturing
> critical errors, thoroughly logging both error and context information
> and forwarding to a special web page that displays very concise
> information about the error (error reference number, etc)  However, for
> completeness sake, I wish to capture any serious errors that occur in
> the "forwarding" phase beyond action handling processing, where,
> particularly using "tiles", one or more JSP servlets are run.
>
> I found a solution that seemed straightforward.  Since I already
> sub-classed TilesRequestProcessor to override one of the other "process"
> methods, I simply overrode processActionForward, wrapped the call to the
> super class in a try/catch block, and forwarded accordingly if an
> exception is thrown.  Below shows the pertinent portions of the
> override:
>
>
> protected void processActionForward(HttpServletRequest request,
> HttpServletResponse response,
> ActionForward forward)
> throws IOException, ServletException {
>
> try {
> super.processActionForward(request,response,forward);
> }
> catch (Throwable ex) {
> // Log information, etc
> ActionForward errorForward;
> // Fetch special forwarding for critical errors.
> .
> .
> .   .
>
>   super.processActionForward(request,response,errorForward); 
> }
> }
>
>
> The "snag" I ran into was tiles/InsertTag.  The normal behavior of the
> class is to broadcast the error message on the web page and "carry on."
> Specifically, from the inner protected class
> InsertHandler::processException():
>
> protected void processException(Throwable ex, String msg) throws
> JspException {
> .
> .
> .
> .
> } else { // show only message
>
> pageContext.getOut().println(msg);
> } // end if
>
>
> Could you kindly consider moving the real processing of
> processException() to a method inside InsertTag itself so that users may
> easily sub-class to override the "broadcasting" behavior?  In other
> words, could you do something like:
>
> protected class InsertHandler {
> .
> .
> protected void processException(Throwable ex.msg,String
> msg)  throws
> JspException
> {
> processTilesException(ex,msg);
> }
>
> }
>
>
> /** Real work done here
>  */
> protected void processTilesException(Throwable ex, String msg)
> throws
> JspException {
> .
> .
> .
> }
>
> I would be greatly appreciative if you consider this very minor change.
>
> Thank you,
> Jay
>
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Passing parameters with mapping.findforward

[Martin Cooper]

This question is really a question for the struts-user list, and not the
struts-dev list. In any case, the answer to your question is documented at
the link Laird provided.

--
Martin Cooper


On Mon, 13 Jan 2003, Rajendra Yadav wrote:

>
> Can we pass objects using the struts framework ?
>  "Nelson, Laird" <[EMAIL PROTECTED]> wrote:> -Original Message-
> > From: Rajendra Yadav [mailto:[EMAIL PROTECTED]]
> > How do we pass parameters from one jsp to another using the
> > Struts framework.
>
> Nothing to do with Struts. See the Servlet API.
>
> http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletRequest.h
> tml#setAttribute(java.lang.String, java.lang.Object)
>
> HTH,
> Laird
>
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
>
> -
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Passing parameters with mapping.findforward

[Rajendra Yadav]

Can we pass objects using the struts framework ?
 "Nelson, Laird" <[EMAIL PROTECTED]> wrote:> -Original Message-
> From: Rajendra Yadav [mailto:[EMAIL PROTECTED]]
> How do we pass parameters from one jsp to another using the 
> Struts framework.

Nothing to do with Struts. See the Servlet API.

http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletRequest.h
tml#setAttribute(java.lang.String, java.lang.Object)

HTH,
Laird

--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

DO NOT REPLY [Bug 16048] New: - Example page won't compile under jboss

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16048

Example page won't compile under jboss

   Summary: Example page won't compile under jboss
   Product: Struts
   Version: 1.0.2 Final
  Platform: PC
   URL: http://192.168.1.10:8080/struts-exercise-taglib/html-
select.jsp
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Example
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Under JBoss-3.0.4, the page html-select.jsp from struts-exercise-taglib.war
won't compile. I was able to fix this by removing a "stray" semicolon from the
page import declaration.


The line used to read:
<%@ page language="java" import="java.util.*,
org.apache.struts.webapp.exercise.*;"%>


But needs to read:
<%@ page language="java" import="java.util.*,org.apache.struts.webapp.exercise.*"%>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Proposal] Migrate to Dependency on commons-resources

[David Graham]

I agree with you.  I was mainly talking about the name ActionMessages.  I 
think there's a more generic name that doesn't seem to be so Struts 
specific.

David






From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: [Proposal] Migrate to Dependency on commons-resources
Date: Mon, 13 Jan 2003 18:15:24 -0500

I am using them outside of Struts now, and it makes perfect sense =:0)

It's important to remember that the idea of a message resource is generic 
to an application and is not a Struts concept. If something occurs on the 
domain layer, the enterprise application should be able to return the 
information using the same tokens as the presentation tier.

Or, more properly, the presentation tier (Struts) should use the same 
tokens as the rest of the application.  =:>

Struts uses the ApplicationResource but the underlying idea is it belongs 
to the application generally (hence, the name).

It's actually very difficult to write an multi-tier i18n enterprise 
application with something like the (Action)Messages. There are a ton of 
messges that you want to return from the domain, including confirmation 
messages (like "record #63 inserted").

Meanwhile, the Commons Validator also has the idea of a Message carrier 
(like ActionMessages) at its core, and there should be a generic 
implementation of this object in the Commons, whether Struts uses it or 
not.

-Ted.

David Graham wrote:
ActionMessages doesn't make sense outside of Struts.  It would need a new 
name at the least.  If we move them to commons, they should become 
interfaces with some default implementations.  Then people would be free 
to plugin their own implementation.

I think they're fine staying in Struts for now;  2.0 might be a better 
time to look at this architecture.

David






From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: [Proposal] Migrate to Dependency on commons-resources
Date: Mon, 13 Jan 2003 17:40:38 -0500

Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and 
Message element [o.a.s.a.ActionMessages] to Commons Resources?

The idea being a domain logic object may like to return a collection of 
Messages to the presentation tier. (At least mine would!)

I'm thinking someone should be able to offload the whole 
ActionForm.validate() mechanism to the domain tier, and just use Struts 
to reconcile and display the messages according to the client's locale.

I've actually already started to generalize ActionMessage/s. for this 
purpose. At one time, I think Martin and I were talking about putting it 
somewhere in the Commons, but I forget which package now. Resources makes 
sense to me. =:0)

So, then, ActionMessages would also become a wrapper around a Commons 
class and would also encapsulate the Struts globals.

Of course, I am volunteering to port the code, if that's what we want to 
do.

-Ted.


Craig R. McClanahan wrote:

As we've discussed a couple of times, the last major functionality 
change
we had discussed for Struts 1.1 was to migrate to dependence on
commons-resources, rather than the proprietary message resource 
facilities
inside og.apache.struts.util.  As you might recall, Michael Schacter 
took
a first crack at factoring out the Struts resources classes out to 
create
this commons package, which is currently in the sandbox.

I've recently gone through it, and did a major refactoring of
commons-resources, to the point where I'm now ready to propose that we
modify Struts to depend on it.  I'd like the other committers to 
evaluate
the current state of commons-resources, and my proposed integration plan
below, to see what they think of this idea.

The nightly build of commons-resources.jar included in recent Struts
nightly builds is the code that I'm proposing.  You can see the Javadocs
for this code at:

  http://jakarta.apache.org/commons/resources/api/

and get the sources via either CVS (from jakarta-commons-sandbox) or
nightly snapshots:

  
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/


In terms of Struts integration, I propose:

(1) Most Struts classes declare a static MessageResources instance
for the messages unique to that Struts package.  For example,
org.apache.struts.taglib.bean.CookieTag has this:

protected static MessageResources messages =
  MessageResources.getMessageResources
  ("org.apache.struts.taglib.bean.LocalStrings");

This would be migrated to the new Messages class from 
commons-resources:

protected static Messages messages =
  Messages.getMessages("org.apache.struts.taglib.bean");

The calls to actually retrieve message strings are compatible with
the existing code, as well as the properties files used to acquire
the message strings, so no other changes should be required.

(2)

Re: [Proposal] Migrate to Dependency on commons-resources

[Craig R. McClanahan]

On Mon, 13 Jan 2003, Ted Husted wrote:

> Date: Mon, 13 Jan 2003 17:40:38 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: [Proposal] Migrate to Dependency on commons-resources
>
> Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and
> Message element [o.a.s.a.ActionMessages] to Commons Resources?
>

That makes sense to me.  There's lots of scenarios for transfer of
individual messages, or message lists, between application tiers.

> The idea being a domain logic object may like to return a collection of
> Messages to the presentation tier. (At least mine would!)
>
> I'm thinking someone should be able to offload the whole
> ActionForm.validate() mechanism to the domain tier, and just use Struts
> to reconcile and display the messages according to the client's locale.
>
> I've actually already started to generalize ActionMessage/s. for this
> purpose. At one time, I think Martin and I were talking about putting it
> somewhere in the Commons, but I forget which package now. Resources
> makes sense to me. =:0)
>
> So, then, ActionMessages would also become a wrapper around a Commons
> class and would also encapsulate the Struts globals.
>
> Of course, I am volunteering to port the code, if that's what we want to do.
>

+1 -- go for it.  Don't forget to add yourself as a committer ...

How about if you create o.a.c.r.Message and o.a.c.r.MessageList?

> -Ted.
>

Craig


>
> Craig R. McClanahan wrote:
> > As we've discussed a couple of times, the last major functionality change
> > we had discussed for Struts 1.1 was to migrate to dependence on
> > commons-resources, rather than the proprietary message resource facilities
> > inside og.apache.struts.util.  As you might recall, Michael Schacter took
> > a first crack at factoring out the Struts resources classes out to create
> > this commons package, which is currently in the sandbox.
> >
> > I've recently gone through it, and did a major refactoring of
> > commons-resources, to the point where I'm now ready to propose that we
> > modify Struts to depend on it.  I'd like the other committers to evaluate
> > the current state of commons-resources, and my proposed integration plan
> > below, to see what they think of this idea.
> >
> > The nightly build of commons-resources.jar included in recent Struts
> > nightly builds is the code that I'm proposing.  You can see the Javadocs
> > for this code at:
> >
> >   http://jakarta.apache.org/commons/resources/api/
> >
> > and get the sources via either CVS (from jakarta-commons-sandbox) or
> > nightly snapshots:
> >
> >   http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/
> >
> > In terms of Struts integration, I propose:
> >
> > (1) Most Struts classes declare a static MessageResources instance
> > for the messages unique to that Struts package.  For example,
> > org.apache.struts.taglib.bean.CookieTag has this:
> >
> > protected static MessageResources messages =
> >   MessageResources.getMessageResources
> >   ("org.apache.struts.taglib.bean.LocalStrings");
> >
> > This would be migrated to the new Messages class from commons-resources:
> >
> > protected static Messages messages =
> >   Messages.getMessages("org.apache.struts.taglib.bean");
> >
> > The calls to actually retrieve message strings are compatible with
> > the existing code, as well as the properties files used to acquire
> > the message strings, so no other changes should be required.
> >
> > (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
> > around equivalent functionality from commons-resources (much like
> > GenericDataSource now wraps commons-dbcp), and deprecate them.
> > This protects existing apps that are customizing these APIs,
> > but allows us to remove the o.a.s.u classes in a future version.
> >
> > (3) Modify the  initialization element to allow
> > the selection and configuration of an appropriate
> > ResourcesFactory from commons-resources, wrapped by a Messages
> > instance.  This is primarily a change in the interpretation of
> > the "factory" attribute, and should not affect anyone that uses
> > the current default.
> >
> > (4) Modify all internal uses (including in tag libraries) of
> > org.apache.struts.util.MessageResources to use
> > org.apache.commons.resources.Messages instead.  This will be
> > transparent to users that use the standard implementations, but
> > will require folks who have subclassed the MessageResources
> > classes to migrate their code as well.
> >
> > What do you think?  Should we go ahead and do this migration?  Is the
> > commons-resources package as it stands now as complete and functional as
> > it needs to be (obviously, it'll need to be promoted to a standard Commons
> > package and released so we can rely on i

RE: [Proposal] Migrate to Dependency on commons-resources

[Edgar P. Dollin]

I like the idea.

While your at it, can each message pass in its own resource bundle so
you can keep the resources with the Class/Package?

Edgar

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]] 
Sent: Monday, January 13, 2003 6:15 PM
To: Struts Developers List
Subject: Re: [Proposal] Migrate to Dependency on commons-resources


I am using them outside of Struts now, and it makes perfect sense =:0)

It's important to remember that the idea of a message resource is 
generic to an application and is not a Struts concept. If something 
occurs on the domain layer, the enterprise application should be able to

return the information using the same tokens as the presentation tier.

Or, more properly, the presentation tier (Struts) should use the same 
tokens as the rest of the application.  =:>

Struts uses the ApplicationResource but the underlying idea is it 
belongs to the application generally (hence, the name).

It's actually very difficult to write an multi-tier i18n enterprise 
application with something like the (Action)Messages. There are a ton of

messges that you want to return from the domain, including confirmation 
messages (like "record #63 inserted").

Meanwhile, the Commons Validator also has the idea of a Message carrier 
(like ActionMessages) at its core, and there should be a generic 
implementation of this object in the Commons, whether Struts uses it or 
not.

-Ted.

David Graham wrote:
> ActionMessages doesn't make sense outside of Struts.  It would need a
> new name at the least.  If we move them to commons, they should become

> interfaces with some default implementations.  Then people would be
free 
> to plugin their own implementation.
> 
> I think they're fine staying in Struts for now;  2.0 might be a better
> time to look at this architecture.
> 
> David
> 
> 
> 
> 
> 
> 
>> From: Ted Husted <[EMAIL PROTECTED]>
>> Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
>> To: Struts Developers List <[EMAIL PROTECTED]>
>> Subject: Re: [Proposal] Migrate to Dependency on commons-resources
>> Date: Mon, 13 Jan 2003 17:40:38 -0500
>>
>> Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and
>> Message element [o.a.s.a.ActionMessages] to Commons Resources?
>>
>> The idea being a domain logic object may like to return a collection
>> of Messages to the presentation tier. (At least mine would!)
>>
>> I'm thinking someone should be able to offload the whole
>> ActionForm.validate() mechanism to the domain tier, and just use 
>> Struts to reconcile and display the messages according to the
client's 
>> locale.
>>
>> I've actually already started to generalize ActionMessage/s. for this
>> purpose. At one time, I think Martin and I were talking about putting

>> it somewhere in the Commons, but I forget which package now.
Resources 
>> makes sense to me. =:0)
>>
>> So, then, ActionMessages would also become a wrapper around a Commons
>> class and would also encapsulate the Struts globals.
>>
>> Of course, I am volunteering to port the code, if that's what we want
>> to do.
>>
>> -Ted.
>>
>>
>> Craig R. McClanahan wrote:
>>
>>> As we've discussed a couple of times, the last major functionality
>>> change
>>> we had discussed for Struts 1.1 was to migrate to dependence on
>>> commons-resources, rather than the proprietary message resource 
>>> facilities
>>> inside og.apache.struts.util.  As you might recall, Michael Schacter

>>> took
>>> a first crack at factoring out the Struts resources classes out to 
>>> create
>>> this commons package, which is currently in the sandbox.
>>>
>>> I've recently gone through it, and did a major refactoring of 
>>> commons-resources, to the point where I'm now ready to propose that 
>>> we modify Struts to depend on it.  I'd like the other committers to 
>>> evaluate the current state of commons-resources, and my proposed 
>>> integration plan below, to see what they think of this idea.
>>>
>>> The nightly build of commons-resources.jar included in recent Struts

>>> nightly builds is the code that I'm proposing.  You can see the 
>>> Javadocs for this code at:
>>>
>>>   http://jakarta.apache.org/commons/resources/api/
>>>
>>> and get the sources via either CVS (from jakarta-commons-sandbox) or

>>> nightly snapshots:
>>>
>>>   
>>> http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-res
>>> ources/
>>>
>>>
>>> In terms of Struts integration, I propose:
>>>
>>> (1) Most Struts classes declare a static MessageResources instance
>>> for the messages unique to that Struts package.  For example,
>>> org.apache.struts.taglib.bean.CookieTag has this:
>>>
>>> protected static MessageResources messages =
>>>   MessageResources.getMessageResources
>>>   ("org.apache.struts.taglib.bean.LocalStrings");
>>>
>>> This would be migrated to the new Messages class from
>>> commons-resources:
>>>
>>> protected static Messages messages =
>>>   Messages.getMessages("org.apache.st

Re: [Proposal] Migrate to Dependency on commons-resources

[Ted Husted]

I am using them outside of Struts now, and it makes perfect sense =:0)

It's important to remember that the idea of a message resource is 
generic to an application and is not a Struts concept. If something 
occurs on the domain layer, the enterprise application should be able to 
return the information using the same tokens as the presentation tier.

Or, more properly, the presentation tier (Struts) should use the same 
tokens as the rest of the application.  =:>

Struts uses the ApplicationResource but the underlying idea is it 
belongs to the application generally (hence, the name).

It's actually very difficult to write an multi-tier i18n enterprise 
application with something like the (Action)Messages. There are a ton of 
messges that you want to return from the domain, including confirmation 
messages (like "record #63 inserted").

Meanwhile, the Commons Validator also has the idea of a Message carrier 
(like ActionMessages) at its core, and there should be a generic 
implementation of this object in the Commons, whether Struts uses it or 
not.

-Ted.

David Graham wrote:
ActionMessages doesn't make sense outside of Struts.  It would need a 
new name at the least.  If we move them to commons, they should become 
interfaces with some default implementations.  Then people would be free 
to plugin their own implementation.

I think they're fine staying in Struts for now;  2.0 might be a better 
time to look at this architecture.

David






From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: [Proposal] Migrate to Dependency on commons-resources
Date: Mon, 13 Jan 2003 17:40:38 -0500

Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and 
Message element [o.a.s.a.ActionMessages] to Commons Resources?

The idea being a domain logic object may like to return a collection 
of Messages to the presentation tier. (At least mine would!)

I'm thinking someone should be able to offload the whole 
ActionForm.validate() mechanism to the domain tier, and just use 
Struts to reconcile and display the messages according to the client's 
locale.

I've actually already started to generalize ActionMessage/s. for this 
purpose. At one time, I think Martin and I were talking about putting 
it somewhere in the Commons, but I forget which package now. Resources 
makes sense to me. =:0)

So, then, ActionMessages would also become a wrapper around a Commons 
class and would also encapsulate the Struts globals.

Of course, I am volunteering to port the code, if that's what we want 
to do.

-Ted.


Craig R. McClanahan wrote:

As we've discussed a couple of times, the last major functionality 
change
we had discussed for Struts 1.1 was to migrate to dependence on
commons-resources, rather than the proprietary message resource 
facilities
inside og.apache.struts.util.  As you might recall, Michael Schacter 
took
a first crack at factoring out the Struts resources classes out to 
create
this commons package, which is currently in the sandbox.

I've recently gone through it, and did a major refactoring of
commons-resources, to the point where I'm now ready to propose that we
modify Struts to depend on it.  I'd like the other committers to 
evaluate
the current state of commons-resources, and my proposed integration plan
below, to see what they think of this idea.

The nightly build of commons-resources.jar included in recent Struts
nightly builds is the code that I'm proposing.  You can see the Javadocs
for this code at:

  http://jakarta.apache.org/commons/resources/api/

and get the sources via either CVS (from jakarta-commons-sandbox) or
nightly snapshots:

  
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/ 


In terms of Struts integration, I propose:

(1) Most Struts classes declare a static MessageResources instance
for the messages unique to that Struts package.  For example,
org.apache.struts.taglib.bean.CookieTag has this:

protected static MessageResources messages =
  MessageResources.getMessageResources
  ("org.apache.struts.taglib.bean.LocalStrings");

This would be migrated to the new Messages class from 
commons-resources:

protected static Messages messages =
  Messages.getMessages("org.apache.struts.taglib.bean");

The calls to actually retrieve message strings are compatible with
the existing code, as well as the properties files used to acquire
the message strings, so no other changes should be required.

(2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
around equivalent functionality from commons-resources (much like
GenericDataSource now wraps commons-dbcp), and deprecate them.
This protects existing apps that are customizing these APIs,
but allows us to remove the o.a.s.u classes in a future version.

(3) Modify the  initialization element to allow
the selection and conf

Re: [Proposal] Migrate to Dependency on commons-resources

[David Graham]

ActionMessages doesn't make sense outside of Struts.  It would need a new 
name at the least.  If we move them to commons, they should become 
interfaces with some default implementations.  Then people would be free to 
plugin their own implementation.

I think they're fine staying in Struts for now;  2.0 might be a better time 
to look at this architecture.

David






From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: [Proposal] Migrate to Dependency on commons-resources
Date: Mon, 13 Jan 2003 17:40:38 -0500

Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and 
Message element [o.a.s.a.ActionMessages] to Commons Resources?

The idea being a domain logic object may like to return a collection of 
Messages to the presentation tier. (At least mine would!)

I'm thinking someone should be able to offload the whole 
ActionForm.validate() mechanism to the domain tier, and just use Struts to 
reconcile and display the messages according to the client's locale.

I've actually already started to generalize ActionMessage/s. for this 
purpose. At one time, I think Martin and I were talking about putting it 
somewhere in the Commons, but I forget which package now. Resources makes 
sense to me. =:0)

So, then, ActionMessages would also become a wrapper around a Commons class 
and would also encapsulate the Struts globals.

Of course, I am volunteering to port the code, if that's what we want to 
do.

-Ted.


Craig R. McClanahan wrote:
As we've discussed a couple of times, the last major functionality change
we had discussed for Struts 1.1 was to migrate to dependence on
commons-resources, rather than the proprietary message resource facilities
inside og.apache.struts.util.  As you might recall, Michael Schacter took
a first crack at factoring out the Struts resources classes out to create
this commons package, which is currently in the sandbox.

I've recently gone through it, and did a major refactoring of
commons-resources, to the point where I'm now ready to propose that we
modify Struts to depend on it.  I'd like the other committers to evaluate
the current state of commons-resources, and my proposed integration plan
below, to see what they think of this idea.

The nightly build of commons-resources.jar included in recent Struts
nightly builds is the code that I'm proposing.  You can see the Javadocs
for this code at:

  http://jakarta.apache.org/commons/resources/api/

and get the sources via either CVS (from jakarta-commons-sandbox) or
nightly snapshots:

  
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/

In terms of Struts integration, I propose:

(1) Most Struts classes declare a static MessageResources instance
for the messages unique to that Struts package.  For example,
org.apache.struts.taglib.bean.CookieTag has this:

protected static MessageResources messages =
  MessageResources.getMessageResources
  ("org.apache.struts.taglib.bean.LocalStrings");

This would be migrated to the new Messages class from 
commons-resources:

protected static Messages messages =
  Messages.getMessages("org.apache.struts.taglib.bean");

The calls to actually retrieve message strings are compatible with
the existing code, as well as the properties files used to acquire
the message strings, so no other changes should be required.

(2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
around equivalent functionality from commons-resources (much like
GenericDataSource now wraps commons-dbcp), and deprecate them.
This protects existing apps that are customizing these APIs,
but allows us to remove the o.a.s.u classes in a future version.

(3) Modify the  initialization element to allow
the selection and configuration of an appropriate
ResourcesFactory from commons-resources, wrapped by a Messages
instance.  This is primarily a change in the interpretation of
the "factory" attribute, and should not affect anyone that uses
the current default.

(4) Modify all internal uses (including in tag libraries) of
org.apache.struts.util.MessageResources to use
org.apache.commons.resources.Messages instead.  This will be
transparent to users that use the standard implementations, but
will require folks who have subclassed the MessageResources
classes to migrate their code as well.

What do you think?  Should we go ahead and do this migration?  Is the
commons-resources package as it stands now as complete and functional as
it needs to be (obviously, it'll need to be promoted to a standard Commons
package and released so we can rely on it, which will require a couple of
volunteers willing to help me maintain it).  Should we do the entire
migration outlined above, or maybe only part of it?

Thoughts, please.

Craig



--
To unsubscribe, e-mail:   

Re: [Proposal] Migrate to Dependency on commons-resources

[Ted Husted]

Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and 
Message element [o.a.s.a.ActionMessages] to Commons Resources?

The idea being a domain logic object may like to return a collection of 
Messages to the presentation tier. (At least mine would!)

I'm thinking someone should be able to offload the whole 
ActionForm.validate() mechanism to the domain tier, and just use Struts 
to reconcile and display the messages according to the client's locale.

I've actually already started to generalize ActionMessage/s. for this 
purpose. At one time, I think Martin and I were talking about putting it 
somewhere in the Commons, but I forget which package now. Resources 
makes sense to me. =:0)

So, then, ActionMessages would also become a wrapper around a Commons 
class and would also encapsulate the Struts globals.

Of course, I am volunteering to port the code, if that's what we want to do.

-Ted.


Craig R. McClanahan wrote:
As we've discussed a couple of times, the last major functionality change
we had discussed for Struts 1.1 was to migrate to dependence on
commons-resources, rather than the proprietary message resource facilities
inside og.apache.struts.util.  As you might recall, Michael Schacter took
a first crack at factoring out the Struts resources classes out to create
this commons package, which is currently in the sandbox.

I've recently gone through it, and did a major refactoring of
commons-resources, to the point where I'm now ready to propose that we
modify Struts to depend on it.  I'd like the other committers to evaluate
the current state of commons-resources, and my proposed integration plan
below, to see what they think of this idea.

The nightly build of commons-resources.jar included in recent Struts
nightly builds is the code that I'm proposing.  You can see the Javadocs
for this code at:

  http://jakarta.apache.org/commons/resources/api/

and get the sources via either CVS (from jakarta-commons-sandbox) or
nightly snapshots:

  http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/

In terms of Struts integration, I propose:

(1) Most Struts classes declare a static MessageResources instance
for the messages unique to that Struts package.  For example,
org.apache.struts.taglib.bean.CookieTag has this:

protected static MessageResources messages =
  MessageResources.getMessageResources
  ("org.apache.struts.taglib.bean.LocalStrings");

This would be migrated to the new Messages class from commons-resources:

protected static Messages messages =
  Messages.getMessages("org.apache.struts.taglib.bean");

The calls to actually retrieve message strings are compatible with
the existing code, as well as the properties files used to acquire
the message strings, so no other changes should be required.

(2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
around equivalent functionality from commons-resources (much like
GenericDataSource now wraps commons-dbcp), and deprecate them.
This protects existing apps that are customizing these APIs,
but allows us to remove the o.a.s.u classes in a future version.

(3) Modify the  initialization element to allow
the selection and configuration of an appropriate
ResourcesFactory from commons-resources, wrapped by a Messages
instance.  This is primarily a change in the interpretation of
the "factory" attribute, and should not affect anyone that uses
the current default.

(4) Modify all internal uses (including in tag libraries) of
org.apache.struts.util.MessageResources to use
org.apache.commons.resources.Messages instead.  This will be
transparent to users that use the standard implementations, but
will require folks who have subclassed the MessageResources
classes to migrate their code as well.

What do you think?  Should we go ahead and do this migration?  Is the
commons-resources package as it stands now as complete and functional as
it needs to be (obviously, it'll need to be promoted to a standard Commons
package and released so we can rely on it, which will require a couple of
volunteers willing to help me maintain it).  Should we do the entire
migration outlined above, or maybe only part of it?

Thoughts, please.

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





--
Ted Husted,
Struts in Action 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Validator and multiple message resources

[franco . caponi]

I have see that arg* tag on validator descriptors TLD did not support the
bundle property but only the key property... it is correct or i have old
descriptors?

If true, this feature will be included in Struts 1.1?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Proposal] Migrate to Dependency on commons-resources

[Craig R. McClanahan]

On Mon, 13 Jan 2003, David Graham wrote:

> Date: Mon, 13 Jan 2003 07:52:52 -0700
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [Proposal] Migrate to Dependency on commons-resources
>
> Are there any backwards compatibility problems here?  Because the Struts
> classes use protected MessageResources members they are exposed to classes
> extending the framework.  It seems that changing these to Messages objects
> would break existing extensions.
>

Whether it would actually break depends on whether the subclass itself
explicitly imported org.apache.struts.util.MessageResources or not.  If
not (in other words, you just used the "messages" static variable of the
base class and called getMessage() on it, then a recompile should be
sufficient -- the variable name and method signatures were deliberately
designed to be compatible.

> Dave

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Proposal] Migrate to Dependency on commons-resources

[Craig R. McClanahan]

On Mon, 13 Jan 2003, PILGRIM, Peter, FM wrote:

> The ResourceFactory implementation. Would it affect how the messages are
> retrieved?

Yes, since it is the Resources implementation that actually does the
retrieval :-).

> For example if you have a merged resources that does the
> following
>
> DBResources
>   (1) Boot strap read properties from a flat file
>   (2) Reads some JDBC properties from (1) if any uses them
>   open a connection to data database.
>   (2a) Read properties from database, these overwrite any
>   flat file properties.
>   (3) Repeat for any extra databases.
>
> Presumably one would need to write a new `ResourceFactory' implementation
> and that would be it. Thought?
>

Yes, one could do a customized ResourcesFactory/Resources pair that did
just this.  In principle, anyone who subclassed or specialized the
existing o.a.s.u.MessageResources stuff would probably have to reimplement
based on commons-resources again.

> --
> Peter Pilgrim,

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Requested modification of InsertTag.java

[Jay]

Requested modification of tiles/InsertTag.java 

I appreciate your ExceptionHandler concept and use it for capturing
critical errors, thoroughly logging both error and context information
and forwarding to a special web page that displays very concise
information about the error (error reference number, etc)  However, for
completeness sake, I wish to capture any serious errors that occur in
the "forwarding" phase beyond action handling processing, where,
particularly using "tiles", one or more JSP servlets are run. 

I found a solution that seemed straightforward.  Since I already 
sub-classed TilesRequestProcessor to override one of the other "process"
methods, I simply overrode processActionForward, wrapped the call to the
super class in a try/catch block, and forwarded accordingly if an
exception is thrown.  Below shows the pertinent portions of the
override: 

   
protected void processActionForward(HttpServletRequest request, 
HttpServletResponse response, 
ActionForward forward) 
throws IOException, ServletException { 

try { 
super.processActionForward(request,response,forward); 
} 
catch (Throwable ex) {  
// Log information, etc 
ActionForward errorForward; 
// Fetch special forwarding for critical errors. 
. 
. 
.   . 
   
super.processActionForward(request,response,errorForward); 
 } 
} 


The "snag" I ran into was tiles/InsertTag.  The normal behavior of the 
class is to broadcast the error message on the web page and "carry on." 
Specifically, from the inner protected class
InsertHandler::processException(): 

protected void processException(Throwable ex, String msg) throws
JspException { 
. 
. 
. 
. 
} else { // show only message 
   
pageContext.getOut().println(msg); 
} // end if 


Could you kindly consider moving the real processing of 
processException() to a method inside InsertTag itself so that users may
easily sub-class to override the "broadcasting" behavior?  In other
words, could you do something like: 

protected class InsertHandler { 
. 
. 
protected void processException(Throwable ex.msg,String
msg)  throws 
JspException 
{ 
processTilesException(ex,msg); 
} 

} 


/** Real work done here 
 */ 
protected void processTilesException(Throwable ex, String msg)
throws 
JspException { 
. 
. 
. 
} 

I would be greatly appreciative if you consider this very minor change. 

Thank you, 
Jay 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Proposal] Migrate to Dependency on commons-resources

[David Graham]

Are there any backwards compatibility problems here?  Because the Struts 
classes use protected MessageResources members they are exposed to classes 
extending the framework.  It seems that changing these to Messages objects 
would break existing extensions.

Dave






From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Proposal] Migrate to Dependency on commons-resources
Date: Sun, 12 Jan 2003 18:34:12 -0800 (PST)

As we've discussed a couple of times, the last major functionality change
we had discussed for Struts 1.1 was to migrate to dependence on
commons-resources, rather than the proprietary message resource facilities
inside og.apache.struts.util.  As you might recall, Michael Schacter took
a first crack at factoring out the Struts resources classes out to create
this commons package, which is currently in the sandbox.

I've recently gone through it, and did a major refactoring of
commons-resources, to the point where I'm now ready to propose that we
modify Struts to depend on it.  I'd like the other committers to evaluate
the current state of commons-resources, and my proposed integration plan
below, to see what they think of this idea.

The nightly build of commons-resources.jar included in recent Struts
nightly builds is the code that I'm proposing.  You can see the Javadocs
for this code at:

  http://jakarta.apache.org/commons/resources/api/

and get the sources via either CVS (from jakarta-commons-sandbox) or
nightly snapshots:

  
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/

In terms of Struts integration, I propose:

(1) Most Struts classes declare a static MessageResources instance
for the messages unique to that Struts package.  For example,
org.apache.struts.taglib.bean.CookieTag has this:

protected static MessageResources messages =
  MessageResources.getMessageResources
  ("org.apache.struts.taglib.bean.LocalStrings");

This would be migrated to the new Messages class from 
commons-resources:

protected static Messages messages =
  Messages.getMessages("org.apache.struts.taglib.bean");

The calls to actually retrieve message strings are compatible with
the existing code, as well as the properties files used to acquire
the message strings, so no other changes should be required.

(2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
around equivalent functionality from commons-resources (much like
GenericDataSource now wraps commons-dbcp), and deprecate them.
This protects existing apps that are customizing these APIs,
but allows us to remove the o.a.s.u classes in a future version.

(3) Modify the  initialization element to allow
the selection and configuration of an appropriate
ResourcesFactory from commons-resources, wrapped by a Messages
instance.  This is primarily a change in the interpretation of
the "factory" attribute, and should not affect anyone that uses
the current default.

(4) Modify all internal uses (including in tag libraries) of
org.apache.struts.util.MessageResources to use
org.apache.commons.resources.Messages instead.  This will be
transparent to users that use the standard implementations, but
will require folks who have subclassed the MessageResources
classes to migrate their code as well.

What do you think?  Should we go ahead and do this migration?  Is the
commons-resources package as it stands now as complete and functional as
it needs to be (obviously, it'll need to be promoted to a standard Commons
package and released so we can rely on it, which will require a couple of
volunteers willing to help me maintain it).  Should we do the entire
migration outlined above, or maybe only part of it?

Thoughts, please.

Craig



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
MSN 8: advanced junk mail protection and 2 months FREE*. 
http://join.msn.com/?page=features/junkmail


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Passing parameters with mapping.findforward

[Nelson, Laird]

> -Original Message-
> From: Rajendra Yadav [mailto:[EMAIL PROTECTED]]
> How do we pass parameters from one jsp to another using the 
> Struts framework.

Nothing to do with Struts.  See the Servlet API.

http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletRequest.h
tml#setAttribute(java.lang.String, java.lang.Object)

HTH,
Laird

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Passing parameters with mapping.findforward

[Rajendra Yadav]

Hi All,

How do we pass parameters from one jsp to another using the Struts framework. By using 
the mapping.findForward(""), we only redirect it to a particular jsp but I am not able 
to see how to pass parameters.

Thanks for the help.

- Raj



-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

DO NOT REPLY [Bug 16019] - LookupDispatchAction multiple MessageResources

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16019

LookupDispatchAction multiple MessageResources





--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 12:43 ---
Created an attachment (id=4404)
diff -u

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16019] - LookupDispatchAction multiple MessageResources

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16019

LookupDispatchAction multiple MessageResources

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 12:43 ---
Couple of things:

If you close the bug, then noone will commit this (because we will think it was
already done)

We cannot easily apply patches when just send us the entire .java file.
We need to see the output from "cvs diff -u filename.java".  This helps
determine if your changes are compatible with the current code.  Otherwise it
might overwrite several iterations of changes because someone might be using an
old copy of the code.

I've taken your code and created the proper "diff -u".

If someone wants to commit this, feel free, but I have not validated this fix.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Proposal] Migrate to Dependency on commons-resources

[James Mitchell]

> The ResourceFactory implementation. Would it affect how the 
> messages are retrieved? For example if you have a merged 
> resources that does the following
> 
> DBResources  
>   (1) Boot strap read properties from a flat file
>   (2) Reads some JDBC properties from (1) if any uses them
>   open a connection to data database.
>   (2a) Read properties from database, these overwrite any
>   flat file properties.
>   (3) Repeat for any extra databases.
>  
> Presumably one would need to write a new `ResourceFactory' 
> implementation
> and that would be it. Thought?
> 
> --
> Peter Pilgrim,


This would be a customization beyond the current implementation or with
the newly proposed API.  That said, everything you've stated is
definitely possible with either implementation.  I've done a database
implementation myself and I'm currently working to integrate this into
the new API.


--
James Mitchell



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16019] - LookupDispatchAction multiple MessageResources

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16019

LookupDispatchAction multiple MessageResources

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Priority|Other   |High
 Resolution||FIXED

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16019] - LookupDispatchAction multiple MessageResources

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16019

LookupDispatchAction multiple MessageResources





--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 12:22 ---
Created an attachment (id=4403)
Modified source code which fixes this problem/bug

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16019] New: - LookupDispatchAction multiple MessageResources

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16019

LookupDispatchAction multiple MessageResources

   Summary: LookupDispatchAction multiple MessageResources
   Product: Struts
   Version: 1.1 Beta 2
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Standard Actions
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The current LookupDispatchAction in Beta 2 of Struts 1.1 doesn't support the 
use of multiple MessageResources defined in the struts-config.xml file.  I 
haven't been able to check if this problem has been fixed in Beta 3 as the 
source code wasn't available for this new beta version when I encountered this 
problem.  The LookupDispatchAction always asumes that there is only one default 
MessageResources defined under Action.MESSAGES_KEY.  The error occurs when you 
want to use submit buttons which are labelled with a message property which 
isn't defined under the default key named Action.MESSAGES_KEY but that is 
defined under another key defined by the user in the struts-config.xml.  There 
you can assign an own key with the bundle argument of the message-resources.  A 
possible solution is to iterate through all the defined message-resources.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Proposal] Migrate to Dependency on commons-resources

[PILGRIM, Peter, FM]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> 
> As we've discussed a couple of times, the last major 
> functionality change
> we had discussed for Struts 1.1 was to migrate to dependence on
> commons-resources, rather than the proprietary message 
> resource facilities
> inside og.apache.struts.util.  As you might recall, Michael 
> Schacter took
> a first crack at factoring out the Struts resources classes 
> out to create
> this commons package, which is currently in the sandbox.
> 
> I've recently gone through it, and did a major refactoring of
> commons-resources, to the point where I'm now ready to propose that we
> modify Struts to depend on it.  I'd like the other committers 
> to evaluate
> the current state of commons-resources, and my proposed 
> integration plan
> below, to see what they think of this idea.
> 
> The nightly build of commons-resources.jar included in recent Struts
> nightly builds is the code that I'm proposing.  You can see 
> the Javadocs
> for this code at:
> 
>   http://jakarta.apache.org/commons/resources/api/
> 
> and get the sources via either CVS (from jakarta-commons-sandbox) or
> nightly snapshots:
> 
>   
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/

In terms of Struts integration, I propose:

(1) Most Struts classes declare a static MessageResources instance
for the messages unique to that Struts package.  For example,
org.apache.struts.taglib.bean.CookieTag has this:

protected static MessageResources messages =
  MessageResources.getMessageResources
  ("org.apache.struts.taglib.bean.LocalStrings");

This would be migrated to the new Messages class from commons-resources:

protected static Messages messages =
  Messages.getMessages("org.apache.struts.taglib.bean");

The calls to actually retrieve message strings are compatible with
the existing code, as well as the properties files used to acquire
the message strings, so no other changes should be required.

(2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
around equivalent functionality from commons-resources (much like
GenericDataSource now wraps commons-dbcp), and deprecate them.
This protects existing apps that are customizing these APIs,
but allows us to remove the o.a.s.u classes in a future version.

(3) Modify the  initialization element to allow
the selection and configuration of an appropriate
ResourcesFactory from commons-resources, wrapped by a Messages
instance.  This is primarily a change in the interpretation of
the "factory" attribute, and should not affect anyone that uses
the current default.

(4) Modify all internal uses (including in tag libraries) of
org.apache.struts.util.MessageResources to use
org.apache.commons.resources.Messages instead.  This will be
transparent to users that use the standard implementations, but
will require folks who have subclassed the MessageResources
classes to migrate their code as well.

What do you think?  Should we go ahead and do this migration?  Is the
commons-resources package as it stands now as complete and functional as
it needs to be (obviously, it'll need to be promoted to a standard Commons
package and released so we can rely on it, which will require a couple of
volunteers willing to help me maintain it).  Should we do the entire
migration outlined above, or maybe only part of it?

Thoughts, please.

Craig
--

The ResourceFactory implementation. Would it affect how the messages are
retrieved? For example if you have a merged resources that does the
following

DBResources  
(1) Boot strap read properties from a flat file
(2) Reads some JDBC properties from (1) if any uses them
open a connection to data database.
(2a) Read properties from database, these overwrite any
flat file properties.
(3) Repeat for any extra databases.
 
Presumably one would need to write a new `ResourceFactory' implementation
and that would be it. Thought?

--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-5642


***
  Visit our Internet site at http://www.rbsmarkets.com

This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB 
Regulated by the Financial Services Authority
***

--
To unsubscribe, e-mail: