You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dmitri Colebatch <di...@bigpond.net.au> on 2001/10/30 02:36:01 UTC
Re: going from Zope to Tomcat, where are these features ?
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>
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>