You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Kevin Duffey <kd...@buymedia.com> on 2000/06/25 02:55:26 UTC
This framework rocks!
Hi,
I just wanted to express my enthusiasm for the use of Struts. While I wrote
my own little framework that did work similarly to Struts, based on a number
of discussions with Craig, Struts obviously has the advantage because its
open, Craig (the guru) is writing it, and alot more of us are contributing
ideas and hopefully providing a good solid testbed for Craig to improve
upon.
None the less, I wanted to let everyone know how fast it is to actually work
with Struts on the front end. I have the disturbing task of dealing with
crappy code and converting it into something good, solid and stable. I am
basically rewriting about 30,000 lines of servlet code into using the Struts
framework, actions, and having it call our "logic" classes. Not only is it
much easier than I originally thought, but at least to me, it appears to be
running much faster..possibly due to the fact that our servlets are always
created an object for every request, putting in a connection, etc..where as
now I am not doing that at all. The added benefit of multiple forwarding
pages for each action based on a String result that matches that of the
action.xml <action...> tags, bean auto-population and creation, and the xml
config being loaded and maintained for me has increased my level of work
greatly. I feel confident that I can create a full set of pages (for
example.. a series of "wizard" page/forms for a single transaction), a
javabean that is used across those pages, and a "session" (logic) class that
handles the connection to the database, does the searching, getting and
updating of info, in a matter of hours..if not less. This includes building
the JSP pages WITH form/field validation for fields I specify, as well as
one or more taglibs used to display dynamic content. Before, it took days to
fully test the same type of setup because of all the issues with our code
base, and other issues aside.
Anyways..just wanted to pass that on to those interested..especially if your
new to the whole Model 2 action/servlet approach and might be frustrated
with it, not fully understanding it, etc.
One last thing..Craig has done us a service by including the xml config
loading and also the auto-populating and creation of beans. One of the BIG
complaints I saw in the JSP-INTEREST mailing list about using Model 2 over
Model 1 (where you use JSP pages and JaveBeans and the JSPServlet
auto-populates the bean..etc) was that using the Model 2 approach you didn't
get the bean auto-population. Craig has nicely taken care of this.
Ahh..one request..the ability to run a little "admin" utility that reloads
the xml config file..and ONLY adds or modifies actions that have changed.
The reason is..it would be nice at runtime, for example, to "replace" an
existing action with a new version of the code. Mostly this would be useful
in the need of an emergency fix. It would also be nice to add NEW actions to
the list (in memory) without having to stop/start the server..so that during
the day I could throw up some new pages and they would take effect
immediately..when a request came in for them. Craig..any ideas if this is
possible?
Thanks again.
RE: Struts and Sessions
Posted by Kevin Duffey <kd...@buymedia.com>.
It knows based on the first request sent to it. In the HttpServletRequest,
there is a header that must indicate if it supports it..or maybe Orion
"writes" a small response or something. I am not sure how it does it. I just
know it does it. If you turn cookies off, and you use Orion, you'll start
seeing a ?jsessionid=A23409ua or something like that. The jsessionid
parameter is the standard cookie session id name, and the value after it is
a server geneated session id value that Orion uses to find the session for
the same user.
> -----Original Message-----
> From: Colin Wilson-Salt [mailto:colin@london.virgin.net]
> Sent: Tuesday, June 27, 2000 11:44 AM
> To: struts-user@jakarta.apache.org
> Subject: Re: Struts and Sessions
>
>
> But, how does it know?
>
> Kevin Duffey wrote:
>
> > Hi,
> >
> > > If I want to support sessions on these devices, I have to
> resort to old
> > > tricks like URL rewriting etc. Can Struts give me any help here, maybe
> > > through its custom tags, to create URL rewritten links, and what
> > > should I do
> > > about forms.
> >
> > I don't know about other app servers, but Orion automatically uses URL
> > Rewriting if the browser doesn't support cookies. You don't have to do
> > anything to get the benefit. For what its worth..
>
>
Re: Struts and Sessions
Posted by Colin Wilson-Salt <co...@london.virgin.net>.
But, how does it know?
Kevin Duffey wrote:
> Hi,
>
> > If I want to support sessions on these devices, I have to resort to old
> > tricks like URL rewriting etc. Can Struts give me any help here, maybe
> > through its custom tags, to create URL rewritten links, and what
> > should I do
> > about forms.
>
> I don't know about other app servers, but Orion automatically uses URL
> Rewriting if the browser doesn't support cookies. You don't have to do
> anything to get the benefit. For what its worth..
RE: Struts and Sessions
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> If I want to support sessions on these devices, I have to resort to old
> tricks like URL rewriting etc. Can Struts give me any help here, maybe
> through its custom tags, to create URL rewritten links, and what
> should I do
> about forms.
I don't know about other app servers, but Orion automatically uses URL
Rewriting if the browser doesn't support cookies. You don't have to do
anything to get the benefit. For what its worth..
RE: Struts and Sessions
Posted by Colin Wilson-Salt <co...@london.virgin.net>.
I think you've covered the issues of resource use by sessions quite well.
However, there a just a couple of points that I can think of:
In my experience, coders are often slack about removing stuff from sessions,
so sessions tend to grow.
Also the correct use of sessions needs to be stressed, I feel they should
only be used for stuff that needs to held for a while. I feel that request
scope should be used for things which are only displayed on the resulting
page.
This is why in my code I have always used Request scope for my equivalent of
Strut's ActionForm. Sure, a new form bean gets constructed everytime the
user iterates around the form, but most of the time users get it right first
time.
I have to deal with devices that don't support cookies. But the usage
pattern on these devices tends to be a very short sequence of requests -
people looking for very specific information, rather than browsing.
If I want to support sessions on these devices, I have to resort to old
tricks like URL rewriting etc. Can Struts give me any help here, maybe
through its custom tags, to create URL rewritten links, and what should I do
about forms.
I know this has strayed away from Struts, and into more general servlet
programming issues. I hope people don't mind.
-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: 26 June 2000 18:58
To: struts-user@jakarta.apache.org
Subject: Re: Struts and Sessions
Colin Wilson-Salt wrote:
> Would it be possible to make the use of sessions in Struts optional?
>
> I'm concerned about the resource overhead if we have a lot of people
visiting just a
> few pages in our site.
>
> We already build applications using the same kind of patterns that Struts
uses, but
> it would be nice to have the benefits of the formalised structure that
Struts gives.
>
> On the other hand, does anyone have any evidence that the resource
overhead of
> sessions is something I shouldn't be concernced about?
There are a couple of issues raised here (and in the follow-ups) to be
addressed:
(1) Can I Use Struts Without Sessions?
Using the basic MVC controller servlet without sessions is certainly
feasible. But it
is worth looking at what Struts uses sessions for, and therefore what you
give up
without them.
The background for this discussion is the fact that HTTP is a stateless
protocol. In
other words, there is absolutely nothing provided by the protocol itself
that ties one
request from a particular user to the next request from that same user.
(Just as an
example, some people assume that they can use the remote IP address to make
this
distinction, but that doesn't work when your users are behind a firewall and
they all
appear to have the same IP address, or if you have multiple users running
off the same
server.) The session management capability in the servlet API provides a
mechanism for
establishing this kind of connection between requests, and requires sending
the client
an identifier (using either cookies or URL rewriting) that the client can
send back on
the next request.
In Struts specifically, the following uses are made of sessions:
* You can store the ActionForm bean in the session or the request.
If your bean supports multi-page input, session is the only way
to save the values from the previous page(s). For single page
forms, request scope works fine.
* Struts expects a per-user Locale to represent the users's choice
of language and display styles for internationalized messages.
Generally, if this object is not present, the server's default Locale
will be used.
In web applications based on servlets and JSP pages in general (including
those based on
Struts), you also have the following issues to think about:
* By default, JSP pages assume that they are part of a session.
If you don't want this, you have to put the following code at the
top of every single page:
<%@ page ... session="false" ... %>
* Many applications perform their own authentication and login
to make sure that only validated users can access certain
parts of the application. The usual mechanism for doing this is
to store some sort of user object in the user's session -- if you
detect that this object is missing (because the user tried to jump
into the middle of your app without logging in, or because their
previous session timed out), you force them to the login page.
Without sessions, this will be very difficult to implement
in a robust manner.
* Without sessions, you are limited to transactions that can be
completed solely based on the request parameters of a single
individual request, since you have no way to link more than one
request together.
* Many sites like to personalize the appearance of their apps
based on who the user is, or what preferences they have saved.
Beyond the authentication issue mentioned earlier, most such
apps save the user's current preferences in a session variable
to save having to go back to the database every request. This can
be a significant performance impact.
So are sessions worth it? Well, that depends on the cost, as we'll see in
the next
question ....
(2) What Are The Performance Impacts of Sessions?
If you have looked at very many of the Java "standard extensions" APIs, you
will note
that most of them define Java interfaces (and associated contracts
documented in the
spec and the Javadocs) that a particular implementation of that API must
conform to, but
they give the implementers a fair degree of freedom in *how* to conform to
the
requirements. Thus, there is no general answer to the question "how does a
servlet
container implement the HttpSession interface."
However, it is worthwhile looking at the way Tomcat handles this -- most of
the
containers I'm familiar with do something similar.
Inside of Tomcat, the set of active sessions associated with a part of a web
application
are instances of the class org.apache.tomcat.session.StandardSession, which
has a few
small instance variables and a Hashtable to contain the user's session
beans. For a
session with no session attributes, this is probably something on the order
of 50 bytes
of memory usage in the JVM's heap (why no precise answer? well, it depends
on the
implementation of the JVM ....). Tomcat also maintains a Hashtable of all
the active
sessions at any given point in time, inside a component called the
"Manager".
Individual sessions can store any number of session-scoped beans (JSP
terminology). The
memory occupancy of those beans is totally dependent on the instance
variables in that
bean (there's only one memory copy of the bytecodes of any class in Java, so
how much
code there is has almost zero impact). Note that you, as the developer,
have total
control over adding and *removing* these objects. For example, as soon as
you are done
with a particular ActionForm bean in a Struts application, you should remove
it from the
session (in the Action class that received the final copy of the form) so
that it can be
garbage collected. There's no reason to keep it around any longer than
that.
Hashtables have the nice property that they support keyed access to even
large numbers
of objects with fairly linear response times. Thus, it makes almost no
difference (from
a CPU time point of view) how many active sessions there are, or how many
session scope
beans you have in a particular sesison.
In general, you will run into performance issues on your database and
network long
before you run out of CPU time -- unless your app is particularly
CPU-intensive, so your
mileage may vary.
The bottom line -- if you don't need to maintain any state information
across requests
from the same user, you don't need sessions. If you do need this, sessions
are a pretty
cheap way to meet that need. What you need to do is plan the memory
requirements
appropriately (peak # of active sessions * peak memory for session scope
beans, if you
want to be conservative).
Craig McClanahan
RE: Struts and Sessions
Posted by Kevin Duffey <kd...@buymedia.com>.
Bravo! Awesome explanation Craig.
I would like to add a bit on how to get around the performance issue.. at
least in one way.
I have bragged alot about Orion app server, and for good reason. Not only is
it a full J2EE app server, not only is it VERY fast at returning JSP pages
(dynamic pages), but it also is a full featured clusterable server, all for
the low price of $1500 per server. So let me give you a simple diagram of
what I saw a lot of at JavaOne on how web-apps (and hardware) is being set
up.
Oh..and this is off topic a little bit..so I apologize, but there seems to
be a lot of interest in the performance issue with sessions, so if you find
this way off topic, delete it. :)
The 3-tier setup includes a front-end servlet container cluster, the
middle-tier ejb cluster, and the back end database cluster. App servers only
worry about the first two, but provide APIs to handle connection pooling and
the sorts for the back-end cluster. JDBC 2.0 makes it nice with DataSources
and all that good stuff.
A typical front-end cluster for fail-over and load-balancing would consist
of a load-balancer that feeds two servers. Now..I am not a hardware pro so I
don't know exactly how this is set up at this time..but I do know you need
something that can evenly feed the two (or more) servers in the front-end
cluster. This can be another machine with software load-balancing, or for
less money and more performance a good Cisco load balancer will do the
trick.
Because Orion is so cheap, and it has a license per server, you can put dual
or quad cpu servers on the front end and pay the same price for Orion. Now,
my company is deiciding between weblogic, silverstream, etc..and the
cheapest I have seen is $15K per cpu. We have decided to use single-cpu 1Ghz
systems with 1GB memory for our front-end servlet cluster, and probably the
same for our EJB cluster.
What I am getting at with all this is that you can "easily" (albeit a bit
more money) set up a cluster of servers to handle more clients (and more
sessions) using Orion clustering. With the use of WebLogic, JRUN 3.0 and
others, it will cost us about $250,000 to setup the hardware we want to use
for fail-over, load-balancing, etc. Most of that cost is the app server
licensing. With Orion, if you figure about $6000 per server (again, 1Ghz,
SCSI III, 1GB memory, Dell rack-mount systems) and $1500 per license, you
look at about $7500 for each server, or $15K for a two-server cluster with
load-balancing and fail-over. Plus your load-balance..a good hardware Cisco
runs about $5K to $10K. I wont get into back-end database cost..thats a
separate issue.
Point here is that by using Orion you can cheaply set up a clusterable
system with great performance and plenty of memory and ability to handle
1000's of users.
Now I say its cheap, loosely because if I were to start my own company, I
surely wouldn't be able to afford $50K in a full hardware setup..but $50K is
feasible with Orion, where as most other app servers I have seen it would
cost in to the $100K's mark.
At any rate..my goal here is to point out that there are solutions to allow
better performance. As far as I can tell, one server with 1GB memory should
be able to handle 1000's of users. Somebody correct me if I am wrong, but I
believe the "hashtable's" used by the HttpSession store references to
objects..and not the full object themselves. As Craig said..when your done
with it..remove the object so its gc'd and you should be able to handle alot
more users.
Anyways..I am ranting..sorry for the off-topic, but this is what I have been
going over in our company for some time now as well. We have the mentality
that if its too slow..throw more hardware at it, and while that is not
always the best thing to do..that is what clustering allows you to do. I
believe that is why it came about..to allow vertical growth of a server farm
to handle more clients at one time.
<snip>
>garbage collected. There's no reason to keep it around any
> longer than that.
>
> Hashtables have the nice property that they support keyed access
> to even large numbers
> of objects with fairly linear response times. Thus, it makes
> almost no difference (from
> a CPU time point of view) how many active sessions there are, or
> how many session scope
> beans you have in a particular sesison.
>
> In general, you will run into performance issues on your database
> and network long
> before you run out of CPU time -- unless your app is particularly
> CPU-intensive, so your
> mileage may vary.
>
> The bottom line -- if you don't need to maintain any state
> information across requests
> from the same user, you don't need sessions. If you do need
> this, sessions are a pretty
> cheap way to meet that need. What you need to do is plan the
> memory requirements
> appropriately (peak # of active sessions * peak memory for
> session scope beans, if you
> want to be conservative).
>
> Craig McClanahan
>
>
>
>
>
Re: Struts and Sessions
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Colin Wilson-Salt wrote:
> Would it be possible to make the use of sessions in Struts optional?
>
> I'm concerned about the resource overhead if we have a lot of people visiting just a
> few pages in our site.
>
> We already build applications using the same kind of patterns that Struts uses, but
> it would be nice to have the benefits of the formalised structure that Struts gives.
>
> On the other hand, does anyone have any evidence that the resource overhead of
> sessions is something I shouldn't be concernced about?
There are a couple of issues raised here (and in the follow-ups) to be addressed:
(1) Can I Use Struts Without Sessions?
Using the basic MVC controller servlet without sessions is certainly feasible. But it
is worth looking at what Struts uses sessions for, and therefore what you give up
without them.
The background for this discussion is the fact that HTTP is a stateless protocol. In
other words, there is absolutely nothing provided by the protocol itself that ties one
request from a particular user to the next request from that same user. (Just as an
example, some people assume that they can use the remote IP address to make this
distinction, but that doesn't work when your users are behind a firewall and they all
appear to have the same IP address, or if you have multiple users running off the same
server.) The session management capability in the servlet API provides a mechanism for
establishing this kind of connection between requests, and requires sending the client
an identifier (using either cookies or URL rewriting) that the client can send back on
the next request.
In Struts specifically, the following uses are made of sessions:
* You can store the ActionForm bean in the session or the request.
If your bean supports multi-page input, session is the only way
to save the values from the previous page(s). For single page
forms, request scope works fine.
* Struts expects a per-user Locale to represent the users's choice
of language and display styles for internationalized messages.
Generally, if this object is not present, the server's default Locale
will be used.
In web applications based on servlets and JSP pages in general (including those based on
Struts), you also have the following issues to think about:
* By default, JSP pages assume that they are part of a session.
If you don't want this, you have to put the following code at the
top of every single page:
<%@ page ... session="false" ... %>
* Many applications perform their own authentication and login
to make sure that only validated users can access certain
parts of the application. The usual mechanism for doing this is
to store some sort of user object in the user's session -- if you
detect that this object is missing (because the user tried to jump
into the middle of your app without logging in, or because their
previous session timed out), you force them to the login page.
Without sessions, this will be very difficult to implement
in a robust manner.
* Without sessions, you are limited to transactions that can be
completed solely based on the request parameters of a single
individual request, since you have no way to link more than one
request together.
* Many sites like to personalize the appearance of their apps
based on who the user is, or what preferences they have saved.
Beyond the authentication issue mentioned earlier, most such
apps save the user's current preferences in a session variable
to save having to go back to the database every request. This can
be a significant performance impact.
So are sessions worth it? Well, that depends on the cost, as we'll see in the next
question ....
(2) What Are The Performance Impacts of Sessions?
If you have looked at very many of the Java "standard extensions" APIs, you will note
that most of them define Java interfaces (and associated contracts documented in the
spec and the Javadocs) that a particular implementation of that API must conform to, but
they give the implementers a fair degree of freedom in *how* to conform to the
requirements. Thus, there is no general answer to the question "how does a servlet
container implement the HttpSession interface."
However, it is worthwhile looking at the way Tomcat handles this -- most of the
containers I'm familiar with do something similar.
Inside of Tomcat, the set of active sessions associated with a part of a web application
are instances of the class org.apache.tomcat.session.StandardSession, which has a few
small instance variables and a Hashtable to contain the user's session beans. For a
session with no session attributes, this is probably something on the order of 50 bytes
of memory usage in the JVM's heap (why no precise answer? well, it depends on the
implementation of the JVM ....). Tomcat also maintains a Hashtable of all the active
sessions at any given point in time, inside a component called the "Manager".
Individual sessions can store any number of session-scoped beans (JSP terminology). The
memory occupancy of those beans is totally dependent on the instance variables in that
bean (there's only one memory copy of the bytecodes of any class in Java, so how much
code there is has almost zero impact). Note that you, as the developer, have total
control over adding and *removing* these objects. For example, as soon as you are done
with a particular ActionForm bean in a Struts application, you should remove it from the
session (in the Action class that received the final copy of the form) so that it can be
garbage collected. There's no reason to keep it around any longer than that.
Hashtables have the nice property that they support keyed access to even large numbers
of objects with fairly linear response times. Thus, it makes almost no difference (from
a CPU time point of view) how many active sessions there are, or how many session scope
beans you have in a particular sesison.
In general, you will run into performance issues on your database and network long
before you run out of CPU time -- unless your app is particularly CPU-intensive, so your
mileage may vary.
The bottom line -- if you don't need to maintain any state information across requests
from the same user, you don't need sessions. If you do need this, sessions are a pretty
cheap way to meet that need. What you need to do is plan the memory requirements
appropriately (peak # of active sessions * peak memory for session scope beans, if you
want to be conservative).
Craig McClanahan
Struts and Sessions
Posted by Colin Wilson-Salt <co...@london.virgin.net>.
Would it be possible to make the use of sessions in Struts optional?
I'm concerned about the resource overhead if we have a lot of people visiting just a
few pages in our site.
We already build applications using the same kind of patterns that Struts uses, but
it would be nice to have the benefits of the formalised structure that Struts gives.
On the other hand, does anyone have any evidence that the resource overhead of
sessions is something I shouldn't be concernced about?
RE: Read only tag attributes?
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> > Already checked this. It has two setSize() methods, one for
> int's and one
> > for String's. I have a sneaking suspicion this may be the problem (two
> > methods) as I know the spec is very vague about whether this sort of
> > overloading is allowed.
> >
>
> I think you're right ... Depending on how Orion chooses to implement bean
> introspection, it's entirely possible that it will decide there
> is no setter
> method there (even though there are two of them) and thus decide
> that the bean
> is read-only.
>
> I really should not have two setters -- and I suspect there are
> problems on some
> containers if there is only the "int" version of the setter
> (which is the way it
> really should be). I will do some experiments and try to correct
> this ASAP.
>
> >
> > Have you got the text tag working under Orion? If so the above
> can't be the
> > problem. What about the struts-example?
> >
>
> What's puzzling to me is why Kevin didn't run into this. Are you
> guys running
> the same versions of Orion? How about JVMs?
I'll clear this up. I never used the tag. :) I merely was responding to what
I thought might be the problem. Sorry to confuse you.
Re: Read only tag attributes?
Posted by Eduardo Pelegri--Llopart <Ed...@eng.sun.com>.
check the errata # 6 in
http://java.sun.com/products/jsp/errata_1_1_a_042800.html
- eduard/o
Mike Cannon-Brookes wrote:
>
> > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> >
> > Mike Cannon-Brookes wrote:
> >
> > > Kevin,
> > >
> > > Already checked this. It has two setSize() methods, one for
> > int's and one
> > > for String's. I have a sneaking suspicion this may be the problem (two
> > > methods) as I know the spec is very vague about whether this sort of
> > > overloading is allowed.
> > >
> >
> > I think you're right ... Depending on how Orion chooses to implement bean
> > introspection, it's entirely possible that it will decide there
> > is no setter
> > method there (even though there are two of them) and thus decide
> > that the bean
> > is read-only.
> >
> > I really should not have two setters -- and I suspect there are
> > problems on some
> > containers if there is only the "int" version of the setter
> > (which is the way it
> > really should be). I will do some experiments and try to correct
> > this ASAP.
> >
> > >
> > > Have you got the text tag working under Orion? If so the above
> > can't be the
> > > problem. What about the struts-example?
> > >
> >
> > What's puzzling to me is why Kevin didn't run into this. Are you
> > guys running
> > the same versions of Orion? How about JVMs?
> >
>
> The oddest thing is that I installed an older version at home last night and
> the example didn't die at that point. (Incidentally it threw up trying to
> add a mail host). At home I installed the build from the 19th of June (no
> read only error), and at work I installed the build from 25th June (has a
> readonly error) - what has changed between these two dates with the TextTag?
> (Or any of it's superclasses?)
>
> Should give you a big headstart on finding the problem!
>
> Mike
RE: Read only tag attributes?
Posted by Mike Cannon-Brookes <mi...@bookmarkbox.com>.
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
>
> Mike Cannon-Brookes wrote:
>
> > Kevin,
> >
> > Already checked this. It has two setSize() methods, one for
> int's and one
> > for String's. I have a sneaking suspicion this may be the problem (two
> > methods) as I know the spec is very vague about whether this sort of
> > overloading is allowed.
> >
>
> I think you're right ... Depending on how Orion chooses to implement bean
> introspection, it's entirely possible that it will decide there
> is no setter
> method there (even though there are two of them) and thus decide
> that the bean
> is read-only.
>
> I really should not have two setters -- and I suspect there are
> problems on some
> containers if there is only the "int" version of the setter
> (which is the way it
> really should be). I will do some experiments and try to correct
> this ASAP.
>
> >
> > Have you got the text tag working under Orion? If so the above
> can't be the
> > problem. What about the struts-example?
> >
>
> What's puzzling to me is why Kevin didn't run into this. Are you
> guys running
> the same versions of Orion? How about JVMs?
>
The oddest thing is that I installed an older version at home last night and
the example didn't die at that point. (Incidentally it threw up trying to
add a mail host). At home I installed the build from the 19th of June (no
read only error), and at work I installed the build from 25th June (has a
readonly error) - what has changed between these two dates with the TextTag?
(Or any of it's superclasses?)
Should give you a big headstart on finding the problem!
Mike
Re: Read only tag attributes?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Mike Cannon-Brookes wrote:
> Kevin,
>
> Already checked this. It has two setSize() methods, one for int's and one
> for String's. I have a sneaking suspicion this may be the problem (two
> methods) as I know the spec is very vague about whether this sort of
> overloading is allowed.
>
I think you're right ... Depending on how Orion chooses to implement bean
introspection, it's entirely possible that it will decide there is no setter
method there (even though there are two of them) and thus decide that the bean
is read-only.
I really should not have two setters -- and I suspect there are problems on some
containers if there is only the "int" version of the setter (which is the way it
really should be). I will do some experiments and try to correct this ASAP.
>
> Have you got the text tag working under Orion? If so the above can't be the
> problem. What about the struts-example?
>
What's puzzling to me is why Kevin didn't run into this. Are you guys running
the same versions of Orion? How about JVMs?
>
> Mike
>
Craig
RE: Read only tag attributes?
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
I haven't tried using it myself..Craig is probably the one to ask about
that. I would think only one method is allowed..but it is a taglib, not a
setter method for a javabean, so its possible it is allowed in the taglib
itself.
> Kevin,
>
> Already checked this. It has two setSize() methods, one for int's and one
> for String's. I have a sneaking suspicion this may be the problem (two
> methods) as I know the spec is very vague about whether this sort of
> overloading is allowed.
>
> Have you got the text tag working under Orion? If so the above
> can't be the
> problem. What about the struts-example?
>
> Mike
>
> -----Original Message-----
> From: Kevin Duffey [mailto:kduffey@buymedia.com]
> > Deployed all the WARs with Orion now - my last instructions should work
> > perfectly.
> >
> > However when accessing the registration page I get:
> >
> > "Error parsing JSP page /registration.jsp line 32
> > Property 'size' of bean/tag 'org.apache.struts.taglib.TextTag' is
> > read only"
> >
> > Any Struts / Orion users ever seen it? I've used custom tags
> > under Orion for
> > ages and this one has me baffled.
>
> I bet the code for the taglib doesn't have a set method in the taglib code
> that matches the attribute name. Look at the source of TextTag
> and see if it
> has a setSize() method..it could be mispelled or something. Or,
> maybe Craig
> meant for it to be this way.
>
>
RE: Read only tag attributes?
Posted by Mike Cannon-Brookes <mc...@internet.com>.
Kevin,
Already checked this. It has two setSize() methods, one for int's and one
for String's. I have a sneaking suspicion this may be the problem (two
methods) as I know the spec is very vague about whether this sort of
overloading is allowed.
Have you got the text tag working under Orion? If so the above can't be the
problem. What about the struts-example?
Mike
-----Original Message-----
From: Kevin Duffey [mailto:kduffey@buymedia.com]
> Deployed all the WARs with Orion now - my last instructions should work
> perfectly.
>
> However when accessing the registration page I get:
>
> "Error parsing JSP page /registration.jsp line 32
> Property 'size' of bean/tag 'org.apache.struts.taglib.TextTag' is
> read only"
>
> Any Struts / Orion users ever seen it? I've used custom tags
> under Orion for
> ages and this one has me baffled.
I bet the code for the taglib doesn't have a set method in the taglib code
that matches the attribute name. Look at the source of TextTag and see if it
has a setSize() method..it could be mispelled or something. Or, maybe Craig
meant for it to be this way.
RE: Read only tag attributes?
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> Deployed all the WARs with Orion now - my last instructions should work
> perfectly.
>
> However when accessing the registration page I get:
>
> "Error parsing JSP page /registration.jsp line 32
> Property 'size' of bean/tag 'org.apache.struts.taglib.TextTag' is
> read only"
>
> Any Struts / Orion users ever seen it? I've used custom tags
> under Orion for
> ages and this one has me baffled.
I bet the code for the taglib doesn't have a set method in the taglib code
that matches the attribute name. Look at the source of TextTag and see if it
has a setSize() method..it could be mispelled or something. Or, maybe Craig
meant for it to be this way.
Read only tag attributes?
Posted by Mike Cannon-Brookes <mc...@internet.com>.
G'day all,
Deployed all the WARs with Orion now - my last instructions should work
perfectly.
However when accessing the registration page I get:
"Error parsing JSP page /registration.jsp line 32
Property 'size' of bean/tag 'org.apache.struts.taglib.TextTag' is read only"
Any Struts / Orion users ever seen it? I've used custom tags under Orion for
ages and this one has me baffled.
Mike
Re: Struts with Orion
Posted by Wong Kok Wai <wo...@pacific.net.sg>.
How about checking the instructions int the CVS as part of Struts' documentation? There's one
already for Tomcat. I think your post would most helpful for lots of people. I like to get Struts
running on Weblogic too, any instructions for this?
Kevin Duffey wrote:
> Hi,
>
> Yeah..I had a little bit of a problem too with Orion.
RE: Struts with Orion
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
I am running Orion with Struts now..no problems. For those just joining, I
will inform you that Orion has one caveat that prevents Struts from working
properly, and that is that Orion does not allow a servlet container access
to the /WEB-INF dir. I spoke extensively to Magnus, one of the orion
developers, and his feeling is that the way the 9.4 section explains
it..that nothing is to SERVER the WEB-INF dir, not even a servlet container
is allowed. However, I talked with Craig (the Struts mastermind) and he
informed me that Danny Coward..the Servlet 2.2 spec lead, says that a
servlet container CAN access WEB-INF, so at this point, its a problem that
is being addressed by the Orion team. The general concensus I got from a
number of developers is that the WEB-INF should be off limits and thus Orion
is correct. However, Orion is the only Servlet 2.2 container I have worked
with that has this problem..everyone else seems to allow it, so the hope
here is that a new patch of Orion 1.0 comes out with access to it enabled.
There may alread be one now..I haven't downloaded in some time.
I too will brag about Orion..I have been using it for 8 months and its by
far the best piece of software I have seen in a long time..at least in the
way of web app related items. It amazes me that a small team created Orion
so fast, and meanwhile the big boys, like WebLogic, WebSphere, etc are
lagging in full support of J2EE. Ofcourse, the downside is Orion has
terrible documentation right now, and it doesn't give you much else in the
way of tools. My company is moving to WebLogic, and at $25K per cpu, its a
MUCH MUCH MUCH larger investment than Orion, at $1500 per server. For all
the bells and whistles you get from WebLogic and others, I would never pay
that kind of money just because they have 1000+ employees, backing, etc..but
that is why I am a developer and not a business man. ;)
Struts is very easy to use once you get it running, and its almost very easy
to get running. I am sure the problem with Orion is what slowed me down,
that and understanding the framework and how to use it. There is alot I
don't use with it yet, but what I am using I am very pleased with. My site
that I am converting to it is much more solid, and much faster for me to
develop as well.
> This is a little more complex than it needs to be. I know how frustrating
> Orion is, I'm on of the first handful over users - been there since
> 0.5something and know the whole development team very well. It is truly a
> brilliant piece of software, don't write it off too soon on account of the
> documentation (which is coming along in leaps and bounds now that 1.0 is
> 'feature stable'). If you need help, try the Orion-Interest list where
> Orion-devotee's are usually very helpful.
>
> With your case, there's no need to create an entire application just to
> deploy one WAR file - you can deploy it as a web module of the default
> global application (finding this out is very difficult I know).
>
> In config/application.xml add a line:
> <web-module id="strutsExampleWebApp"
> path="c:\struts\struts-example.war" />
>
> Now to config/default-web-site.xml add (or any other web-site.xml file if
> you want to deploy it separately from the default web site):
> <web-app application="default" name="strutsExampleWebApp"
> root="/strutsExample" />
>
> Now localhost/strutsExample will have your struts example app -
> without the
> hassle of creating an EAR.
>
> Hope this helps everyone,
> Feel free to ask me questions on setting up Orion w/ Struts, I'm
> about to do
> it ;)
>
> Cheers,
> Mike
>
> -----Original Message-----
> From: Philip Eskelin [mailto:philip@eskelin.com]
> Sent: Monday, June 26, 2000 12:51 PM
> To: struts-user@jakarta.apache.org; Kevin Duffey
> Subject: RE: Struts with Orion
>
>
>
> I got both applications working. The problem I ran into is that Orion
> needed to be tweaked some more to make it work. For example, in
> global-web-application.xml I needed to change the
> welcome-file-list so that
> it used index.jsp instead of default.jsp as its JSP welcome.
> Also, I needed
> to put tools.jar into the base Orion directory. Finally, I needed to put
> the .war into an .ear and add an application.xml to the meta-inf directory
> that describes the .war module.
>
> The structure looks like this:
>
> struts-example.ear
> meta-inf
> application.xml - describes www.war
> www.war - struts-example.war with Kevin's updates
> meta-inf
> web-inf
> etc.
>
> One of the things I hope Struts gets down is that the documentation
> accurately maps to successfully using it. One of the
> frustrations I've ran
> into with Orion is that it's a wonderfully cool piece of software, but the
> docs seem to be out of sync with the app. E.g., I followed their steps
> exactly as documented to get Hypersonic SQL working and it doesn't work.
>
> The suggestion for Struts would be that the docs should start
> with the user
> installing Orion and documents all the steps required to make it work with
> the included apps (struts-example and struts-documentation). Heck, maybe
> I'll join the project and do it myself ;-)
>
> Phil
>
> > -----Original Message-----
> > From: Philip Eskelin [mailto:philip@eskelin.com]
> > Sent: Sunday, June 25, 2000 8:44 PM
> > To: Kevin Duffey; struts-user@jakarta.apache.org
> > Subject: RE: Struts with Orion
> >
> >
> > Kevin,
> >
> > Thanks much for the reply -- I too like Orion a lot and think
> > it's theme of
> > never shutting down the server is where things need to be. I'm
> trying to
> > get struts-example and struts-documentation to work in Orion.
> Neither of
> > these projects have an app or www directory -- just META-INF and
> > WEB-INF at
> > the base of the .war file. So where would you put action.xml in
> > this case?
> > I'll play around and thanks in advance for any additional suggestions.
> >
> > Regards,
> > Philip
> >
> > > -----Original Message-----
> > > From: Kevin Duffey [mailto:kduffey@buymedia.com]
> > > Sent: Sunday, June 25, 2000 2:10 AM
> > > To: struts-user@jakarta.apache.org; philip@eskelin.com
> > > Subject: RE: Struts with Orion
> > >
> > >
> > > Hi,
> > >
> > > Yeah..I had a little bit of a problem too with Orion. As it turns
> > > out, Orion
> > > does NOT allow the servlet container serlvets to access anything
> > > in WEB-INF
> > > dir, so the examples were not working. However, I am using Struts
> > > with Orion
> > > 1.0 release just fine. What I had to do is move action.xml into my www
> > > folder (of my .WAR directory structure), and I did put
> struts.tld in the
> > > WEB-INF dir, compiled my code to WEB-INF/classes, and put
> > > struts.jar in the
> > > WEB-INF/lib dir.
> > >
> > > app/www/action.xml - struts config file
> > > app/www/WEB-INF/classes - compiled class code (Servlets,
> javabeans, core
> > > classes, etc)
> > > app/www/WEB-INF/lib/struts.jar - struts library
> > > app/www/WEB-INF/struts.tld - struts tag-lib library
> > >
> > > Also, I have the following in web.xml for Orion specifically:
> > >
> > > <?xml version="1.0"?>
> > > <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
> Application
> > > 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
> > >
> > > <web-app>
> > > <servlet>
> > > <servlet-name>action</servlet-name>
> > > <display-name>action</display-name>
> > >
> > > <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
> > > <init-param>
> > > <param-name>mapping</param-name>
> > >
> > > <param-value>org.apache.struts.action.ActionMappingBase</param-value>
> > > </init-param>
> > > <init-param>
> > > <param-name>application</param-name>
> > >
> > > <param-value>org.apache.struts.action.ActionResources</param-value>
> > > </init-param>
> > > <init-param>
> > > <param-name>config</param-name>
> > > <param-value>/action.xml</param-value>
> > > </init-param>
> > > <init-param>
> > > <param-name>debug</param-name>
> > > <param-value>0</param-value>
> > > </init-param>
> > > </servlet>
> > > <servlet-mapping>
> > > <servlet-name>action</servlet-name>
> > > <url-pattern>*.do</url-pattern>
> > > </servlet-mapping>
> > > <welcome-file-list>
> > > <welcome-file>index.jsp</welcome-file>
> > > </welcome-file-list>
> > > <taglib>
> > > <taglib-uri>/config/struts.tld</taglib-uri>
> > > <taglib-location>/WEB-INF/struts.tld</taglib-location>
> > > </taglib>
> > > <taglib>
> > > <taglib-uri>/config/bm.tld</taglib-uri>
> > > <taglib-location>/WEB-INF/bm.tld</taglib-location>
> > > </taglib>
> > > <login-config>
> > > <auth-method>BASIC</auth-method>
> > > </login-config>
> > > </web-app>
> > >
> > >
> > > Make sure you use the init-param for CONFIG and set the value to
> > > /action.xml. It defaults to /WEB-INF/action.xml, and that won't work
> > > presently with Orion.
> > >
> > > As to why this is happening, their is a misunderstanding of the
> > > servlet 2.2
> > > spec of the WAR format. A number of developers including the
> Orion team
> > > believe the spec means that the servlet container can NOT server
> > > anything in
> > > the WEB-INF dir, even to its own servlets..thus they are not
> allowed to
> > > access the WEB-INF dir. The code in Struts..I forget exactly..but
> > > I believe
> > > it uses getResource() call to get the xml config file loaded,
> > and that is
> > > what Orion is preventing from working. I did talk with the
> > Orion team and
> > > they are looking into the specific meaning of the WEB-INF
> > > structure. Craig,
> > > the developer of Struts has informed me that Danny Coward, the
> > lead on the
> > > servlet 2.2 spec confirms that the WEB-INF dir is accessible via
> > > the servlet
> > > container. Tomcat supports this, and Craig is part of the
> Apache/Jakarta
> > > project..which uses Tomcat for development (is this right Craig? ;).
> > >
> > > Other servlet engines including JRUN, Resing and WebLogic do
> > allow WEB-INF
> > > access, so I think Orion will change to allow this. They are
> > > working on EJB
> > > 2.0, admin tools, and Serlvete 2.3, JSP 1.2 already for Orion,
> > so I don't
> > > know if they will add this to 1.0 (update), or later versions for
> > > those that
> > > want to start using the new features Orion already implements
> (which is
> > > going to be part of J2EE 1.3).
> > >
> > > Oh yeah..I set up an application with a META-INF dir too..but you
> > > can deploy
> > > just a .war or an expanded WAR formatted dir structure as well.
> > >
> > > If you have any trouble..feel free to ask. I use Orion
> > > exclusively as its by
> > > far the best product I have seen, especially considering the price,
> > > performance and feature set. It may not package development tools
> > > and fancy
> > > GUI tools, but it is certainly the easiest app server I have
> > ever set up,
> > > and its performance thus far is much higher than every other
> > engine I have
> > > tried (WebLogic, IIS/JRUN, ServletExec, Resin, Apache/JServ).
> > > Resin is very
> > > fast too..but Orion is slightly ahead of it..and it supports full J2EE
> > > deployment.
> > >
> > > Hope that helps.
> > >
> >
>
>
>
RE: Struts with Orion
Posted by Mike Cannon-Brookes <mc...@internet.com>.
This is a little more complex than it needs to be. I know how frustrating
Orion is, I'm on of the first handful over users - been there since
0.5something and know the whole development team very well. It is truly a
brilliant piece of software, don't write it off too soon on account of the
documentation (which is coming along in leaps and bounds now that 1.0 is
'feature stable'). If you need help, try the Orion-Interest list where
Orion-devotee's are usually very helpful.
With your case, there's no need to create an entire application just to
deploy one WAR file - you can deploy it as a web module of the default
global application (finding this out is very difficult I know).
In config/application.xml add a line:
<web-module id="strutsExampleWebApp" path="c:\struts\struts-example.war" />
Now to config/default-web-site.xml add (or any other web-site.xml file if
you want to deploy it separately from the default web site):
<web-app application="default" name="strutsExampleWebApp"
root="/strutsExample" />
Now localhost/strutsExample will have your struts example app - without the
hassle of creating an EAR.
Hope this helps everyone,
Feel free to ask me questions on setting up Orion w/ Struts, I'm about to do
it ;)
Cheers,
Mike
-----Original Message-----
From: Philip Eskelin [mailto:philip@eskelin.com]
Sent: Monday, June 26, 2000 12:51 PM
To: struts-user@jakarta.apache.org; Kevin Duffey
Subject: RE: Struts with Orion
I got both applications working. The problem I ran into is that Orion
needed to be tweaked some more to make it work. For example, in
global-web-application.xml I needed to change the welcome-file-list so that
it used index.jsp instead of default.jsp as its JSP welcome. Also, I needed
to put tools.jar into the base Orion directory. Finally, I needed to put
the .war into an .ear and add an application.xml to the meta-inf directory
that describes the .war module.
The structure looks like this:
struts-example.ear
meta-inf
application.xml - describes www.war
www.war - struts-example.war with Kevin's updates
meta-inf
web-inf
etc.
One of the things I hope Struts gets down is that the documentation
accurately maps to successfully using it. One of the frustrations I've ran
into with Orion is that it's a wonderfully cool piece of software, but the
docs seem to be out of sync with the app. E.g., I followed their steps
exactly as documented to get Hypersonic SQL working and it doesn't work.
The suggestion for Struts would be that the docs should start with the user
installing Orion and documents all the steps required to make it work with
the included apps (struts-example and struts-documentation). Heck, maybe
I'll join the project and do it myself ;-)
Phil
> -----Original Message-----
> From: Philip Eskelin [mailto:philip@eskelin.com]
> Sent: Sunday, June 25, 2000 8:44 PM
> To: Kevin Duffey; struts-user@jakarta.apache.org
> Subject: RE: Struts with Orion
>
>
> Kevin,
>
> Thanks much for the reply -- I too like Orion a lot and think
> it's theme of
> never shutting down the server is where things need to be. I'm trying to
> get struts-example and struts-documentation to work in Orion. Neither of
> these projects have an app or www directory -- just META-INF and
> WEB-INF at
> the base of the .war file. So where would you put action.xml in
> this case?
> I'll play around and thanks in advance for any additional suggestions.
>
> Regards,
> Philip
>
> > -----Original Message-----
> > From: Kevin Duffey [mailto:kduffey@buymedia.com]
> > Sent: Sunday, June 25, 2000 2:10 AM
> > To: struts-user@jakarta.apache.org; philip@eskelin.com
> > Subject: RE: Struts with Orion
> >
> >
> > Hi,
> >
> > Yeah..I had a little bit of a problem too with Orion. As it turns
> > out, Orion
> > does NOT allow the servlet container serlvets to access anything
> > in WEB-INF
> > dir, so the examples were not working. However, I am using Struts
> > with Orion
> > 1.0 release just fine. What I had to do is move action.xml into my www
> > folder (of my .WAR directory structure), and I did put struts.tld in the
> > WEB-INF dir, compiled my code to WEB-INF/classes, and put
> > struts.jar in the
> > WEB-INF/lib dir.
> >
> > app/www/action.xml - struts config file
> > app/www/WEB-INF/classes - compiled class code (Servlets, javabeans, core
> > classes, etc)
> > app/www/WEB-INF/lib/struts.jar - struts library
> > app/www/WEB-INF/struts.tld - struts tag-lib library
> >
> > Also, I have the following in web.xml for Orion specifically:
> >
> > <?xml version="1.0"?>
> > <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
> > 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
> >
> > <web-app>
> > <servlet>
> > <servlet-name>action</servlet-name>
> > <display-name>action</display-name>
> >
> > <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
> > <init-param>
> > <param-name>mapping</param-name>
> >
> > <param-value>org.apache.struts.action.ActionMappingBase</param-value>
> > </init-param>
> > <init-param>
> > <param-name>application</param-name>
> >
> > <param-value>org.apache.struts.action.ActionResources</param-value>
> > </init-param>
> > <init-param>
> > <param-name>config</param-name>
> > <param-value>/action.xml</param-value>
> > </init-param>
> > <init-param>
> > <param-name>debug</param-name>
> > <param-value>0</param-value>
> > </init-param>
> > </servlet>
> > <servlet-mapping>
> > <servlet-name>action</servlet-name>
> > <url-pattern>*.do</url-pattern>
> > </servlet-mapping>
> > <welcome-file-list>
> > <welcome-file>index.jsp</welcome-file>
> > </welcome-file-list>
> > <taglib>
> > <taglib-uri>/config/struts.tld</taglib-uri>
> > <taglib-location>/WEB-INF/struts.tld</taglib-location>
> > </taglib>
> > <taglib>
> > <taglib-uri>/config/bm.tld</taglib-uri>
> > <taglib-location>/WEB-INF/bm.tld</taglib-location>
> > </taglib>
> > <login-config>
> > <auth-method>BASIC</auth-method>
> > </login-config>
> > </web-app>
> >
> >
> > Make sure you use the init-param for CONFIG and set the value to
> > /action.xml. It defaults to /WEB-INF/action.xml, and that won't work
> > presently with Orion.
> >
> > As to why this is happening, their is a misunderstanding of the
> > servlet 2.2
> > spec of the WAR format. A number of developers including the Orion team
> > believe the spec means that the servlet container can NOT server
> > anything in
> > the WEB-INF dir, even to its own servlets..thus they are not allowed to
> > access the WEB-INF dir. The code in Struts..I forget exactly..but
> > I believe
> > it uses getResource() call to get the xml config file loaded,
> and that is
> > what Orion is preventing from working. I did talk with the
> Orion team and
> > they are looking into the specific meaning of the WEB-INF
> > structure. Craig,
> > the developer of Struts has informed me that Danny Coward, the
> lead on the
> > servlet 2.2 spec confirms that the WEB-INF dir is accessible via
> > the servlet
> > container. Tomcat supports this, and Craig is part of the Apache/Jakarta
> > project..which uses Tomcat for development (is this right Craig? ;).
> >
> > Other servlet engines including JRUN, Resing and WebLogic do
> allow WEB-INF
> > access, so I think Orion will change to allow this. They are
> > working on EJB
> > 2.0, admin tools, and Serlvete 2.3, JSP 1.2 already for Orion,
> so I don't
> > know if they will add this to 1.0 (update), or later versions for
> > those that
> > want to start using the new features Orion already implements (which is
> > going to be part of J2EE 1.3).
> >
> > Oh yeah..I set up an application with a META-INF dir too..but you
> > can deploy
> > just a .war or an expanded WAR formatted dir structure as well.
> >
> > If you have any trouble..feel free to ask. I use Orion
> > exclusively as its by
> > far the best product I have seen, especially considering the price,
> > performance and feature set. It may not package development tools
> > and fancy
> > GUI tools, but it is certainly the easiest app server I have
> ever set up,
> > and its performance thus far is much higher than every other
> engine I have
> > tried (WebLogic, IIS/JRUN, ServletExec, Resin, Apache/JServ).
> > Resin is very
> > fast too..but Orion is slightly ahead of it..and it supports full J2EE
> > deployment.
> >
> > Hope that helps.
> >
>
RE: Struts with Orion
Posted by Philip Eskelin <ph...@eskelin.com>.
I got both applications working. The problem I ran into is that Orion
needed to be tweaked some more to make it work. For example, in
global-web-application.xml I needed to change the welcome-file-list so that
it used index.jsp instead of default.jsp as its JSP welcome. Also, I needed
to put tools.jar into the base Orion directory. Finally, I needed to put
the .war into an .ear and add an application.xml to the meta-inf directory
that describes the .war module.
The structure looks like this:
struts-example.ear
meta-inf
application.xml - describes www.war
www.war - struts-example.war with Kevin's updates
meta-inf
web-inf
etc.
One of the things I hope Struts gets down is that the documentation
accurately maps to successfully using it. One of the frustrations I've ran
into with Orion is that it's a wonderfully cool piece of software, but the
docs seem to be out of sync with the app. E.g., I followed their steps
exactly as documented to get Hypersonic SQL working and it doesn't work.
The suggestion for Struts would be that the docs should start with the user
installing Orion and documents all the steps required to make it work with
the included apps (struts-example and struts-documentation). Heck, maybe
I'll join the project and do it myself ;-)
Phil
> -----Original Message-----
> From: Philip Eskelin [mailto:philip@eskelin.com]
> Sent: Sunday, June 25, 2000 8:44 PM
> To: Kevin Duffey; struts-user@jakarta.apache.org
> Subject: RE: Struts with Orion
>
>
> Kevin,
>
> Thanks much for the reply -- I too like Orion a lot and think
> it's theme of
> never shutting down the server is where things need to be. I'm trying to
> get struts-example and struts-documentation to work in Orion. Neither of
> these projects have an app or www directory -- just META-INF and
> WEB-INF at
> the base of the .war file. So where would you put action.xml in
> this case?
> I'll play around and thanks in advance for any additional suggestions.
>
> Regards,
> Philip
>
> > -----Original Message-----
> > From: Kevin Duffey [mailto:kduffey@buymedia.com]
> > Sent: Sunday, June 25, 2000 2:10 AM
> > To: struts-user@jakarta.apache.org; philip@eskelin.com
> > Subject: RE: Struts with Orion
> >
> >
> > Hi,
> >
> > Yeah..I had a little bit of a problem too with Orion. As it turns
> > out, Orion
> > does NOT allow the servlet container serlvets to access anything
> > in WEB-INF
> > dir, so the examples were not working. However, I am using Struts
> > with Orion
> > 1.0 release just fine. What I had to do is move action.xml into my www
> > folder (of my .WAR directory structure), and I did put struts.tld in the
> > WEB-INF dir, compiled my code to WEB-INF/classes, and put
> > struts.jar in the
> > WEB-INF/lib dir.
> >
> > app/www/action.xml - struts config file
> > app/www/WEB-INF/classes - compiled class code (Servlets, javabeans, core
> > classes, etc)
> > app/www/WEB-INF/lib/struts.jar - struts library
> > app/www/WEB-INF/struts.tld - struts tag-lib library
> >
> > Also, I have the following in web.xml for Orion specifically:
> >
> > <?xml version="1.0"?>
> > <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
> > 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
> >
> > <web-app>
> > <servlet>
> > <servlet-name>action</servlet-name>
> > <display-name>action</display-name>
> >
> > <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
> > <init-param>
> > <param-name>mapping</param-name>
> >
> > <param-value>org.apache.struts.action.ActionMappingBase</param-value>
> > </init-param>
> > <init-param>
> > <param-name>application</param-name>
> >
> > <param-value>org.apache.struts.action.ActionResources</param-value>
> > </init-param>
> > <init-param>
> > <param-name>config</param-name>
> > <param-value>/action.xml</param-value>
> > </init-param>
> > <init-param>
> > <param-name>debug</param-name>
> > <param-value>0</param-value>
> > </init-param>
> > </servlet>
> > <servlet-mapping>
> > <servlet-name>action</servlet-name>
> > <url-pattern>*.do</url-pattern>
> > </servlet-mapping>
> > <welcome-file-list>
> > <welcome-file>index.jsp</welcome-file>
> > </welcome-file-list>
> > <taglib>
> > <taglib-uri>/config/struts.tld</taglib-uri>
> > <taglib-location>/WEB-INF/struts.tld</taglib-location>
> > </taglib>
> > <taglib>
> > <taglib-uri>/config/bm.tld</taglib-uri>
> > <taglib-location>/WEB-INF/bm.tld</taglib-location>
> > </taglib>
> > <login-config>
> > <auth-method>BASIC</auth-method>
> > </login-config>
> > </web-app>
> >
> >
> > Make sure you use the init-param for CONFIG and set the value to
> > /action.xml. It defaults to /WEB-INF/action.xml, and that won't work
> > presently with Orion.
> >
> > As to why this is happening, their is a misunderstanding of the
> > servlet 2.2
> > spec of the WAR format. A number of developers including the Orion team
> > believe the spec means that the servlet container can NOT server
> > anything in
> > the WEB-INF dir, even to its own servlets..thus they are not allowed to
> > access the WEB-INF dir. The code in Struts..I forget exactly..but
> > I believe
> > it uses getResource() call to get the xml config file loaded,
> and that is
> > what Orion is preventing from working. I did talk with the
> Orion team and
> > they are looking into the specific meaning of the WEB-INF
> > structure. Craig,
> > the developer of Struts has informed me that Danny Coward, the
> lead on the
> > servlet 2.2 spec confirms that the WEB-INF dir is accessible via
> > the servlet
> > container. Tomcat supports this, and Craig is part of the Apache/Jakarta
> > project..which uses Tomcat for development (is this right Craig? ;).
> >
> > Other servlet engines including JRUN, Resing and WebLogic do
> allow WEB-INF
> > access, so I think Orion will change to allow this. They are
> > working on EJB
> > 2.0, admin tools, and Serlvete 2.3, JSP 1.2 already for Orion,
> so I don't
> > know if they will add this to 1.0 (update), or later versions for
> > those that
> > want to start using the new features Orion already implements (which is
> > going to be part of J2EE 1.3).
> >
> > Oh yeah..I set up an application with a META-INF dir too..but you
> > can deploy
> > just a .war or an expanded WAR formatted dir structure as well.
> >
> > If you have any trouble..feel free to ask. I use Orion
> > exclusively as its by
> > far the best product I have seen, especially considering the price,
> > performance and feature set. It may not package development tools
> > and fancy
> > GUI tools, but it is certainly the easiest app server I have
> ever set up,
> > and its performance thus far is much higher than every other
> engine I have
> > tried (WebLogic, IIS/JRUN, ServletExec, Resin, Apache/JServ).
> > Resin is very
> > fast too..but Orion is slightly ahead of it..and it supports full J2EE
> > deployment.
> >
> > Hope that helps.
> >
>
RE: Struts with Orion
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> I agree for the README. But to validate what I write, it would
> sure be nice if
> there was a cookbook for adding a deploying a web app on Orion.
> I'm sure it's
> there in the docs, but it was not obvious to me on first reading.
>
> What Orion config files to you have to change?????
Well, generally you can add a web app by just putting in a <web-app..> tag
in the confid/default-web-app.xml file. But I am not one to keep my files in
the servers dir structure. How about this..I'll cook up a simple little WAR
app that is specific to Orion, with instructions on how to deploy it in
Orion 1.0. It may take a couple of days as I am very busy (usually writing
emails to the Struts list. ;), but it should be a simple app, a couple of
pages with web.xml, struts in it, etc. You don't mind me putting the
struts.jar and tld and action.xml in the jar do you?
Re: Struts with Orion
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> Hi,
>
> I'll give you a "quick" one right now. However, what I don't think you
> should have to do in your readme is tell people how to install Orion
> properly, including figuring out getting an app to work. That is part of the
> Orion team's job. You should only be concerned with Struts with Orion.
>
I agree for the README. But to validate what I write, it would sure be nice if
there was a cookbook for adding a deploying a web app on Orion. I'm sure it's
there in the docs, but it was not obvious to me on first reading.
What Orion config files to you have to change?????
Craig
>
> So far, its very simple.
>
> - Download Struts
> - Unzip.
> - Move struts.jar into a web app's /WEB-INF/lib dir
> - Move struts.tld into a web app's /WEB-INF dir
> - Move actions.xml into a web app's "root" (www) dir
>
> Thats it. At least for me..it worked fine. I think the biggest problem right
> now is that most people are having a hard time getting Orion to work. Its
> easy once you figure it out (or get help) but until that time, their docs
> aren't that great in detail as to how to get it running for a web app (WAR),
> or an application (EAR).
>
> The above works for me every time..I don't think I missed anything..did I?
> :)
>
> > Mike Cannon-Brookes wrote:
> >
> > > Re: The index.jsp thing - this is a Struts problem. (Presumably because
> > > index.jsp is in the default welcome-file-list for Tomcat/JServ? I don't
> > > know)
> > >
> > > In the web.xml that comes with the WARs, index.jsp should be a
> > welcome file?
> > > (Welcome files are specified for each web app).
> > >
> > > Craig, can you add this ?
> > >
> >
> > Yep. I just did. Since Tomcat defines "index.jsp" as a welcome
> > file in it's
> > default config, I just assumed everyone did :-). This is not in
> > the servlet
> > spec, so as of tonight's nightly build it will be defined
> > explicitly in the
> > web.xml for the example app.
> >
> > On the top of "Struts with Orion", if someone could consolidate
> > all the ideas
> > into a little "cookbook" style set of steps for installing Struts
> > and getting it
> > working, I'd love to include that in the README file (or a
> > separate file pointed
> > to by the README). As many have pointed out, Orion is a powerful
> > and very fast
> > platform for web applications to run on, so I'd like to avoid any
> > frustrations
> > installing Struts that I can.
> >
> > Same goes for any idiosyncracies on any other servers as well.
> >
> > >
> > > Cheers,
> > > Mike
> >
> > Craig McClanahan
> >
> >
> >
> >
> >
RE: Struts with Orion
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
I'll give you a "quick" one right now. However, what I don't think you
should have to do in your readme is tell people how to install Orion
properly, including figuring out getting an app to work. That is part of the
Orion team's job. You should only be concerned with Struts with Orion.
So far, its very simple.
- Download Struts
- Unzip.
- Move struts.jar into a web app's /WEB-INF/lib dir
- Move struts.tld into a web app's /WEB-INF dir
- Move actions.xml into a web app's "root" (www) dir
Thats it. At least for me..it worked fine. I think the biggest problem right
now is that most people are having a hard time getting Orion to work. Its
easy once you figure it out (or get help) but until that time, their docs
aren't that great in detail as to how to get it running for a web app (WAR),
or an application (EAR).
The above works for me every time..I don't think I missed anything..did I?
:)
> Mike Cannon-Brookes wrote:
>
> > Re: The index.jsp thing - this is a Struts problem. (Presumably because
> > index.jsp is in the default welcome-file-list for Tomcat/JServ? I don't
> > know)
> >
> > In the web.xml that comes with the WARs, index.jsp should be a
> welcome file?
> > (Welcome files are specified for each web app).
> >
> > Craig, can you add this ?
> >
>
> Yep. I just did. Since Tomcat defines "index.jsp" as a welcome
> file in it's
> default config, I just assumed everyone did :-). This is not in
> the servlet
> spec, so as of tonight's nightly build it will be defined
> explicitly in the
> web.xml for the example app.
>
> On the top of "Struts with Orion", if someone could consolidate
> all the ideas
> into a little "cookbook" style set of steps for installing Struts
> and getting it
> working, I'd love to include that in the README file (or a
> separate file pointed
> to by the README). As many have pointed out, Orion is a powerful
> and very fast
> platform for web applications to run on, so I'd like to avoid any
> frustrations
> installing Struts that I can.
>
> Same goes for any idiosyncracies on any other servers as well.
>
> >
> > Cheers,
> > Mike
>
> Craig McClanahan
>
>
>
>
>
RE: Struts with Orion
Posted by Mike Cannon-Brookes <mi...@bookmarkbox.com>.
I wrote in with a cookbook yesterday - it's very simple - only 4 steps. Are
there archives? I can't find them - they sure would be useful.
I'll resend the cookbook when I get to work today (about 2 hours) and try to
add more detail. The only 'problem' on Struts end is the placement of
action.xml/database.xml in the /WEB-INF directory - which has been discussed
here - but it is VERY easy to solve.
Cookbook coming up.
Mike
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: Tuesday, 27 June 2000 3:27
> To: struts-user@jakarta.apache.org
> Subject: Re: Struts with Orion
>
>
> Mike Cannon-Brookes wrote:
>
> > Re: The index.jsp thing - this is a Struts problem. (Presumably because
> > index.jsp is in the default welcome-file-list for Tomcat/JServ? I don't
> > know)
> >
> > In the web.xml that comes with the WARs, index.jsp should be a
> welcome file?
> > (Welcome files are specified for each web app).
> >
> > Craig, can you add this ?
> >
>
> Yep. I just did. Since Tomcat defines "index.jsp" as a welcome
> file in it's
> default config, I just assumed everyone did :-). This is not in
> the servlet
> spec, so as of tonight's nightly build it will be defined
> explicitly in the
> web.xml for the example app.
>
> On the top of "Struts with Orion", if someone could consolidate
> all the ideas
> into a little "cookbook" style set of steps for installing Struts
> and getting it
> working, I'd love to include that in the README file (or a
> separate file pointed
> to by the README). As many have pointed out, Orion is a powerful
> and very fast
> platform for web applications to run on, so I'd like to avoid any
> frustrations
> installing Struts that I can.
>
> Same goes for any idiosyncracies on any other servers as well.
>
> >
> > Cheers,
> > Mike
>
> Craig McClanahan
>
>
>
>
Re: Struts with Orion
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Mike Cannon-Brookes wrote:
> Re: The index.jsp thing - this is a Struts problem. (Presumably because
> index.jsp is in the default welcome-file-list for Tomcat/JServ? I don't
> know)
>
> In the web.xml that comes with the WARs, index.jsp should be a welcome file?
> (Welcome files are specified for each web app).
>
> Craig, can you add this ?
>
Yep. I just did. Since Tomcat defines "index.jsp" as a welcome file in it's
default config, I just assumed everyone did :-). This is not in the servlet
spec, so as of tonight's nightly build it will be defined explicitly in the
web.xml for the example app.
On the top of "Struts with Orion", if someone could consolidate all the ideas
into a little "cookbook" style set of steps for installing Struts and getting it
working, I'd love to include that in the README file (or a separate file pointed
to by the README). As many have pointed out, Orion is a powerful and very fast
platform for web applications to run on, so I'd like to avoid any frustrations
installing Struts that I can.
Same goes for any idiosyncracies on any other servers as well.
>
> Cheers,
> Mike
Craig McClanahan
RE: Struts with Orion
Posted by Mike Cannon-Brookes <mc...@internet.com>.
Re: The index.jsp thing - this is a Struts problem. (Presumably because
index.jsp is in the default welcome-file-list for Tomcat/JServ? I don't
know)
In the web.xml that comes with the WARs, index.jsp should be a welcome file?
(Welcome files are specified for each web app).
Craig, can you add this ?
Cheers,
Mike
-----Original Message-----
From: Kevin Duffey [mailto:kduffey@buymedia.com]
Hi,
> Thanks much for the reply -- I too like Orion a lot and think
> it's theme of
> never shutting down the server is where things need to be. I'm trying to
> get struts-example and struts-documentation to work in Orion. Neither of
> these projects have an app or www directory -- just META-INF and
> WEB-INF at
> the base of the .war file. So where would you put action.xml in
> this case?
> I'll play around and thanks in advance for any additional suggestions.
Sure thing. Like I said before..as far as I know, Orion does not yet support
/WEB-INF/ access from servlets..unless you use file IO..not a good choice.
So, you might have to unjar the application, move action.xml into the "base"
dir (the one that the WEB-INF dir is in), and then jar it up (and rename it
to .war) and try that. Also, like someone else said, make sure the
welcome-file-list is set to use index.jsp, and that tools.jar is in your
Orion root dir.
RE: Struts with Orion
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> Thanks much for the reply -- I too like Orion a lot and think
> it's theme of
> never shutting down the server is where things need to be. I'm trying to
> get struts-example and struts-documentation to work in Orion. Neither of
> these projects have an app or www directory -- just META-INF and
> WEB-INF at
> the base of the .war file. So where would you put action.xml in
> this case?
> I'll play around and thanks in advance for any additional suggestions.
Sure thing. Like I said before..as far as I know, Orion does not yet support
/WEB-INF/ access from servlets..unless you use file IO..not a good choice.
So, you might have to unjar the application, move action.xml into the "base"
dir (the one that the WEB-INF dir is in), and then jar it up (and rename it
to .war) and try that. Also, like someone else said, make sure the
welcome-file-list is set to use index.jsp, and that tools.jar is in your
Orion root dir.
RE: Struts with Orion
Posted by Philip Eskelin <ph...@eskelin.com>.
Kevin,
Thanks much for the reply -- I too like Orion a lot and think it's theme of
never shutting down the server is where things need to be. I'm trying to
get struts-example and struts-documentation to work in Orion. Neither of
these projects have an app or www directory -- just META-INF and WEB-INF at
the base of the .war file. So where would you put action.xml in this case?
I'll play around and thanks in advance for any additional suggestions.
Regards,
Philip
> -----Original Message-----
> From: Kevin Duffey [mailto:kduffey@buymedia.com]
> Sent: Sunday, June 25, 2000 2:10 AM
> To: struts-user@jakarta.apache.org; philip@eskelin.com
> Subject: RE: Struts with Orion
>
>
> Hi,
>
> Yeah..I had a little bit of a problem too with Orion. As it turns
> out, Orion
> does NOT allow the servlet container serlvets to access anything
> in WEB-INF
> dir, so the examples were not working. However, I am using Struts
> with Orion
> 1.0 release just fine. What I had to do is move action.xml into my www
> folder (of my .WAR directory structure), and I did put struts.tld in the
> WEB-INF dir, compiled my code to WEB-INF/classes, and put
> struts.jar in the
> WEB-INF/lib dir.
>
> app/www/action.xml - struts config file
> app/www/WEB-INF/classes - compiled class code (Servlets, javabeans, core
> classes, etc)
> app/www/WEB-INF/lib/struts.jar - struts library
> app/www/WEB-INF/struts.tld - struts tag-lib library
>
> Also, I have the following in web.xml for Orion specifically:
>
> <?xml version="1.0"?>
> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
> 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
>
> <web-app>
> <servlet>
> <servlet-name>action</servlet-name>
> <display-name>action</display-name>
>
> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
> <init-param>
> <param-name>mapping</param-name>
>
> <param-value>org.apache.struts.action.ActionMappingBase</param-value>
> </init-param>
> <init-param>
> <param-name>application</param-name>
>
> <param-value>org.apache.struts.action.ActionResources</param-value>
> </init-param>
> <init-param>
> <param-name>config</param-name>
> <param-value>/action.xml</param-value>
> </init-param>
> <init-param>
> <param-name>debug</param-name>
> <param-value>0</param-value>
> </init-param>
> </servlet>
> <servlet-mapping>
> <servlet-name>action</servlet-name>
> <url-pattern>*.do</url-pattern>
> </servlet-mapping>
> <welcome-file-list>
> <welcome-file>index.jsp</welcome-file>
> </welcome-file-list>
> <taglib>
> <taglib-uri>/config/struts.tld</taglib-uri>
> <taglib-location>/WEB-INF/struts.tld</taglib-location>
> </taglib>
> <taglib>
> <taglib-uri>/config/bm.tld</taglib-uri>
> <taglib-location>/WEB-INF/bm.tld</taglib-location>
> </taglib>
> <login-config>
> <auth-method>BASIC</auth-method>
> </login-config>
> </web-app>
>
>
> Make sure you use the init-param for CONFIG and set the value to
> /action.xml. It defaults to /WEB-INF/action.xml, and that won't work
> presently with Orion.
>
> As to why this is happening, their is a misunderstanding of the
> servlet 2.2
> spec of the WAR format. A number of developers including the Orion team
> believe the spec means that the servlet container can NOT server
> anything in
> the WEB-INF dir, even to its own servlets..thus they are not allowed to
> access the WEB-INF dir. The code in Struts..I forget exactly..but
> I believe
> it uses getResource() call to get the xml config file loaded, and that is
> what Orion is preventing from working. I did talk with the Orion team and
> they are looking into the specific meaning of the WEB-INF
> structure. Craig,
> the developer of Struts has informed me that Danny Coward, the lead on the
> servlet 2.2 spec confirms that the WEB-INF dir is accessible via
> the servlet
> container. Tomcat supports this, and Craig is part of the Apache/Jakarta
> project..which uses Tomcat for development (is this right Craig? ;).
>
> Other servlet engines including JRUN, Resing and WebLogic do allow WEB-INF
> access, so I think Orion will change to allow this. They are
> working on EJB
> 2.0, admin tools, and Serlvete 2.3, JSP 1.2 already for Orion, so I don't
> know if they will add this to 1.0 (update), or later versions for
> those that
> want to start using the new features Orion already implements (which is
> going to be part of J2EE 1.3).
>
> Oh yeah..I set up an application with a META-INF dir too..but you
> can deploy
> just a .war or an expanded WAR formatted dir structure as well.
>
> If you have any trouble..feel free to ask. I use Orion
> exclusively as its by
> far the best product I have seen, especially considering the price,
> performance and feature set. It may not package development tools
> and fancy
> GUI tools, but it is certainly the easiest app server I have ever set up,
> and its performance thus far is much higher than every other engine I have
> tried (WebLogic, IIS/JRUN, ServletExec, Resin, Apache/JServ).
> Resin is very
> fast too..but Orion is slightly ahead of it..and it supports full J2EE
> deployment.
>
> Hope that helps.
>
RE: Struts with Orion
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
Yeah..I had a little bit of a problem too with Orion. As it turns out, Orion
does NOT allow the servlet container serlvets to access anything in WEB-INF
dir, so the examples were not working. However, I am using Struts with Orion
1.0 release just fine. What I had to do is move action.xml into my www
folder (of my .WAR directory structure), and I did put struts.tld in the
WEB-INF dir, compiled my code to WEB-INF/classes, and put struts.jar in the
WEB-INF/lib dir.
app/www/action.xml - struts config file
app/www/WEB-INF/classes - compiled class code (Servlets, javabeans, core
classes, etc)
app/www/WEB-INF/lib/struts.jar - struts library
app/www/WEB-INF/struts.tld - struts tag-lib library
Also, I have the following in web.xml for Orion specifically:
<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<servlet>
<servlet-name>action</servlet-name>
<display-name>action</display-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>mapping</param-name>
<param-value>org.apache.struts.action.ActionMappingBase</param-value>
</init-param>
<init-param>
<param-name>application</param-name>
<param-value>org.apache.struts.action.ActionResources</param-value>
</init-param>
<init-param>
<param-name>config</param-name>
<param-value>/action.xml</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<taglib>
<taglib-uri>/config/struts.tld</taglib-uri>
<taglib-location>/WEB-INF/struts.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/config/bm.tld</taglib-uri>
<taglib-location>/WEB-INF/bm.tld</taglib-location>
</taglib>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
</web-app>
Make sure you use the init-param for CONFIG and set the value to
/action.xml. It defaults to /WEB-INF/action.xml, and that won't work
presently with Orion.
As to why this is happening, their is a misunderstanding of the servlet 2.2
spec of the WAR format. A number of developers including the Orion team
believe the spec means that the servlet container can NOT server anything in
the WEB-INF dir, even to its own servlets..thus they are not allowed to
access the WEB-INF dir. The code in Struts..I forget exactly..but I believe
it uses getResource() call to get the xml config file loaded, and that is
what Orion is preventing from working. I did talk with the Orion team and
they are looking into the specific meaning of the WEB-INF structure. Craig,
the developer of Struts has informed me that Danny Coward, the lead on the
servlet 2.2 spec confirms that the WEB-INF dir is accessible via the servlet
container. Tomcat supports this, and Craig is part of the Apache/Jakarta
project..which uses Tomcat for development (is this right Craig? ;).
Other servlet engines including JRUN, Resing and WebLogic do allow WEB-INF
access, so I think Orion will change to allow this. They are working on EJB
2.0, admin tools, and Serlvete 2.3, JSP 1.2 already for Orion, so I don't
know if they will add this to 1.0 (update), or later versions for those that
want to start using the new features Orion already implements (which is
going to be part of J2EE 1.3).
Oh yeah..I set up an application with a META-INF dir too..but you can deploy
just a .war or an expanded WAR formatted dir structure as well.
If you have any trouble..feel free to ask. I use Orion exclusively as its by
far the best product I have seen, especially considering the price,
performance and feature set. It may not package development tools and fancy
GUI tools, but it is certainly the easiest app server I have ever set up,
and its performance thus far is much higher than every other engine I have
tried (WebLogic, IIS/JRUN, ServletExec, Resin, Apache/JServ). Resin is very
fast too..but Orion is slightly ahead of it..and it supports full J2EE
deployment.
Hope that helps.
Struts with Orion
Posted by Philip Eskelin <ph...@eskelin.com>.
Anybody get this to work? I'm trying to deploy struts-example and it gives
me this:
"Auto-unpacking E:\Program Files\orion\applications\struts-example.war...
done.
Error updating application struts-example: Unable to find/read assembly info
for
E:\Program Files\orion\applications\struts-example
(META-INF/application.xml)"
Do I create an application.xml and put it into meta-inf in the .war file?
Thanks for any tips,
Philip Eskelin
RE: This framework rocks!
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> Thanks for the vote of confidence! This is the kind of results that I
> envisioned when I sat down to actually write Struts, based on the many
> conversations we've had on JSP-INTEREST. I'm glad it is working
> out the way
> that I hoped it would.
Hey..do you ever go home? I don't. ;) I notice you respond to email
24/7..pretty much as do I. It is definitely working out. Infact, its working
out so well that I am training another almost "beginner" programmer using
Struts, and he just did his first conversion of some crappy code into using
the Struts framework. He has been rather bummed lately..as our main engineer
likes to put him and others down when they don't grasp the concepts fully.
So not only is Struts useful and quick to develop with, but it brings smiles
to some peoples faces when they see results! ;)
> Well, I do note the following interesting facts:
>
> * ActionServlet has a public addMapping() method.
>
> * The ActionServlet instance gets passed as an argument to
> your Action's perform() method.
>
> * Therefore an Action can call the controller servlet's
> addMapping() method (or removeMapping() for that
> matter).
Ahh yes..perfect! I haven't fully read everything because I have been so
darn busy implementing the site using it. Thanks for the pointer..I'll look
into a simple admin servlet (password protected ofcourse) that can reside on
our production server (or admin server) and allow a new class to be added
in. One question on this..do you recommend doing a "removeMapping()" call
FIRST, then using addMapping() to reuse an already named map..while the
server is running..or do you think that could cause portential problems if
someone submits a request to the action right in the middle of it being
removed and readded? I would say..the latter is the answer on this, but I am
curious if it happens fast enough to be "thread safe". Maybe, if its not too
much trouble, you could add a reMap() method that undoes and redoes a
mapping to a class, all in the comfort of a syncronized method or something?
Or..could I just call addMapping with the same name of an already mapped
action, which would overwrite the existing object (downside being..the
object might be stranded in memory for a while).
Thanks again.
RE: This framework rocks!
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> Thanks for the vote of confidence! This is the kind of results that I
> envisioned when I sat down to actually write Struts, based on the many
> conversations we've had on JSP-INTEREST. I'm glad it is working
> out the way
> that I hoped it would.
Hey..do you ever go home? I don't. ;) I notice you respond to email
24/7..pretty much as do I. It is definitely working out. Infact, its working
out so well that I am training another almost "beginner" programmer using
Struts, and he just did his first conversion of some crappy code into using
the Struts framework. He has been rather bummed lately..as our main engineer
likes to put him and others down when they don't grasp the concepts fully.
So not only is Struts useful and quick to develop with, but it brings smiles
to some peoples faces when they see results! ;)
> Well, I do note the following interesting facts:
>
> * ActionServlet has a public addMapping() method.
>
> * The ActionServlet instance gets passed as an argument to
> your Action's perform() method.
>
> * Therefore an Action can call the controller servlet's
> addMapping() method (or removeMapping() for that
> matter).
Ahh yes..perfect! I haven't fully read everything because I have been so
darn busy implementing the site using it. Thanks for the pointer..I'll look
into a simple admin servlet (password protected ofcourse) that can reside on
our production server (or admin server) and allow a new class to be added
in. One question on this..do you recommend doing a "removeMapping()" call
FIRST, then using addMapping() to reuse an already named map..while the
server is running..or do you think that could cause portential problems if
someone submits a request to the action right in the middle of it being
removed and readded? I would say..the latter is the answer on this, but I am
curious if it happens fast enough to be "thread safe". Maybe, if its not too
much trouble, you could add a reMap() method that undoes and redoes a
mapping to a class, all in the comfort of a syncronized method or something?
Or..could I just call addMapping with the same name of an already mapped
action, which would overwrite the existing object (downside being..the
object might be stranded in memory for a while).
Thanks again.
Re: This framework rocks!
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> Hi,
>
> I just wanted to express my enthusiasm for the use of Struts. While I wrote
> my own little framework that did work similarly to Struts, based on a number
> of discussions with Craig, Struts obviously has the advantage because its
> open, Craig (the guru) is writing it, and alot more of us are contributing
> ideas and hopefully providing a good solid testbed for Craig to improve
> upon.
>
> None the less, I wanted to let everyone know how fast it is to actually work
> with Struts on the front end. I have the disturbing task of dealing with
> crappy code and converting it into something good, solid and stable. I am
> basically rewriting about 30,000 lines of servlet code into using the Struts
> framework, actions, and having it call our "logic" classes. Not only is it
> much easier than I originally thought, but at least to me, it appears to be
> running much faster..possibly due to the fact that our servlets are always
> created an object for every request, putting in a connection, etc..where as
> now I am not doing that at all. The added benefit of multiple forwarding
> pages for each action based on a String result that matches that of the
> action.xml <action...> tags, bean auto-population and creation, and the xml
> config being loaded and maintained for me has increased my level of work
> greatly. I feel confident that I can create a full set of pages (for
> example.. a series of "wizard" page/forms for a single transaction), a
> javabean that is used across those pages, and a "session" (logic) class that
> handles the connection to the database, does the searching, getting and
> updating of info, in a matter of hours..if not less. This includes building
> the JSP pages WITH form/field validation for fields I specify, as well as
> one or more taglibs used to display dynamic content. Before, it took days to
> fully test the same type of setup because of all the issues with our code
> base, and other issues aside.
>
> Anyways..just wanted to pass that on to those interested..especially if your
> new to the whole Model 2 action/servlet approach and might be frustrated
> with it, not fully understanding it, etc.
>
> One last thing..Craig has done us a service by including the xml config
> loading and also the auto-populating and creation of beans. One of the BIG
> complaints I saw in the JSP-INTEREST mailing list about using Model 2 over
> Model 1 (where you use JSP pages and JaveBeans and the JSPServlet
> auto-populates the bean..etc) was that using the Model 2 approach you didn't
> get the bean auto-population. Craig has nicely taken care of this.
>
Thanks for the vote of confidence! This is the kind of results that I
envisioned when I sat down to actually write Struts, based on the many
conversations we've had on JSP-INTEREST. I'm glad it is working out the way
that I hoped it would.
>
> Ahh..one request..the ability to run a little "admin" utility that reloads
> the xml config file..and ONLY adds or modifies actions that have changed.
> The reason is..it would be nice at runtime, for example, to "replace" an
> existing action with a new version of the code. Mostly this would be useful
> in the need of an emergency fix. It would also be nice to add NEW actions to
> the list (in memory) without having to stop/start the server..so that during
> the day I could throw up some new pages and they would take effect
> immediately..when a request came in for them. Craig..any ideas if this is
> possible?
>
Well, I do note the following interesting facts:
* ActionServlet has a public addMapping() method.
* The ActionServlet instance gets passed as an argument to
your Action's perform() method.
* Therefore an Action can call the controller servlet's
addMapping() method (or removeMapping() for that
matter).
Sounds like this might be something you could build in to your own application
(suitably password protected or something, of course). After all, you've
already got this wonderful toolkit :-)
You can also investigate your servlet container's ability to perform automatic
application reloading when an application class is updated. You would want this
if you need to modify an existing Java class -- although you might not really
want to pay the runtime overhead for having your servlet container check all the
time.
>
> Thanks again.
Craig
Re: This framework rocks!
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> Hi,
>
> I just wanted to express my enthusiasm for the use of Struts. While I wrote
> my own little framework that did work similarly to Struts, based on a number
> of discussions with Craig, Struts obviously has the advantage because its
> open, Craig (the guru) is writing it, and alot more of us are contributing
> ideas and hopefully providing a good solid testbed for Craig to improve
> upon.
>
> None the less, I wanted to let everyone know how fast it is to actually work
> with Struts on the front end. I have the disturbing task of dealing with
> crappy code and converting it into something good, solid and stable. I am
> basically rewriting about 30,000 lines of servlet code into using the Struts
> framework, actions, and having it call our "logic" classes. Not only is it
> much easier than I originally thought, but at least to me, it appears to be
> running much faster..possibly due to the fact that our servlets are always
> created an object for every request, putting in a connection, etc..where as
> now I am not doing that at all. The added benefit of multiple forwarding
> pages for each action based on a String result that matches that of the
> action.xml <action...> tags, bean auto-population and creation, and the xml
> config being loaded and maintained for me has increased my level of work
> greatly. I feel confident that I can create a full set of pages (for
> example.. a series of "wizard" page/forms for a single transaction), a
> javabean that is used across those pages, and a "session" (logic) class that
> handles the connection to the database, does the searching, getting and
> updating of info, in a matter of hours..if not less. This includes building
> the JSP pages WITH form/field validation for fields I specify, as well as
> one or more taglibs used to display dynamic content. Before, it took days to
> fully test the same type of setup because of all the issues with our code
> base, and other issues aside.
>
> Anyways..just wanted to pass that on to those interested..especially if your
> new to the whole Model 2 action/servlet approach and might be frustrated
> with it, not fully understanding it, etc.
>
> One last thing..Craig has done us a service by including the xml config
> loading and also the auto-populating and creation of beans. One of the BIG
> complaints I saw in the JSP-INTEREST mailing list about using Model 2 over
> Model 1 (where you use JSP pages and JaveBeans and the JSPServlet
> auto-populates the bean..etc) was that using the Model 2 approach you didn't
> get the bean auto-population. Craig has nicely taken care of this.
>
Thanks for the vote of confidence! This is the kind of results that I
envisioned when I sat down to actually write Struts, based on the many
conversations we've had on JSP-INTEREST. I'm glad it is working out the way
that I hoped it would.
>
> Ahh..one request..the ability to run a little "admin" utility that reloads
> the xml config file..and ONLY adds or modifies actions that have changed.
> The reason is..it would be nice at runtime, for example, to "replace" an
> existing action with a new version of the code. Mostly this would be useful
> in the need of an emergency fix. It would also be nice to add NEW actions to
> the list (in memory) without having to stop/start the server..so that during
> the day I could throw up some new pages and they would take effect
> immediately..when a request came in for them. Craig..any ideas if this is
> possible?
>
Well, I do note the following interesting facts:
* ActionServlet has a public addMapping() method.
* The ActionServlet instance gets passed as an argument to
your Action's perform() method.
* Therefore an Action can call the controller servlet's
addMapping() method (or removeMapping() for that
matter).
Sounds like this might be something you could build in to your own application
(suitably password protected or something, of course). After all, you've
already got this wonderful toolkit :-)
You can also investigate your servlet container's ability to perform automatic
application reloading when an application class is updated. You would want this
if you need to modify an existing Java class -- although you might not really
want to pay the runtime overhead for having your servlet container check all the
time.
>
> Thanks again.
Craig