You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Eddie Bush <ek...@swbell.net> on 2002/07/26 01:45:33 UTC

Initialization Question

At what point are resources (ie property files) loaded?  Is it before or 
after data-source intialization?
At what point are data-sources initialized?  Is it before or after plug-ins?
How would a plugin grab ahold of the data-source, assuming one uses the 
default key for the data-source?

... I think that's all my questions :-)

Thanks,

Eddie



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Initialization Question

Posted by Eddie Bush <ek...@swbell.net>.

Eddie Bush wrote:

> Craig R. McClanahan wrote:
>
>>
>> On Thu, 25 Jul 2002, Eddie Bush wrote:
>>
>> Creating properties files at startup time isn't the most useful approach
>> -- especially because the app server's class loader won't recognize
>> dynamic additions after the app has started.  Plus the little fact that
>> there is no place to *put* the little buggers if your app is running
>> directly from a WAR file.
>
> You over-guessed my aim :-)  I was just trying to get a feel for how 
> plausible it would be to build a plugin that would enable this behavior. 

and my intent was to have the plug-in actually hit the database ;-)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Initialization Question

Posted by Eddie Bush <ed...@vestus.adabbs.com>.
Craig R. McClanahan wrote:

>
>On Thu, 25 Jul 2002, Eddie Bush wrote:
>
>>At what point are resources (ie property files) loaded?  Is it before or
>>after data-source intialization?
>>At what point are data-sources initialized?  Is it before or after plug-ins?
>>How would a plugin grab ahold of the data-source, assuming one uses the
>>default key for the data-source?
>>
>
>Creating properties files at startup time isn't the most useful approach
>-- especially because the app server's class loader won't recognize
>dynamic additions after the app has started.  Plus the little fact that
>there is no place to *put* the little buggers if your app is running
>directly from a WAR file.
>
You over-guessed my aim :-)  I was just trying to get a feel for how 
plausible it would be to build a plugin that would enable this behavior.

>The right answer is to remember that
>org.apache.struts.util.MessageResources is an abstract class.  You can
>define your own implementation of this class (and configure it with the
>"application" init parameter (Struts 1.0) or in the <message-resources>
>element (Struts 1.1).
>
I hadn't thought of that :-)  Admittedly, while I'm becoming quite 
comfortable with the more advanced uses of Struts, I lack a lot of 
understanding of it's "guts".

>PropertyMessageResources, which reads property files, is just one possible
>implementation.
>
;-) I understand.

>NOTE:  Someone took a crack at abstracting the message resources stuff out
>of STruts and into a jakarta-commons-sandbox project called "resources",
>like we've extracted other useful things that are not (by themselves)
>Struts dependent.  It would be cool if someone wanted to finish that work,
>including an implementation that reads XML files and an implementation
>that loads resources from a database.
>
I don't know that I could, at this point, abstract out the MRes stuff. 
 I would be interested in helping build up some utility behavior that 
would allow this to be selected in the config file though - ie. prop 
file/XML config/DB.  Maybe once I've done that I'll feel comfortable 
enough with "things" to go ripping and snorting.  My XML is awful shaky 
though - but I may very well look into building a DB implementation.

>>... I think that's all my questions :-)
>>
>>Thanks,
>>
>>Eddie
>>
>
>Craig
>
Thanks, Craig.  I always enjoy your insight, as it seems you have a much 
broader, generalized view of things than do I.  I may well tinker around 
a bit with the MsgRes stuff.  Thanks again for your view :-)

Eddie


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Initialization Question

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Thu, 25 Jul 2002, Eddie Bush wrote:

> Date: Thu, 25 Jul 2002 18:45:33 -0500
> From: Eddie Bush <ek...@swbell.net>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users List <st...@jakarta.apache.org>
> Subject: Initialization Question
>
> At what point are resources (ie property files) loaded?  Is it before or
> after data-source intialization?
> At what point are data-sources initialized?  Is it before or after plug-ins?
> How would a plugin grab ahold of the data-source, assuming one uses the
> default key for the data-source?
>

Creating properties files at startup time isn't the most useful approach
-- especially because the app server's class loader won't recognize
dynamic additions after the app has started.  Plus the little fact that
there is no place to *put* the little buggers if your app is running
directly from a WAR file.

The right answer is to remember that
org.apache.struts.util.MessageResources is an abstract class.  You can
define your own implementation of this class (and configure it with the
"application" init parameter (Struts 1.0) or in the <message-resources>
element (Struts 1.1).

PropertyMessageResources, which reads property files, is just one possible
implementation.

NOTE:  Someone took a crack at abstracting the message resources stuff out
of STruts and into a jakarta-commons-sandbox project called "resources",
like we've extracted other useful things that are not (by themselves)
Struts dependent.  It would be cool if someone wanted to finish that work,
including an implementation that reads XML files and an implementation
that loads resources from a database.

> ... I think that's all my questions :-)
>
> Thanks,
>
> Eddie
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>