You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Koon Yue Lam <ki...@gmail.com> on 2004/07/22 04:42:28 UTC
About Struts + JBoss preference issue
Hi ! My application has change from Struts + Tomcat to Struts + Jboss 3.X
I create various struts Actions to deal with incoming request, in the
Action class, it preform remote lookup of session bean's home
interface and create, destory ... it.
My session bean has an DAO attach to it to preform database related stuffs
NO entiy beans in my application since transaction is not a problem
and most DB query are read only
The question is the speed, it is much slower when I request an Action
instead of directly request a servlet. Is it normal ? I don't mind a
little bit preformance tradeoff but I want to know the delay is caused
by Struts or something else.
Any help?
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by Vic Cekvenich <ce...@portalvu.com>.
Because Struts is a layered application, you can stress test the
performance of your data layer by itself. If the DAO is slow, or the SQL
is slow, then Struts can't serve it fast.
So, test the performance of DAO layer.
.V
Koon Yue Lam wrote:
> Hi ! My application has change from Struts + Tomcat to Struts + Jboss 3.X
>
> I create various struts Actions to deal with incoming request, in the
> Action class, it preform remote lookup of session bean's home
> interface and create, destory ... it.
>
> My session bean has an DAO attach to it to preform database related stuffs
> NO entiy beans in my application since transaction is not a problem
> and most DB query are read only
>
> The question is the speed, it is much slower when I request an Action
> instead of directly request a servlet. Is it normal ? I don't mind a
> little bit preformance tradeoff but I want to know the delay is caused
> by Struts or something else.
>
> Any help?
>
> Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by HG <st...@nospam.websolver.dk>.
> isn't that in a cluster the app server 'replicates' the JNDI tree, so
> that u won't have to bother if one of the servers in a cluster shuts
> down?
Se my other post. I think it's up to the J2EE Server to provide "cluster
transparacy" to the clients.
> I m no expert in cluster, and I was wandering what happens if u cache
> The Remote object, If someone can explain..
Me neither....Anyone? Please?
Regards
Henrik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: About Struts + JBoss preference issue
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello,
>2. If the application scale up to cluster, this design seems can't deal
>with it
>(because the client always invoke remote object that was downloaded to
>cache, which is not dynamically locate by app. server in a cluster
>environment.)
isn't that in a cluster the app server 'replicates' the JNDI tree, so
that u won't have to bother if one of the servers in a cluster shuts
down?
I m no expert in cluster, and I was wandering what happens if u cache
The Remote object, If someone can explain..
Regards
marco
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by HG <st...@nospam.websolver.dk>.
Hi
> 2. If the application scale up to cluster, this design seems can't deal
with it
> (because the client always invoke remote object that was downloaded to
> cache, which is not dynamically locate by app. server in a cluster
> environment.)
Is this really an issue? Maybe I do not understand you correctly.
Is this the scenario you are thinking of:
When plugin is initialized it uses J2EE Server A to get the remote object.
Meantime J2EE Server A breaks down. Do you mean that remote object would not
be accessible anylonger?
I do not think this is an issue. It mmust be up to the J2EE Server to "hide"
clustering from the clients (here the plugin class)
I can see an issue in clustering though..The J2EE server must be able to
share/distribute ServletContexts across clusters...but isn't that a part of
the J2EE specs?
Any thoughts...also from others...
Regards
Henrik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by Koon Yue Lam <ki...@gmail.com>.
some drawbacks I can see:
1. longer server start up time (but it is OK)
2. If the application scale up to cluster, this design seems can't deal with it
(because the client always invoke remote object that was downloaded to
cache, which is not dynamically locate by app. server in a cluster
environment.)
however if it is a single JVM application (like mine, ^^), I will
consider it a try
thanks for help
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by HG <st...@nospam.websolver.dk>.
Hi Marco
> right, so I assume every Action class that u write subclasses
> PlugInManagerAction, correct?
Correct
> I don't like putting parenthesis :-) coz everything that I get
> From ServletContext is an object....
>
> It doesn't bother me much.. but I m still wandering if I can add
> Let's say 10 plugIns to my app, and have a common interface so that
> I can just retrieve them by name without typecast....
Well you *could* let your PluginManager handle the casting but...
Check out the Service Locator pattern at http://java.sun.com
I think the have an example "type-safe" implementation.
> I haven't done it and probably I won't need It much....but I m still
> Thinking... :-)
Always nice to do some thinking.. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: About Struts + JBoss preference issue
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello,
>But it could easily be a XML file, or anything else
yes...personally I would 4 that unless u have particular
requirements for storing it into the DB
>> U use the PlugInMgr as singleton, correct? Coz right now I m
following
>> Similar 'approach' but I m storing the BD in the ServletContext, and
>> what
>> I don't like much is that every time I have to retrieve it, I have to
>> Do a cast....
>The plugin manager is stored in ServletContext, and I have a base class
>(PluginManagerAction) for my action, which have a method with the
following
>signature
right, so I assume every Action class that u write subclasses
PlugInManagerAction, correct?
>public PluginManager getPluginManager();
>In my action which derives from PluginManagerAction I do this:
>MyPluginInterface plugin = (MyPluginInterface)
>getPluginManager().getPlugin("myplugin");
>I have to type cast the interface because getPluginManager() return the
>superclass interface Plugin
>What is it you don't like, when doing type casts...?
I don't like putting parenthesis :-) coz everything that I get
>From ServletContext is an object....
It doesn't bother me much.. but I m still wandering if I can add
Let's say 10 plugIns to my app, and have a common interface so that
I can just retrieve them by name without typecast....
I haven't done it and probably I won't need It much....but I m still
Thinking... :-)
Regards
Henrik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by HG <st...@nospam.websolver.dk>.
Hi Robert
> This approach sounds similar to the Spring IoC framework.
> Objects are defined in an xml file and a manager loads them
> into memory. Your action class looks up beans using something
> like:
> MyBD bd = (MyBD)applicationContext.getBean("MyBD");
I wasn't aware of that. I have seen so many good comments (on various sites)
on the Spring framework lately.. I'd better go and check it out.
Thanx for your input..
Regards
Henrik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: About Struts + JBoss preference issue
Posted by Robert Taylor <rt...@mulework.com>.
This approach sounds similar to the Spring IoC framework.
Objects are defined in an xml file and a manager loads them
into memory. Your action class looks up beans using something
like:
MyBD bd = (MyBD)applicationContext.getBean("MyBD");
So you don't have to implement the ServiceLocator or
Singleton patterns.
It provides declarative transaction services as well.
Check it out here:
http://www.springframework.org/
robert
> -----Original Message-----
> From: HG [mailto:struts@nospam.websolver.dk]
> Sent: Thursday, July 22, 2004 5:22 AM
> To: Struts Users Mailing List
> Subject: Re: About Struts + JBoss preference issue
>
>
> Hi Marco
>
> > I have questions coz I m interested in that approach..
>
> I am happy that you find it interesting :-)
>
> > I assume u have a config file for telling the PlugIn Mgr what
> > To load, correct?
>
> The plugins, names and classed that implement the plugin interface are
> stored in a table in a database.
> When the pluginmanager initializes, it performs a query on the database,
> fetching the plugins to load.
>
> Then the PluginManager iterates the found plugin and performs this sequence
> in each interation
>
> - Load the class (implementing the plugin interface) and get an instance of
> it.
> - initialize the plugin (performing lookup of remote home through
> ServiceLocator and creating remote object (Facade) to associate with the
> plugin.
>
> But it could easily be a XML file, or anything else
>
> > U use the PlugInMgr as singleton, correct? Coz right now I m following
> > Similar 'approach' but I m storing the BD in the ServletContext, and
> > what
> > I don't like much is that every time I have to retrieve it, I have to
> > Do a cast....
>
> The plugin manager is stored in ServletContext, and I have a base class
> (PluginManagerAction) for my action, which have a method with the following
> signature
>
> public PluginManager getPluginManager();
>
> In my action which derives from PluginManagerAction I do this:
>
> MyPluginInterface plugin = (MyPluginInterface)
> getPluginManager().getPlugin("myplugin");
>
> I have to type cast the interface because getPluginManager() return the
> superclass interface Plugin
>
> No I am ready to invoke methods of the plugin.
>
> What is it you don't like, when doing type casts...?
>
> Regards
>
> Henrik
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by HG <st...@nospam.websolver.dk>.
Hi Marco
> I have questions coz I m interested in that approach..
I am happy that you find it interesting :-)
> I assume u have a config file for telling the PlugIn Mgr what
> To load, correct?
The plugins, names and classed that implement the plugin interface are
stored in a table in a database.
When the pluginmanager initializes, it performs a query on the database,
fetching the plugins to load.
Then the PluginManager iterates the found plugin and performs this sequence
in each interation
- Load the class (implementing the plugin interface) and get an instance of
it.
- initialize the plugin (performing lookup of remote home through
ServiceLocator and creating remote object (Facade) to associate with the
plugin.
But it could easily be a XML file, or anything else
> U use the PlugInMgr as singleton, correct? Coz right now I m following
> Similar 'approach' but I m storing the BD in the ServletContext, and
> what
> I don't like much is that every time I have to retrieve it, I have to
> Do a cast....
The plugin manager is stored in ServletContext, and I have a base class
(PluginManagerAction) for my action, which have a method with the following
signature
public PluginManager getPluginManager();
In my action which derives from PluginManagerAction I do this:
MyPluginInterface plugin = (MyPluginInterface)
getPluginManager().getPlugin("myplugin");
I have to type cast the interface because getPluginManager() return the
superclass interface Plugin
No I am ready to invoke methods of the plugin.
What is it you don't like, when doing type casts...?
Regards
Henrik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: About Struts + JBoss preference issue
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello,
I have questions coz I m interested in that approach..
I assume u have a config file for telling the PlugIn Mgr what
To load, correct?
U use the PlugInMgr as singleton, correct? Coz right now I m following
Similar 'approach' but I m storing the BD in the ServletContext, and
what
I don't like much is that every time I have to retrieve it, I have to
Do a cast....
Regards
marco
-----Original Message-----
From: HG [mailto:struts@websolver.dk]
Sent: 22 July 2004 09:26
To: Struts Users Mailing List
Subject: Re: About Struts + JBoss preference issue
Glad to help.
I even optimized this further down the road, but it depends on your
application if you can do that.
I used the BusinessDelegate pattern to employ the concept of a
BusinessPlugin. That is an interface to the EJB Session Facade, but
implemented as a POJO. There's a one-to-one relationsship (don't have to
be
so, but it is now) between BusinessPlugin and EJB Facade. The business
plugin only exists once, and is also put in a cache for faster
retrieval,
just like the homes. This cache is called the PluginManager and is
populated
by a Struts plugin, after the homes a cached.
So it looks like this on startup:
- Cache homes (like I wrote in the other post)
- Create BusinessPlugin instances and assign the "remote object" (the
one
created by remoteHome.create()) to the BusinessPlugin instance.
- Cache business plugin
In practive this not only caches homes, but also caches the remote
objects
created by the home (in each business plugin)
And the "call stack" on invoking an action looks like this
// In the plugin you now have a "web tier" interface to you EJB Facade,
al
instantiated and ready to use.
MyPluginInterface plugin = (MyPluginInterface)
PluginManager.getPlugin("myPlugin");
// myBusinessMethod() delagates the call to the associated remote object
(EJB Facade)
plugin.myBusinessMethod();
I have not found any drawbacks to this approach, and it saves you a
whole
lot of cluttering in your action class.
You might wonder when the EJB remove() method is called?
The Struts plugin that populates the PluginManager (thereby
instantiating
remote objects from their homes), also "depopulate" the PluginManager in
the
destroy() method, which is (hopefully) called when the server shuts
down...
Is there anyone else who can see pitfalls to this approach..?
Regards
Henrik
----- Original Message -----
From: "Koon Yue Lam" <ki...@gmail.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Thursday, July 22, 2004 9:31 AM
Subject: Re: About Struts + JBoss preference issue
> Thanks !
> It seems like a great solution and I will try that out tonight, thanks
> for help ^^
>
> Regards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by HG <st...@nospam.websolver.dk>.
Glad to help.
I even optimized this further down the road, but it depends on your
application if you can do that.
I used the BusinessDelegate pattern to employ the concept of a
BusinessPlugin. That is an interface to the EJB Session Facade, but
implemented as a POJO. There's a one-to-one relationsship (don't have to be
so, but it is now) between BusinessPlugin and EJB Facade. The business
plugin only exists once, and is also put in a cache for faster retrieval,
just like the homes. This cache is called the PluginManager and is populated
by a Struts plugin, after the homes a cached.
So it looks like this on startup:
- Cache homes (like I wrote in the other post)
- Create BusinessPlugin instances and assign the "remote object" (the one
created by remoteHome.create()) to the BusinessPlugin instance.
- Cache business plugin
In practive this not only caches homes, but also caches the remote objects
created by the home (in each business plugin)
And the "call stack" on invoking an action looks like this
// In the plugin you now have a "web tier" interface to you EJB Facade, al
instantiated and ready to use.
MyPluginInterface plugin = (MyPluginInterface)
PluginManager.getPlugin("myPlugin");
// myBusinessMethod() delagates the call to the associated remote object
(EJB Facade)
plugin.myBusinessMethod();
I have not found any drawbacks to this approach, and it saves you a whole
lot of cluttering in your action class.
You might wonder when the EJB remove() method is called?
The Struts plugin that populates the PluginManager (thereby instantiating
remote objects from their homes), also "depopulate" the PluginManager in the
destroy() method, which is (hopefully) called when the server shuts down...
Is there anyone else who can see pitfalls to this approach..?
Regards
Henrik
----- Original Message -----
From: "Koon Yue Lam" <ki...@gmail.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Thursday, July 22, 2004 9:31 AM
Subject: Re: About Struts + JBoss preference issue
> Thanks !
> It seems like a great solution and I will try that out tonight, thanks
> for help ^^
>
> Regards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by Koon Yue Lam <ki...@gmail.com>.
Thanks !
It seems like a great solution and I will try that out tonight, thanks
for help ^^
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem setting intial value of checkbox to check
Posted by Erik Weber <er...@mindspring.com>.
I tried my advice and it worked.
In my reset method, I normally set my checkbox form bean attributes to
"false". I changed one to "true" and the checkbox now comes up checked
by default.
Hope that helps,
Erik
Erik Weber wrote:
> I think setting the value to "true" just means that "true" is what
> will be sent to the server if the checkbox is checked when the form
> submits.
>
> I *think* you would "turn on" the checkbox in the reset method of your
> form bean, if I am not mistaken . . .
>
> Not 100% sure,
>
> Erik
>
>
>
> Joe Argiro wrote:
>
>> Hi
>> we're migrating our code to 1.1
>> I've got a problem with the html:checkbox. (which used to work in
>> 1.02 )
>>
>> <html:checkbox property="displayInfo" value="true"/>
>>
>> I need to set the initial value to "checked" but it no longer seems
>> to work in 1.1
>> what is the correct way to do this now
>>
>>
>>
>> thanks!
>> --joe
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Problem setting intial value of checkbox to check
Posted by Erik Weber <er...@mindspring.com>.
I think setting the value to "true" just means that "true" is what will
be sent to the server if the checkbox is checked when the form submits.
I *think* you would "turn on" the checkbox in the reset method of your
form bean, if I am not mistaken . . .
Not 100% sure,
Erik
Joe Argiro wrote:
> Hi
> we're migrating our code to 1.1
> I've got a problem with the html:checkbox. (which used to work in 1.02 )
>
> <html:checkbox property="displayInfo" value="true"/>
>
> I need to set the initial value to "checked" but it no longer seems
> to work in 1.1
> what is the correct way to do this now
>
>
>
> thanks!
> --joe
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Problem setting intial value of checkbox to check
Posted by Joe Argiro <ja...@idtTechnology.com>.
Hi
we're migrating our code to 1.1
I've got a problem with the html:checkbox. (which used to work in 1.02 )
<html:checkbox property="displayInfo" value="true"/>
I need to set the initial value to "checked" but it no longer seems to
work in 1.1
what is the correct way to do this now
thanks!
--joe
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: About Struts + JBoss preference issue
Posted by HG <st...@nospam.websolver.dk>.
Hi there
Now, it shouldn't be much slower. However, there is a performance tradeoff
when using EJB, specially remote ones like you do.
One thing, that really speeds up things is to cache the home interface, when
looking it up, or when the applications starts up.
First use will still be slow, but subsequent uses should be much faster.
I use this approach:
Have a Struts plugin lookup home interfaces, assign a unique name to each
home interface (I am using an int constant) and initialize a Singleton cache
with all homes regisistered with the unique name.
By doing this your homes are ready to use in your action, but it takes a
little longer to deploy/start the application.
A pseudo code for an action might look like this:
MyRemoteHome home = HomeCache.get(HomeCache.MY_HOME_CONSTANT);
MyRemoteObject obj = home.create();
obj.doMyRemoteMethod();
obj.remove();
Hope this is understandable and helps..
Regards
Henrik
----- Original Message -----
From: "Koon Yue Lam" <ki...@gmail.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Thursday, July 22, 2004 4:42 AM
Subject: About Struts + JBoss preference issue
> Hi ! My application has change from Struts + Tomcat to Struts + Jboss 3.X
>
> I create various struts Actions to deal with incoming request, in the
> Action class, it preform remote lookup of session bean's home
> interface and create, destory ... it.
>
> My session bean has an DAO attach to it to preform database related stuffs
> NO entiy beans in my application since transaction is not a problem
> and most DB query are read only
>
> The question is the speed, it is much slower when I request an Action
> instead of directly request a servlet. Is it normal ? I don't mind a
> little bit preformance tradeoff but I want to know the delay is caused
> by Struts or something else.
>
> Any help?
>
> Regards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org