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:[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
