You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Leonardo Mena <lm...@swordfish.com.uy> on 2001/11/02 16:21:36 UTC
ClassCastException when moving extended Action and ActionForm classes in the classpath
Hi folks! I am from Uruguay, South America, so sorry my English :)
I am evaluating the Struts framework as an MVC aproach in the web tier in
our company product (after attending the entusiastic presentation in the
JavaOne conference!). The framework convince us pretty much, but we are very
concerned with a situation that we hope is due to our little experience with
Struts.
PROBLEM:
If we move our extended Action or ActionForm classes from WEB-INF/classes to
somewhere else in the servlet container classpath (we're using ServletExec
3.0c), an error occurs (ClassCastException) wich prevents the application to
continue.
DETAIL:
I don't want to include further details (such as servlet logs) unless you
think it's necesary, but tell you that the error takes the form of a
java.lang.ClassCastException in the ActionServlet, when it attemps to cast a
new extended Action class (instantiated via reflection) to its superclass
Action. We're pretty confussed because the class is found and instantiated
when moved, but generates a cast error, even when the log tell us that its
superclass is the one Struts is casting to: org.apache.struts.action.Action.
The same occurs with ActionForm. The web browser shows a processed error
message: "The following error occurred: 500 - No action instance for path
/logon could be created".
Any help will be very appreciated, we hope we're doing some trivial mistake
or something else and this is not a limitation on the framework. We think
that from a JVM standpoint this make no sense, but...
Thanks in advance,
Leonardo Mena
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ClassCastException when moving extended Action and ActionForm classes in the classpath
Posted by Leonardo Mena <lm...@swordfish.com.uy>.
Thanks for your response, I'm now understanding the problem, but my concern
remains: so, it is not possible with the Struts framework to have some
extended Action classes in WEB-INF/classes and other somewhere in the
classpath?
I think this is a serious limitation, imagine our situation: we have one web
app per client, but the app is mainly the same (that is, the same classes,
but we have one app per client to have more flexibility with each one), so
we have a common folder of the classpath where we have all our classes. Some
clients may want to have different behaviours on some actions, different of
the standard ones, so, we envisioned the following solution: for those
customized clients we could have a modified "struts-config.xml" that use
other extended Action classes. Thosse client propietary extended Action
classes makes sense only for those clients, so those classes belongs to they
WEB-INF/classes folder, the "default" ones remains in the common folder in
the classpath. Well, it seems that we can't do these with Struts, isn't it?
Thanks in advance,
Leonardo Mena
PD: Is there any way to force the same class loader to load the extended
classes?
-----Original Message-----
From: martin.cooper@tumbleweed.com [mailto:martin.cooper@tumbleweed.com]
Sent: Domingo, 04 de Noviembre de 2001 09:19 p.m.
To: Struts Users Mailing List
Subject: Re: ClassCastException when moving extended Action and
ActionForm classes in the classpath
What you are seeing is most likely the result of different class loaders
being used. That's why you need to leave the Struts application in
WEB-INF/classes or WEB-INF/lib.
--
Martin Cooper
----- Original Message -----
From: "Leonardo Mena" <lm...@swordfish.com.uy>
To: <st...@jakarta.apache.org>
Sent: Friday, November 02, 2001 7:21 AM
Subject: ClassCastException when moving extended Action and ActionForm
classes in the classpath
> Hi folks! I am from Uruguay, South America, so sorry my English :)
>
> I am evaluating the Struts framework as an MVC aproach in the web tier in
> our company product (after attending the entusiastic presentation in the
> JavaOne conference!). The framework convince us pretty much, but we are
very
> concerned with a situation that we hope is due to our little experience
with
> Struts.
>
>
> PROBLEM:
>
> If we move our extended Action or ActionForm classes from WEB-INF/classes
to
> somewhere else in the servlet container classpath (we're using ServletExec
> 3.0c), an error occurs (ClassCastException) wich prevents the application
to
> continue.
>
>
> DETAIL:
>
> I don't want to include further details (such as servlet logs) unless you
> think it's necesary, but tell you that the error takes the form of a
> java.lang.ClassCastException in the ActionServlet, when it attemps to cast
a
> new extended Action class (instantiated via reflection) to its superclass
> Action. We're pretty confussed because the class is found and instantiated
> when moved, but generates a cast error, even when the log tell us that its
> superclass is the one Struts is casting to:
org.apache.struts.action.Action.
> The same occurs with ActionForm. The web browser shows a processed error
> message: "The following error occurred: 500 - No action instance for path
> /logon could be created".
>
> Any help will be very appreciated, we hope we're doing some trivial
mistake
> or something else and this is not a limitation on the framework. We think
> that from a JVM standpoint this make no sense, but...
>
> Thanks in advance,
> Leonardo Mena
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ClassCastException when moving extended Action and
ActionForm classes in the classpath
Posted by ma...@tumbleweed.com.
What you are seeing is most likely the result of different class loaders
being used. That's why you need to leave the Struts application in
WEB-INF/classes or WEB-INF/lib.
--
Martin Cooper
----- Original Message -----
From: "Leonardo Mena" <lm...@swordfish.com.uy>
To: <st...@jakarta.apache.org>
Sent: Friday, November 02, 2001 7:21 AM
Subject: ClassCastException when moving extended Action and ActionForm
classes in the classpath
> Hi folks! I am from Uruguay, South America, so sorry my English :)
>
> I am evaluating the Struts framework as an MVC aproach in the web tier in
> our company product (after attending the entusiastic presentation in the
> JavaOne conference!). The framework convince us pretty much, but we are
very
> concerned with a situation that we hope is due to our little experience
with
> Struts.
>
>
> PROBLEM:
>
> If we move our extended Action or ActionForm classes from WEB-INF/classes
to
> somewhere else in the servlet container classpath (we're using ServletExec
> 3.0c), an error occurs (ClassCastException) wich prevents the application
to
> continue.
>
>
> DETAIL:
>
> I don't want to include further details (such as servlet logs) unless you
> think it's necesary, but tell you that the error takes the form of a
> java.lang.ClassCastException in the ActionServlet, when it attemps to cast
a
> new extended Action class (instantiated via reflection) to its superclass
> Action. We're pretty confussed because the class is found and instantiated
> when moved, but generates a cast error, even when the log tell us that its
> superclass is the one Struts is casting to:
org.apache.struts.action.Action.
> The same occurs with ActionForm. The web browser shows a processed error
> message: "The following error occurred: 500 - No action instance for path
> /logon could be created".
>
> Any help will be very appreciated, we hope we're doing some trivial
mistake
> or something else and this is not a limitation on the framework. We think
> that from a JVM standpoint this make no sense, but...
>
> Thanks in advance,
> Leonardo Mena
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>