You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Inamdar, Anil - Cons" <ai...@iso-ne.com> on 2004/04/29 20:05:44 UTC
Way to reload struts Action classes in WebLogic8.1
Hello,
Is there a way to reload Actions in Weblogic without redeploying the web
application.
I have the servlet reloading enabled , but weblogic doesnt seem to recognize
the changes to the Action classes and throws a ClassCastException.
So every small change I make, I have to redeploy the Web app which makes the
whole development process slow.
thanks
Anil
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Isn't the trick to load the classes with a classloader that does not
require you to reload the entire webapp? This is a combination question
and statement. I am interested in this issue and want to find a way to
load classes in a webapp which will be workable. I am thinking of the
stuff that has been discussed in books on container programming in Java.
At 10:15 PM 5/1/2004, Craig R. McClanahan wrote:
>Inamdar, Anil - Cons wrote:
>
>>Hello,
>>Is there a way to reload Actions in Weblogic without redeploying the web
>>application.
>No. Java provides no way to replace a class (loaded by a particular class
>loader) with a modified version, without throwing away the entire class
>loader. That's what normally happens when you reload a webapp.
>
>>I have the servlet reloading enabled , but weblogic doesnt seem to recognize
>>the changes to the Action classes and throws a ClassCastException.
>>So every small change I make, I have to redeploy the Web app which makes the
>>whole development process slow.
>I don't know about Weblogic, but Sun's app servers (and Tomcat) have
>"reload" options that are *much* faster than the undeploy/redeploy cycle
>it sounds like you are using. Check the docs.
>
>>thanks
>>Anil
>>
>Craig
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Thanks for sharing that, Pedro. I think it is good stuff too.
At 05:16 PM 5/2/2004, Pedro Salgado wrote:
>On 04/05/02 23:50, "Michael McGrady" <mi...@michaelmcgrady.com> wrote:
>
> > This is more of a passing interest of mine, so I will pursue a bit more, if
> > you continue an interest. I have an application that needs to do this from
> > afar on multiple and untrackable sites. So, the bouncing the server idea
> > just won't work for me. I need this to happen without exchanging
> > classloaders, and probably without fiddling with the classloader API. So,
> > this is my thought: that you have multiple dependencies is not important so
> > long as they all obey the "pattern" we were discussing, i.e., 1., 2., and
> > 3. So, any application framework that provided reloading only to the
> > requisite classes, those that followed this "pattern" would not be
> > "half-assed" at all but would be fully workable. One might even use a tag
> > interface, e.g.
> > Reloadable, to identify which classes had this sort of
> > independence. If all classes were created and were loaded on this sort of
> > structure, there would never be a need to bounce servers, etc. That, I
> > think, is a very workable solution, and another reason why using interfaces
> > is so important in designing architectures. Whew! That may be false but
> > it sure is ambitious. ///;-)
> >
>
> Two years ago I attended a presentation about a "reflective component
>framework" called FORMAware.
>
> It is way beyond than just reloading Struts actions but maybe there could
>be some ideas that could help you:
> http://www.cs.wustl.edu/~corsaro/papers/RM2003/p18-moreira.pdf
>
> Anyway I think this is good stuff so...
>
> Regards,
>
>Pedro Salgado
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Thanks for sticking with this "half-assed" idea for a bit, Craig.
All this says, if I understand you, and I am fairly sure I do, is that if
you change some class and have no way to reload it, without the container
reloading then you have a problem unless you do something about it. That
is to be expected.
So, if you are going to change a class and there is not a way to hot deploy
that class, you need to do something else. That, however, does not say
anything about the efficacy and the reasonableness on whatever basis an
architect might decide of using some hot deployment. This is not a case
that does not work with the "scheme".
This is simply a case where a class is replaced without a possibility of
hot deploy. That has nothing to do with hot deploy working where you code
for it. The "scheme" is unrelated to this problem. This is merely like
the case where I make one class serializable and another is not
serializable. That is not a failure of the "scheme" of serialization and
does not make serialization "half-assed".
Maybe I am not seeing something, but I don't think so in this case. A
solution that does not pretend to or need to solve all problems is still
useful for its intended purpose. Right?
At 11:38 PM 5/2/2004, Craig McClanahan wrote:
>Michael McGrady wrote:
>
>>This is more of a passing interest of mine, so I will pursue a bit more,
>>if you continue an interest. I have an application that needs to do this
>>from afar on multiple and untrackable sites. So, the bouncing the server
>>idea just won't work for me. I need this to happen without exchanging
>>classloaders, and probably without fiddling with the classloader
>>API. So, this is my thought: that you have multiple dependencies is not
>>important so long as they all obey the "pattern" we were discussing,
>>i.e., 1., 2., and 3. So, any application framework that provided
>>reloading only to the requisite classes, those that followed this
>>"pattern" would not be "half-assed" at all but would be fully
>>workable. One might even use a tag interface, e.g. Reloadable, to
>>identify which classes had this sort of independence. If all classes
>>were created and were loaded on this sort of structure, there would never
>>be a need to bounce servers, etc. That, I think, is a very workable
>>solution, and another reason why using interfaces is so important in
>>designing architectures.
>>Whew! That may be false but it sure is ambitious. ///;-)
>
>OK, let's be very clear about a use case that doesn't work with your scheme.
>
>A very common design pattern for Struts-based apps is to have a "setup"
>action that preconfigures a form bean, followed by a submit to a "process
>action" that performs database transactions on behalf of that very same
>form bean class. What happens in your approach when you recompile the
>form bean class to add a new property, because you need to add a new field
>to the corresponding input form? That's right ... recompiling the action
>classes is not sufficient, because the old copy of the form bean class
>continues to persist.
>
>This kind of thing happens so often that, unless you can solve it, any
>solution that deals only with reloading Actions is going to meet my test
>for "half-assed", because the fine points of what is reloadable and what
>is not is going to be totally lost on most developers. And your solution
>doesn't solve it.
>
>If your container can't do a reload fast enough, then get a new
>container. I'm not interested in Struts pretending to be a container when
>there is no way to solve all the necessary problems. That would be a
>tremendous disservice to all Struts users.
>
>Craig
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Craig McClanahan <cr...@apache.org>.
Michael McGrady wrote:
> This is more of a passing interest of mine, so I will pursue a bit
> more, if you continue an interest. I have an application that needs
> to do this from afar on multiple and untrackable sites. So, the
> bouncing the server idea just won't work for me. I need this to
> happen without exchanging classloaders, and probably without fiddling
> with the classloader API. So, this is my thought: that you have
> multiple dependencies is not important so long as they all obey the
> "pattern" we were discussing, i.e., 1., 2., and 3. So, any
> application framework that provided reloading only to the requisite
> classes, those that followed this "pattern" would not be "half-assed"
> at all but would be fully workable. One might even use a tag
> interface, e.g. Reloadable, to identify which classes had this sort of
> independence. If all classes were created and were loaded on this
> sort of structure, there would never be a need to bounce servers,
> etc. That, I think, is a very workable solution, and another reason
> why using interfaces is so important in designing architectures.
> Whew! That may be false but it sure is ambitious. ///;-)
OK, let's be very clear about a use case that doesn't work with your scheme.
A very common design pattern for Struts-based apps is to have a "setup"
action that preconfigures a form bean, followed by a submit to a
"process action" that performs database transactions on behalf of that
very same form bean class. What happens in your approach when you
recompile the form bean class to add a new property, because you need to
add a new field to the corresponding input form? That's right ...
recompiling the action classes is not sufficient, because the old copy
of the form bean class continues to persist.
This kind of thing happens so often that, unless you can solve it, any
solution that deals only with reloading Actions is going to meet my test
for "half-assed", because the fine points of what is reloadable and what
is not is going to be totally lost on most developers. And your
solution doesn't solve it.
If your container can't do a reload fast enough, then get a new
container. I'm not interested in Struts pretending to be a container
when there is no way to solve all the necessary problems. That would be
a tremendous disservice to all Struts users.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Pedro Salgado <sa...@04web.com>.
On 04/05/02 23:50, "Michael McGrady" <mi...@michaelmcgrady.com> wrote:
> This is more of a passing interest of mine, so I will pursue a bit more, if
> you continue an interest. I have an application that needs to do this from
> afar on multiple and untrackable sites. So, the bouncing the server idea
> just won't work for me. I need this to happen without exchanging
> classloaders, and probably without fiddling with the classloader API. So,
> this is my thought: that you have multiple dependencies is not important so
> long as they all obey the "pattern" we were discussing, i.e., 1., 2., and
> 3. So, any application framework that provided reloading only to the
> requisite classes, those that followed this "pattern" would not be
> "half-assed" at all but would be fully workable. One might even use a tag
> interface, e.g.
> Reloadable, to identify which classes had this sort of
> independence. If all classes were created and were loaded on this sort of
> structure, there would never be a need to bounce servers, etc. That, I
> think, is a very workable solution, and another reason why using interfaces
> is so important in designing architectures. Whew! That may be false but
> it sure is ambitious. ///;-)
>
Two years ago I attended a presentation about a "reflective component
framework" called FORMAware.
It is way beyond than just reloading Struts actions but maybe there could
be some ideas that could help you:
http://www.cs.wustl.edu/~corsaro/papers/RM2003/p18-moreira.pdf
Anyway I think this is good stuff so...
Regards,
Pedro Salgado
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
This is more of a passing interest of mine, so I will pursue a bit more, if
you continue an interest. I have an application that needs to do this from
afar on multiple and untrackable sites. So, the bouncing the server idea
just won't work for me. I need this to happen without exchanging
classloaders, and probably without fiddling with the classloader API. So,
this is my thought: that you have multiple dependencies is not important so
long as they all obey the "pattern" we were discussing, i.e., 1., 2., and
3. So, any application framework that provided reloading only to the
requisite classes, those that followed this "pattern" would not be
"half-assed" at all but would be fully workable. One might even use a tag
interface, e.g. Reloadable, to identify which classes had this sort of
independence. If all classes were created and were loaded on this sort of
structure, there would never be a need to bounce servers, etc. That, I
think, is a very workable solution, and another reason why using interfaces
is so important in designing architectures. Whew! That may be false but
it sure is ambitious. ///;-)
Michael
At 01:25 PM 5/2/2004, Craig R. McClanahan wrote:
>Michael McGrady wrote:
>
>>To expand (part question and part statement): Suppose:
>>
>>1. We made an interface, Action, which the present Struts Action
>>(renamed, say, "ActionImpl") implemented.
>>2. We created a daemon ActionFactory which loaded actions from outside
>>the CLASSPATH using a URLClassloader, etc., and which did not reference
>>the implementation(s) but only the interface.
>>3. We created a method in the main(String [] params) for the web
>>container which allowed us to reload using the ActionFactory.
>
>Steps 1 and 2 are pretty much how many servlet container deals with
>individual JSP pages that have been changed ... they are each loaded into
>a separate class loader (an alternative strategy is to change the
>classname for each generated servlet, and add that class to the existing
>webapp class loader).
>
>This works fine for classes that never refer to each other. But what do
>you do with classes (like DTOs or form beans) that might be referenced by
>more than one Action? You're back to where we started. Unless/until Java
>provides ClassLoader.unloadClass(), this is not a problem that can be
>solved inside a webapp.
>I am not a believer in providing half-assed solutions to this kind of
>problem, or an application framework pretending to be an app server
>container. Instead, you're better off finding app server implementations
>that do the reload trick fast enough to meet your needs. My typical
>reload turnaround time during development, on either Tomcat or Sun's app
>server (the 8.0 version of PE) is under two seconds, even counting the
>fact that I typically invoke it with a command line Ant invocation. I
>don't consider that to be a problem.
>
>>
>>
>>Wouldn't that work with very little effort?
>
>As described above, it only solves part of the problem ... not enough to
>make it worth implementing, IMHO.
>
>>
>>Michael McGrady
>
>Craig
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Craig McClanahan <cr...@apache.org>.
Michael McGrady wrote:
> At 11:40 PM 5/2/2004, Craig McClanahan wrote:
>
>> Michael McGrady wrote:
>>
>>> Isn't it true, Craig, that this is not a problem for hot deploy of
>>> the classes that do this. If you have other classes that do not do
>>> this, then they cannot be hot deployed. But, what difference does
>>> that make? If someone wants to hot deploy them, they can redesign
>>> the class. The more I think about it, the less of a problem this
>>> seems to be. Am I missing something here?
>>
>>
>> Most containers (but no guarantees, since it's not in the specs) will
>> know how to pick up a new class that has never been compiled before.
>> No container that I know of lets you selectively replace classes that
>> have already been loaded into the class loader, because Java's class
>> loader API doesn't support unloadClass() or replaceClass().
>>
>> Solving 1% of the problem doesn't help -- it only misleads people.
>> See my response in the other thread for a very common Struts use case
>> that doesn't work with your approach.
>
>
> In the other thread I responded to the idea that the use case doesn't
> work. That use case is not supposed to work. Making one class hot
> deployable is not supposed to make all classes hot deployable.
> Personally, I don't see a good reason not to make an entire framework
> hot deployable. This could be done fairly easy and without doing the
> framework any injustice that is obvious. All you have to do is to
> provide the proper interfaces which is probably a good idea for lots
> of reasons and cannot really hurt for any reason I know of and then
> you can easily employ class factories using a new classloader for each
> hot deploy. That would for a game application, for example, provide a
> 100% solution unrelated to the container.
>
> The key, and maybe you are not seeing this is part of the solution, is
> to load the implementation with the following being true:
>
> 1. Do not have the client (container) reference the implementation
> that needs to be replaced. Otherwise you will have to bounce the
> client (container).
> 2. Have the client (container) reference only a base class or an
> interface. If you change base classes or interfaces, you would still
> have to bounce the client (container), but that is not a problem.
> 3. Have the implementation class's classloader delegate to the client
> (container) classloader. Presumably this means that the client
> (container) would be using the system classloader.
> 4. Make sure that a number of things happen with a hot deploy by a
> class factory: (a) get the state of the old implementation and add it
> to the new one, so the client (container) must make the state of the
> original object available to the factory and (b) the client
> (container) must drop any old references to the old implementations
> both to save resources and to use the new version, these objectives
> are achieved by passing the old implementation into the factor and
> returning the new one with the same reference as the old one.
> 5. If you want to hide things from the client (container) as well,
> give the client (container) a forwarding proxy to the actual object,
> giving the factory the control of swapping the object at any time
> without either the knowledge or agreement of the client (container).
>
> Here "container" might be "framework". Yes?
Taking this whole approach is not specific to Struts, but (if it is
actually useful) would have general applicability. It sounds like what
you're designing is a specialized sort of servlet container that knows
how to support some limited subset of hot deploy -- plus a design
paradigm for building applications for it that requires you to replace
any persistent reference to another object with a lookup in a cache of
some sort (so that you're not pointing at an object based on an obsolete
implementation class). This can have pretty dramatic impacts on code
readability and performance, but presumably someone will find it
worthwhile. I wouldn't personally be willing to live under the
restrictions such a design paradigm implies when building apps.
But it is still totally out of scope for Struts.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
At 11:40 PM 5/2/2004, Craig McClanahan wrote:
>Michael McGrady wrote:
>
>>Isn't it true, Craig, that this is not a problem for hot deploy of the
>>classes that do this. If you have other classes that do not do this,
>>then they cannot be hot deployed. But, what difference does that
>>make? If someone wants to hot deploy them, they can redesign the
>>class. The more I think about it, the less of a problem this seems to
>>be. Am I missing something here?
>
>Most containers (but no guarantees, since it's not in the specs) will know
>how to pick up a new class that has never been compiled before. No
>container that I know of lets you selectively replace classes that have
>already been loaded into the class loader, because Java's class loader API
>doesn't support unloadClass() or replaceClass().
>
>Solving 1% of the problem doesn't help -- it only misleads people. See my
>response in the other thread for a very common Struts use case that
>doesn't work with your approach.
In the other thread I responded to the idea that the use case doesn't
work. That use case is not supposed to work. Making one class hot
deployable is not supposed to make all classes hot deployable. Personally,
I don't see a good reason not to make an entire framework hot
deployable. This could be done fairly easy and without doing the framework
any injustice that is obvious. All you have to do is to provide the proper
interfaces which is probably a good idea for lots of reasons and cannot
really hurt for any reason I know of and then you can easily employ class
factories using a new classloader for each hot deploy. That would for a
game application, for example, provide a 100% solution unrelated to the
container.
The key, and maybe you are not seeing this is part of the solution, is to
load the implementation with the following being true:
1. Do not have the client (container) reference the implementation that
needs to be replaced. Otherwise you will have to bounce the client
(container).
2. Have the client (container) reference only a base class or an
interface. If you change base classes or interfaces, you would still have
to bounce the client (container), but that is not a problem.
3. Have the implementation class's classloader delegate to the client
(container) classloader. Presumably this means that the client (container)
would be using the system classloader.
4. Make sure that a number of things happen with a hot deploy by a class
factory: (a) get the state of the old implementation and add it to the new
one, so the client (container) must make the state of the original object
available to the factory and (b) the client (container) must drop any old
references to the old implementations both to save resources and to use the
new version, these objectives are achieved by passing the old
implementation into the factor and returning the new one with the same
reference as the old one.
5. If you want to hide things from the client (container) as well, give
the client (container) a forwarding proxy to the actual object, giving the
factory the control of swapping the object at any time without either the
knowledge or agreement of the client (container).
Here "container" might be "framework". Yes?
RE: Way to reload struts Action classes in WebLogic8.1
Posted by Andrew Hill <an...@gridnode.com>.
<snip>
No container that I know of lets you selectively replace classes that have
already been loaded into the class loader, because Java's class loader
API doesn't support unloadClass() or replaceClass().
</snip>
I use the Sysdeo plugin for eclipse with tomcat and it lets me make minor
modifications to code 'on the fly' while Im debugging stuff.
Obviously this sort of thing is far from a 'full-arsed' solution in that
anything that changes the interface (or needs to reload static stuff etc...)
is no-go, but I am rather curious as to this is achieved in the absence of a
classloader replaceClass() call?
As for all this being out of struts scope Im definately +1 on that!
-----Original Message-----
From: Craig McClanahan [mailto:craigmcc@apache.org]
Sent: Monday, 3 May 2004 14:41
To: Struts Users Mailing List
Subject: Re: Way to reload struts Action classes in WebLogic8.1
Michael McGrady wrote:
> Isn't it true, Craig, that this is not a problem for hot deploy of the
> classes that do this. If you have other classes that do not do this,
> then they cannot be hot deployed. But, what difference does that
> make? If someone wants to hot deploy them, they can redesign the
> class. The more I think about it, the less of a problem this seems to
> be. Am I missing something here?
>
Most containers (but no guarantees, since it's not in the specs) will
know how to pick up a new class that has never been compiled before. No
container that I know of lets you selectively replace classes that have
already been loaded into the class loader, because Java's class loader
API doesn't support unloadClass() or replaceClass().
Solving 1% of the problem doesn't help -- it only misleads people. See
my response in the other thread for a very common Struts use case that
doesn't work with your approach.
> Michael
Craig
---------------------------------------------------------------------
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: Way to reload struts Action classes in WebLogic8.1
Posted by Craig McClanahan <cr...@apache.org>.
Michael McGrady wrote:
> Isn't it true, Craig, that this is not a problem for hot deploy of the
> classes that do this. If you have other classes that do not do this,
> then they cannot be hot deployed. But, what difference does that
> make? If someone wants to hot deploy them, they can redesign the
> class. The more I think about it, the less of a problem this seems to
> be. Am I missing something here?
>
Most containers (but no guarantees, since it's not in the specs) will
know how to pick up a new class that has never been compiled before. No
container that I know of lets you selectively replace classes that have
already been loaded into the class loader, because Java's class loader
API doesn't support unloadClass() or replaceClass().
Solving 1% of the problem doesn't help -- it only misleads people. See
my response in the other thread for a very common Struts use case that
doesn't work with your approach.
> Michael
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Isn't it true, Craig, that this is not a problem for hot deploy of the
classes that do this. If you have other classes that do not do this, then
they cannot be hot deployed. But, what difference does that make? If
someone wants to hot deploy them, they can redesign the class. The more I
think about it, the less of a problem this seems to be. Am I missing
something here?
Michael
At 01:25 PM 5/2/2004, Craig R. McClanahan wrote:
>Michael McGrady wrote:
>
>>To expand (part question and part statement): Suppose:
>>
>>1. We made an interface, Action, which the present Struts Action
>>(renamed, say, "ActionImpl") implemented.
>>2. We created a daemon ActionFactory which loaded actions from outside
>>the CLASSPATH using a URLClassloader, etc., and which did not reference
>>the implementation(s) but only the interface.
>>3. We created a method in the main(String [] params) for the web
>>container which allowed us to reload using the ActionFactory.
>
>Steps 1 and 2 are pretty much how many servlet container deals with
>individual JSP pages that have been changed ... they are each loaded into
>a separate class loader (an alternative strategy is to change the
>classname for each generated servlet, and add that class to the existing
>webapp class loader).
>
>This works fine for classes that never refer to each other. But what do
>you do with classes (like DTOs or form beans) that might be referenced by
>more than one Action? You're back to where we started. Unless/until Java
>provides ClassLoader.unloadClass(), this is not a problem that can be
>solved inside a webapp.
>I am not a believer in providing half-assed solutions to this kind of
>problem, or an application framework pretending to be an app server
>container. Instead, you're better off finding app server implementations
>that do the reload trick fast enough to meet your needs. My typical
>reload turnaround time during development, on either Tomcat or Sun's app
>server (the 8.0 version of PE) is under two seconds, even counting the
>fact that I typically invoke it with a command line Ant invocation. I
>don't consider that to be a problem.
>
>>
>>
>>Wouldn't that work with very little effort?
>
>As described above, it only solves part of the problem ... not enough to
>make it worth implementing, IMHO.
>
>>
>>Michael McGrady
>
>Craig
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Way to reload struts Action classes in WebLogic8.1
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Michael McGrady wrote:
> To expand (part question and part statement): Suppose:
>
> 1. We made an interface, Action, which the present Struts Action
> (renamed, say, "ActionImpl") implemented.
> 2. We created a daemon ActionFactory which loaded actions from
> outside the CLASSPATH using a URLClassloader, etc., and which did not
> reference the implementation(s) but only the interface.
> 3. We created a method in the main(String [] params) for the web
> container which allowed us to reload using the ActionFactory.
Steps 1 and 2 are pretty much how many servlet container deals with
individual JSP pages that have been changed ... they are each loaded
into a separate class loader (an alternative strategy is to change the
classname for each generated servlet, and add that class to the existing
webapp class loader).
This works fine for classes that never refer to each other. But what do
you do with classes (like DTOs or form beans) that might be referenced
by more than one Action? You're back to where we started. Unless/until
Java provides ClassLoader.unloadClass(), this is not a problem that can
be solved inside a webapp.
I am not a believer in providing half-assed solutions to this kind of
problem, or an application framework pretending to be an app server
container. Instead, you're better off finding app server
implementations that do the reload trick fast enough to meet your
needs. My typical reload turnaround time during development, on either
Tomcat or Sun's app server (the 8.0 version of PE) is under two
seconds, even counting the fact that I typically invoke it with a
command line Ant invocation. I don't consider that to be a problem.
>
>
> Wouldn't that work with very little effort?
As described above, it only solves part of the problem ... not enough to
make it worth implementing, IMHO.
>
> Michael McGrady
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Action class performance
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Erwin Cabral wrote:
>1. Are there any performance issues involved when an
>Action class forwards to another?
>
Any RequestDispatcher.forward() call has roughly the same performance
impact as what the container has to do on any original HTTP request (map
the request to a particular servlet, start that servlet as needed, and
call the service() method). Since it all happens on the server side,
it's generally a very small amount of time. In most cases, it will be
an order of magnitude faster than anything that requires an HTTP redirect.
>
>2. Does the number of Actions created in a web
>application affect the overall performance of the
>application?
>
>
The only possible way this could matter is if you run out of memory,
which is typically not the issue. The most common performance
bottlenecks I've seen are (in priority order):
* Database access
* Network performance
* Locking too aggressively
Performance tools can help you analyze where the issues are for your
particular application.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Action class performance
Posted by Erwin Cabral <er...@yahoo.com>.
1. Are there any performance issues involved when an
Action class forwards to another?
2. Does the number of Actions created in a web
application affect the overall performance of the
application?
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Way to reload struts Action classes in WebLogic8.1
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
To expand (part question and part statement): Suppose:
1. We made an interface, Action, which the present Struts Action (renamed,
say, "ActionImpl") implemented.
2. We created a daemon ActionFactory which loaded actions from outside the
CLASSPATH using a URLClassloader, etc., and which did not reference the
implementation(s) but only the interface.
3. We created a method in the main(String [] params) for the web container
which allowed us to reload using the ActionFactory.
Wouldn't that work with very little effort?
Michael McGrady
At 10:15 PM 5/1/2004, Craig R. McClanahan wrote:
>Inamdar, Anil - Cons wrote:
>
>>Hello,
>>Is there a way to reload Actions in Weblogic without redeploying the web
>>application.
>No. Java provides no way to replace a class (loaded by a particular class
>loader) with a modified version, without throwing away the entire class
>loader. That's what normally happens when you reload a webapp.
>
>>I have the servlet reloading enabled , but weblogic doesnt seem to recognize
>>the changes to the Action classes and throws a ClassCastException.
>>So every small change I make, I have to redeploy the Web app which makes the
>>whole development process slow.
>I don't know about Weblogic, but Sun's app servers (and Tomcat) have
>"reload" options that are *much* faster than the undeploy/redeploy cycle
>it sounds like you are using. Check the docs.
>
>>thanks
>>Anil
>>
>Craig
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Way to reload struts Action classes in WebLogic8.1
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Inamdar, Anil - Cons wrote:
>Hello,
>Is there a way to reload Actions in Weblogic without redeploying the web
>application.
>
No. Java provides no way to replace a class (loaded by a particular
class loader) with a modified version, without throwing away the entire
class loader. That's what normally happens when you reload a webapp.
>I have the servlet reloading enabled , but weblogic doesnt seem to recognize
>the changes to the Action classes and throws a ClassCastException.
>So every small change I make, I have to redeploy the Web app which makes the
>whole development process slow.
>
I don't know about Weblogic, but Sun's app servers (and Tomcat) have
"reload" options that are *much* faster than the undeploy/redeploy cycle
it sounds like you are using. Check the docs.
>thanks
>Anil
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org