You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by raj <ra...@clarologic.com> on 2001/10/25 13:01:52 UTC
Where to place the Login.html file
Due to the bug (yet unresolved) in Tomcat 3.x, the Login.html and
Error.html files cannot be
placed inside the servlets dir.
For instance:
My servlet is inside the dir called "foo" (i.e webapps/foo) and is
called "bar".
URL pattern is "/*" for security.
This means "Login.html" and "Error.html" cannot be placed inside
/webapps/foo.
Question: Where should I placed them instead?
I have tried to place them in webapps and declared them (in web.xml) as:
<form-login-page>/../LoginForm.html</form-login-page>
<form-error-page>/../LoginError.html</form-error-page>
but this would not work.
Any suggestion would be most appreciated. Should I try another
URL pattern?
The release note says something about placing "other" files in "other"
sub-dirs but what other files and what other
sub-dirs.
Some clarity would help, n'est pas?
Cheers
-raj
Re: going from Zope to Tomcat, where are these features ?
Posted by Jim Cheesman <jc...@msl.es>.
> >> 2. In Zope, you create a "SQL Method", which is an object that
> >> basically contains a SQL statement and queries it against
> >> one of the database connections in your pool.
> >> The advantage of such "SQL Methods" is that they can be fully
> >> tested/debugged standalone before using their output within
> >> your pages. The result is also cached and you can easily specify
> >> the time to cache, or the number of results to cache.
> >> All it takes is your SQL query and 4-5 clicks of the mouse.
> >
> >sounds like an entity bean? Am I way off track?
>
>An entity bean encapsulates a lot more functionality than
>Zope's SQL methods. An entity bean, as I understand,
>takes care of all the business logic for a business object....
>.. whereas the SQL methods to which I refer just take care of
>SQL statements (inserts/updates/deletes etc) and cach the
>results. A business object in Zope might use multiple SQL methods.
You could try the dbTags - which I believe are part of jakarta's taglib.
> >> For example, I have to agree with the following article -
> >> http://www-106.ibm.com/developerworks/java/library/j-webdata/
> >> - that the scriptlets and even the DBTags code leave your
> >> JSP pages a complete mess.
> >
> >(o: I think you'll find most ppl agree with you there.
>
>Glad to hear it's not just me.
On the other hand, the ability to mix all the code up in the jsp lends
itself to rapid page development, which you can then tidy up by removing
the code to seperate beans.
> >>
> >> <db_connections> - <sql_method> - <display_page>
> >>
> >One option for providing this sort of architecture would be:
> >
> >db - jboss - struts/tomcat - view
> >
> >jboss - http://www.jboss.org
> >struts - http://jakarta.apache.org/struts
> >
> >note that everyone has their favourite application server, I'm just
> >suggesting jboss/tomcat as a very easy solution (which we use).
>
>OK. I had hoped to leave EJB/J2EE and JBoss for a later date
>- there was a quote somewhere that 70% of projects that use
>EJB really don't need to. However, if that's going to give
>me much cleaner demarkation of business logic from presentation,
>and make each component easier to debug/test individually,
>then it's worth a try.... I may as well get my feet wet now,
>and will check JBoss.
JBoss and EJBs have a reasonably steep learning curve - as have
tomcat/jsp/servlets. I'd stick to one for the moment, then investigate the
other. As you mentioned, 70% of projects that use ejb probably don't need
to. We certainly found that to be true in our case.
Jim
--
* Jim Cheesman *
Trabajo:
jchees@msl.es - (34)(91) 724 9200 x 2360
Some people say that I'm
superficial, but that's just on the surface.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: going from Zope to Tomcat, where are these features ?
Posted by chas <pa...@skinnyhippo.com>.
Thanks for the reply Dmitri,
>> 1. In Zope, you can create permanent database connections
>> with a click of a button. It comes part and parcel of
>> the application server.
>> In Java, you can create your own database pool.
>> (eg. http://webdevelopersjournal.com/columns/connection_pool.html)
>> But does Tomcat really not come with its own database
>> pool manager built-in ?
>
>J2EE uses the javax.sql.Datasource for connection pooling - normally this
>would be controlled at an application server level, but the following
>document talks about how to use it in tomcat (I'm not sure of the extent
>of the datasource discussion here):
>
>http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
Great, this is what I was looking for. It also covers the equivalent
of Zope's Mail Adapters for mail support. Other than the lack of simple
GUI for configuration, this is perfect.
>> 2. In Zope, you create a "SQL Method", which is an object that
>> basically contains a SQL statement and queries it against
>> one of the database connections in your pool.
>> The advantage of such "SQL Methods" is that they can be fully
>> tested/debugged standalone before using their output within
>> your pages. The result is also cached and you can easily specify
>> the time to cache, or the number of results to cache.
>> All it takes is your SQL query and 4-5 clicks of the mouse.
>
>sounds like an entity bean? Am I way off track?
An entity bean encapsulates a lot more functionality than
Zope's SQL methods. An entity bean, as I understand,
takes care of all the business logic for a business object....
.. whereas the SQL methods to which I refer just take care of
SQL statements (inserts/updates/deletes etc) and cach the
results. A business object in Zope might use multiple SQL methods.
So, it appears to me that this is the way to go with Java/JSP
- wrap everything inside beans. I don't mind doing this but
find that it doesn't lend itself as easily to prototyping and
rapid application development.
>> For example, I have to agree with the following article -
>> http://www-106.ibm.com/developerworks/java/library/j-webdata/
>> - that the scriptlets and even the DBTags code leave your
>> JSP pages a complete mess.
>
>(o: I think you'll find most ppl agree with you there.
Glad to hear it's not just me.
>> In short, there has to be a better, cleaner way of separating
>>
>> <db_connections> - <sql_method> - <display_page>
>>
>> where Display pages use the results of SQL method which
>> in turn use DB connections. The article above suggest the
>> cleanest way to separate these is with "includes" - including
>> separate pages which take care of form validation, database
>> queries, etc.
>
>One option for providing this sort of architecture would be:
>
>db - jboss - struts/tomcat - view
>
>jboss - http://www.jboss.org
>struts - http://jakarta.apache.org/struts
>
>note that everyone has their favourite application server, I'm just
>suggesting jboss/tomcat as a very easy solution (which we use).
OK. I had hoped to leave EJB/J2EE and JBoss for a later date
- there was a quote somewhere that 70% of projects that use
EJB really don't need to. However, if that's going to give
me much cleaner demarkation of business logic from presentation,
and make each component easier to debug/test individually,
then it's worth a try.... I may as well get my feet wet now,
and will check JBoss.
Thanks again,
chas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: going from Zope to Tomcat, where are these features ?
Posted by Dmitri Colebatch <di...@bigpond.net.au>.
Hi,
I haven't used Zope, so cant comment on much of this, but a couple of
links might be helpful for you...
> 1. In Zope, you can create permanent database connections
> with a click of a button. It comes part and parcel of
> the application server.
> In Java, you can create your own database pool.
> (eg. http://webdevelopersjournal.com/columns/connection_pool.html)
> But does Tomcat really not come with its own database
> pool manager built-in ?
J2EE uses the javax.sql.Datasource for connection pooling - normally this
would be controlled at an application server level, but the following
document talks about how to use it in tomcat (I'm not sure of the extent
of the datasource discussion here):
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
> 2. In Zope, you create a "SQL Method", which is an object that
> basically contains a SQL statement and queries it against
> one of the database connections in your pool.
> The advantage of such "SQL Methods" is that they can be fully
> tested/debugged standalone before using their output within
> your pages. The result is also cached and you can easily specify
> the time to cache, or the number of results to cache.
> All it takes is your SQL query and 4-5 clicks of the mouse.
sounds like an entity bean? Am I way off track?
> For example, I have to agree with the following article -
> http://www-106.ibm.com/developerworks/java/library/j-webdata/
> - that the scriptlets and even the DBTags code leave your
> JSP pages a complete mess.
(o: I think you'll find most ppl agree with you there.
> In short, there has to be a better, cleaner way of separating
>
> <db_connections> - <sql_method> - <display_page>
>
> where Display pages use the results of SQL method which
> in turn use DB connections. The article above suggest the
> cleanest way to separate these is with "includes" - including
> separate pages which take care of form validation, database
> queries, etc.
One option for providing this sort of architecture would be:
db - jboss - struts/tomcat - view
jboss - http://www.jboss.org
struts - http://jakarta.apache.org/struts
note that everyone has their favourite application server, I'm just
suggesting jboss/tomcat as a very easy solution (which we use).
hope some of the above is useful.
cheesr
dim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
going from Zope to Tomcat, where are these features ?
Posted by chas <pa...@skinnyhippo.com>.
This is not meant as a comparison of Zope and Tomcat, and the
market has dictated that Java/JSP/J2EE is the way to go, so pls
do not treat this post as a troll.
However, in migrating from Zope to Tomcat, I can't help but
wonder where the following features are in Tomcat.
1. In Zope, you can create permanent database connections
with a click of a button. It comes part and parcel of
the application server.
In Java, you can create your own database pool.
(eg. http://webdevelopersjournal.com/columns/connection_pool.html)
But does Tomcat really not come with its own database
pool manager built-in ?
2. In Zope, you create a "SQL Method", which is an object that
basically contains a SQL statement and queries it against
one of the database connections in your pool.
The advantage of such "SQL Methods" is that they can be fully
tested/debugged standalone before using their output within
your pages. The result is also cached and you can easily specify
the time to cache, or the number of results to cache.
All it takes is your SQL query and 4-5 clicks of the mouse.
There seem to be several methods of accessing DBs with Java/JSP :
a. stuff all the Java code in Scriptlets within JSPs
b. use Taglibs, using DBTags.
c. use a javabean to take care of all DB functionality.
... but nothing as elegant as Zope's "SQL methods".
For example, I have to agree with the following article -
http://www-106.ibm.com/developerworks/java/library/j-webdata/
- that the scriptlets and even the DBTags code leave your
JSP pages a complete mess.
In short, there has to be a better, cleaner way of separating
<db_connections> - <sql_method> - <display_page>
where Display pages use the results of SQL method which
in turn use DB connections. The article above suggest the
cleanest way to separate these is with "includes" - including
separate pages which take care of form validation, database
queries, etc.
Am I overlooking something ?
Thank you for your patience - sorry for such a long post.
chas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>