You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by John Shin <ho...@us.ibm.com> on 2000/05/02 04:02:29 UTC
Re: Hi
> Hi, folks.
My name is John Shin.
I am glad that I can work on this exciting Jakarta project with you folks.
I am planning to actively participate in the project development.
Where can I find the list of the work items to be addressed? Anything
urgent?
My address is hoon@raleigh.ibm.com..... Hoon is my middle name.
John H. Shin
IBM
Research Triangle Park, NC
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Eduardo Pelegri--Llopart <Ed...@eng.sun.com>.
interaction of tag libraries and lifecycles (both servlet and
applications) is high in the priority for JSP 1.2. In the meantime
there are a few things that can be done, we can go through them at the
BOF on tag libraries in J1 :-)
- eduard/o
Boyd Waters wrote:
>
> Michal Mosiewicz wrote:
>
> > > Attached is a (10K) jar file that contains source code for
> > > implementations of the SQL Taglib discussed in the JavaServer Pages 1.1
> > > specification, sections A.2.1 and A.2.2
> >
> > Poor solution. Run it with Oracle and you'll certainly run out of
> > cursors. You have to close connections, you have to close statements,
> > you have to close resultSets as soon as they are no longer needed.
> >
> > -- Mike
>
> Mike:
>
> You're absolutely correct -- in my "normal" JDBC code I am quite careful
> about closing JDBC resources as soon as possible. I should have
> mentioned this problem in the comments to the example code.
>
> I'm still trying to figure out the interaction between JSP servlet
> life-cycles and these JSP tags. I've written JDBC servlets, no problem -
> I have control. But with these tags -- ?
>
> CONNECTION MANAGMENT
> In particular, with our JDBC library (Ingres (!)) here at NRAO-Socorro,
> connections take a *long* time to set up, but after that things are
> fast. Connection-pooling is therefore desirable; you keep a small set of
> connections "open" and re-use them as much as possible.
>
> In my "in-house" implementation of the Connection tag, I use such a
> scheme by delegating to a Connection Factory which implements connection
> pooling:
>
> public Connection getConnection() throws JspException {
> if( conn == null ) {
> try {
> conn = ConnectionFactory.Impl.makeConnection( userID, password );
> }
> catch( SQLException e ) {
> throw new JspException( e.getMessage() );
> }
> }
>
> return conn;
> }
>
> RESULTSET MANAGMENT
> You'll note that I keep the RecordSet as a memeber variable, and then
> close it in the release() method of the Query tag.
>
> You shouldn't do this, because it's difficult to control the creation of
> server-side cursors in JDBC. With Visual Basic Active Data Objects (ADO)
> and MS SQL Server, you can specify client-side cursors. I can't see a
> way to do this exactly in the JDBC 2.0 spec, consult your driver's
> documentation.
>
> Note that you can (and should) specify that the ResultSet is read-only;
> this might tell your JDBC driver to implement the cursor client-side:
>
> instead of
> Statement stmt = conn.createStatement();
>
> say
> Statement stmt =
> conn.createStatement( ResultSet.TYPE_SCROLL_INSENSITIVE,
> ResultSet.CONCUR_READ_ONLY );
>
> Finally, what you should *really* do is to "cache" the results in a
> Vector of EntityBeans and get rid of the ResultSet ASAP. Or choose not
> to cache the results.
>
> So Mike is right about that. You shouldn't keep the ResultSet around. I
> was keeping it around because I was going to implement caching and then
> thought it would complicate the example.
>
> STATEMENT MANAGMENT
> You'll note that I didn't issue a stmt.close() command in the
> doAfterBody() -- why not?
>
> Very simple. I forgot. Oops.
>
> --
>
> If you've got an improvemed implementation of the example, please post
> it back to me!
>
> Cheers!
>
> -- boyd
>
> ---------
> Boyd Waters bwaters@nrao.edu
> National Radio Astronomy Observatory http://www.nrao.edu
> PO Box 0 Socorro, NM 87801 505.835.7346
>
> http://www.zocalo.net/~waters
> waters@zocalo.net
> ---------
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Eduardo Pelegri--Llopart <Ed...@eng.sun.com>.
"Joseph B. Ottinger" wrote:
>
> Okay, I'm writing FAR TOO MUCH on these lists. :)
Yes, we all do. But sometimes we even learn something :-)
> Is using a bean to access data "model 2?" It was my impression that Model
> 2 requires a controlling servlet, which this isn't.
There are so many variations... I tried to get away from the "model 2"
terminology and talk about "control components" and "presentation
components"; didn't work. Maybe I'll try again for JSP 1.2 :-)
> 1) Woohoo! Then why not use PHP or one of its derivates, which don't even
> bother to encourage proper design? PHP is designed JUST for this kind of
> hackery, without all that pesky Java syntax. Plus, PHP is a lot more
> forgiving of completely crappy designs.
It is a valid question. I think JSPs have some advantages over PHPs
(spec, multiple implementations, tag libraries) but probably the largest
is that JSPs give you more of a range: you can use them as PHP or you
can use them as pure presentations, all within the same core language.
Me thinks...
- eduard/o
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by "Joseph B. Ottinger" <jo...@suninternet.com>.
On Tue, 9 May 2000, Gal Shachor wrote:
> "Joseph B. Ottinger" wrote:
> > Anyway, on to your points:
> > 1) Java developers aren't hard to come by; such data access beans would be
> > VERY easy for a tool to generate, if a developer isn't handy. (Right,
> > Eduardo?)
> Not so true, I have just spent a day with my sysadmin trying to explain
> him how
> to create a simple report using JSP + Beans + Scriptles and eventually
> wrote him a
> set of custom tags because this is what he can use...
The problem is one of design. I'd advocate a mix of tags and beans,
in the real world - it's easy, it's fun, it's efficient, it's
convenient. Again, see
http://cupid.suninternet.com/phonelist/fates/listfates.jsp for an example.
> He could not use the beans because of the scriptlets! he had lots of
> problems
> with them (But why do I need to put ; what is this import attribute?
> what is
> this syntax error ....) but he is really comfortable with tags.
*nod* I'm not a fan of scriptlets.
> The point here is that we have in my location many Java developers, but
> you can
> not (and should not) fork a developer to help someone that got stuck
> because he
> does not know about Java.
No doubt, and that was never my argument.
> > 2) Too much of an effort? How so? It would seem to me that it'd be ... ah,
> > never mind, I see your point exactly. *shrug* I think reusable components
> > would be better, but... that's just me.
> Tags are VERY reusable, lets assume that you have a set of tags that
> lets you:
> 1. Select something from a data base.
> 2. Enumerate the response.
> 3. Show the specific columns in the current row.
>
> You can create >50% of your reports with that.
True enough. I still think it's better to have a bean that wraps data,
though, as your data might be *just data* and not *relational data.* It's
convenient to assume everyone's using JDBC, but be real: not everyone
is. EJB allows you to wrap legacy (codasyl? flat file?) data in Java, and
that's a normal business process; using EJB shouldn't be the solution you
turn to when everything else craps out, it should be the *first* solution
you use, and you use other access methods only because you can't manage to
convince the PHB to buy Orion.
> > 1) Woohoo! Then why not use PHP or one of its derivates, which don't even
> > bother to encourage proper design? PHP is designed JUST for this kind of
> > hackery, without all that pesky Java syntax. Plus, PHP is a lot more
> > forgiving of completely crappy designs.
>
> So you want yet another scripting language for my none programmer?
> Really.
> Also, I would rather work with something that is a standard!
Please note my sarcastic tone; I'm no fan of PHP. I far prefer proper
design.
> > 2) I've no real answer for this, except to possibly ask why it's wise to
> > provide a hammer as a tool for, oh, computer repair - "It probably won't
> > work, but it COULD."
> It does not really matter that this is not the right way. What is
> important is
> that these things happen, and then you need to support it in the
> platform (or
> JSP will remain the tool for the Java developers).
*nod* although this still rubs me the wrong way.
-----------------------------------------------------------
Joseph B. Ottinger joeo@cupid.suninternet.com
http://cupid.suninternet.com/~joeo HOMES.COM Developer
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Gal Shachor <sh...@il.ibm.com>.
"Joseph B. Ottinger" wrote:
>
> Anyway, on to your points:
>
> 1) Java developers aren't hard to come by; such data access beans would be
> VERY easy for a tool to generate, if a developer isn't handy. (Right,
> Eduardo?)
>
Not so true, I have just spent a day with my sysadmin trying to explain
him how
to create a simple report using JSP + Beans + Scriptles and eventually
wrote him a
set of custom tags because this is what he can use...
He could not use the beans because of the scriptlets! he had lots of
problems
with them (But why do I need to put ; what is this import attribute?
what is
this syntax error ....) but he is really comfortable with tags.
The point here is that we have in my location many Java developers, but
you can
not (and should not) fork a developer to help someone that got stuck
because he
does not know about Java.
>
> 2) Too much of an effort? How so? It would seem to me that it'd be ... ah,
> never mind, I see your point exactly. *shrug* I think reusable components
> would be better, but... that's just me.
>
Tags are VERY reusable, lets assume that you have a set of tags that
lets you:
1. Select something from a data base.
2. Enumerate the response.
3. Show the specific columns in the current row.
You can create >50% of your reports with that.
>
> 1) Woohoo! Then why not use PHP or one of its derivates, which don't even
> bother to encourage proper design? PHP is designed JUST for this kind of
> hackery, without all that pesky Java syntax. Plus, PHP is a lot more
> forgiving of completely crappy designs.
>
So you want yet another scripting language for my none programmer?
Really.
Also, I would rather work with something that is a standard!
>
> 2) I've no real answer for this, except to possibly ask why it's wise to
> provide a hammer as a tool for, oh, computer repair - "It probably won't
> work, but it COULD."
>
It does not really matter that this is not the right way. What is
important is
that these things happen, and then you need to support it in the
platform (or
JSP will remain the tool for the Java developers).
Note: I am not saying that you are 100% wrong, only that sometimes
getting away with
tags is the way to go.
Gal Shachor
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by "Joseph B. Ottinger" <jo...@suninternet.com>.
Okay, I'm writing FAR TOO MUCH on these lists. :)
On Tue, 9 May 2000, Gal Shachor wrote:
> > > really think an SQL taglib really is a lousy replacement for proper
> > > design, such as a bean that retrieves data from an indeterminate source.
> > YES!! TOTALLY CORRECT! After implementing the example SQL tag, I
> > immediately set it aside and my JSP pages use an object-based
> > approach... that's why I refer to the object-based iterator in my sample
> > code...
> I would not call that a "lousy ... design" but an alternative design. It
> is true that using Model-2 for accessing a database may looks like the
> right
> approach yet:
> 1. It force the company to have a good Java developer even for a very
> simple project.
> 2. You create bean objects that wrap your result set, it is a good thing
> for several reasons but if all you want to do is to create a simple
> report
> based on a database table then it is too much of an effort.
> 3. You stay with the same old problem of populating your page using
> scriptlets.
Is using a bean to access data "model 2?" It was my impression that Model
2 requires a controlling servlet, which this isn't.
Anyway, on to your points:
1) Java developers aren't hard to come by; such data access beans would be
VERY easy for a tool to generate, if a developer isn't handy. (Right,
Eduardo?)
2) Too much of an effort? How so? It would seem to me that it'd be ... ah,
never mind, I see your point exactly. *shrug* I think reusable components
would be better, but... that's just me.
3) You do? See http://cupid.suninternet.com/phonelist/fates/, choose "list
all fates." There's one scriptlet in that page, and it's not really
necessary (it sorts the list.)
> On the other hand:
>
> 1. Many simple cases can be handled very easily using a tag library.
> And after
> the initial effort of creating the library, using it is really easy
> (mainly
> for non programmer persons).
> 2. You should remember that many of the database driven pages are in use
> for
> small scale/internal sites and for such sites you can not even assume
> that
> you are going to see a design (of any type). The site will just
> happen, and
> for these sites tag libraries are a life savers.
1) Woohoo! Then why not use PHP or one of its derivates, which don't even
bother to encourage proper design? PHP is designed JUST for this kind of
hackery, without all that pesky Java syntax. Plus, PHP is a lot more
forgiving of completely crappy designs.
2) I've no real answer for this, except to possibly ask why it's wise to
provide a hammer as a tool for, oh, computer repair - "It probably won't
work, but it COULD."
-----------------------------------------------------------
Joseph B. Ottinger joeo@cupid.suninternet.com
http://cupid.suninternet.com/~joeo HOMES.COM Developer
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Gal Shachor <sh...@il.ibm.com>.
Boyd Waters wrote:
>
> "Joseph B. Ottinger" wrote:
>
> > really think an SQL taglib really is a lousy replacement for proper
> > design, such as a bean that retrieves data from an indeterminate source.
>
> YES!! TOTALLY CORRECT! After implementing the example SQL tag, I
> immediately set it aside and my JSP pages use an object-based
> approach... that's why I refer to the object-based iterator in my sample
> code...
>
I would not call that a "lousy ... design" but an alternative design. It
is true that using Model-2 for accessing a database may looks like the
right
approach yet:
1. It force the company to have a good Java developer even for a very
simple project.
2. You create bean objects that wrap your result set, it is a good thing
for several reasons but if all you want to do is to create a simple
report
based on a database table then it is too much of an effort.
3. You stay with the same old problem of populating your page using
scriptlets.
On the other hand:
1. Many simple cases can be handled very easily using a tag library.
And after
the initial effort of creating the library, using it is really easy
(mainly
for non programmer persons).
2. You should remember that many of the database driven pages are in use
for
small scale/internal sites and for such sites you can not even assume
that
you are going to see a design (of any type). The site will just
happen, and
for these sites tag libraries are a life savers.
Sure, model-2 and its derivatives are technically better and the
architecture is
clean, but you do not use it every day.
Gal Shachor
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Eduardo Pelegri--Llopart <Ed...@eng.sun.com>.
Joe sayz...:
> eduardo sayz..:
> > TO clarify my premise: the page author is not creating the SQL query
> > directly but through a wizard/ page authoring tool. In such a case, you
> > just fire your wizard, which you use to create the query and probably
> > populate a list of fields available. Then you can use the tool, again,
> > to generate the presnetaiton interactively.
>
> This works, certainly... but why couldn't the tool create a reusable
> component just as easily? What's more the reusable component would be more
> efficient in the long run...
(to start with, I don't think there is "a right way", so ..)
I think what approach is best depends on the details of the usage
scenario.
To clarify mine: a developer is writing a presentation of some data that
really lives in a database. Say the JavaOne database. So, s/he goes
and writes a JSP page to extract that data and present it. Essentially
what s/he wants to create is a query on that database + some
presentation of that query. The JSP page can capture both by having a
custom action that is the query (plus any other data that may be needed
to present the query to the author nicely), plus some custom actions to
present the result of running the query. The reusuable code is the tag
library that is interacting with connection pooling, maybe caches, and
the database.
On the other hand, if your abstraction is represented in a number of
DBs, then maybe you want to encapsulate them into some object, maybe a
session EJB?, and then your custom tags would let you get at the data
via that abstraction. Perhaps this is done via an authoring tool that
knows about the DBs (maybe a la JavaBlend), but that tool will need to
keep track of extra information so you can present the original state to
the author when s/he wants to extend the abstraction. A bean
abstraction is probably what I'd also use if there is more validation to
do, etc.
I don't think that one scenario is always better than the other. It
depends on how close your query is to the DB, how quickly the queries
change, how long lived is your view of the data...
Does this help?
- eduard/o
"Joseph B. Ottinger" wrote:
>
> On Tue, 9 May 2000, Eduardo Pelegri--Llopart wrote:
>
> > Call me biased :-) but I don't see why in some cases a taglib that
> > encapsulates SQL is such a bad idea.
>
> Perhaps it's a personal bias, one that encourages JSP to be very simple -
> simple enough that web designers don't have to know Java or SQL or
> anything but HTML or XML in order to use JSP as a viable solution. I know
> a number of people (we'll call them "clients") who are very comfortable
> sending me boilerplate HTML, but who'd balk immediately at writing their
> own JSP... but who could be convinced to modify their own pages if the
> syntax was consistent. I realise that my bias here certainly isn't a
> constraint on JSP overall, and nothing prevents developers from doing
> traditional servlets via JSP (yes, guilty!) but in presentation, I far
> prefer JSP to remain "dumbed-down," and presentation-only. Generate the
> <table>? You bet. Generate the data for the table? That's business logic,
> and far better suited to a bean of some kind.
>
> > TO clarify my premise: the page author is not creating the SQL query
> > directly but through a wizard/ page authoring tool. In such a case, you
> > just fire your wizard, which you use to create the query and probably
> > populate a list of fields available. Then you can use the tool, again,
> > to generate the presnetaiton interactively.
>
> This works, certainly... but why couldn't the tool create a reusable
> component just as easily? What's more the reusable component would be more
> efficient in the long run...
>
> > We have a demo that does about 3/4ths of this using a DreamWeaver
> > extension that we will try to bring to JavaOne. A similar thing could
> > be done for GoLive5 using their SDK.
> >
> > DB queries are so important that I'd expect most authoring tools to
> > wire-in something like this.
>
> <rant>They probably would. Yay! Let's make JSP like PHP, and screw design
> methodologies!</rant> :)
>
> > Or I might be wrong... :-) Other opinions?
> >
> > - eduard/o
> >
> >
> > Boyd Waters wrote:
> > >
> > > "Joseph B. Ottinger" wrote:
> > >
> > > > really think an SQL taglib really is a lousy replacement for proper
> > > > design, such as a bean that retrieves data from an indeterminate source.
> > >
> > > YES!! TOTALLY CORRECT! After implementing the example SQL tag, I
> > > immediately set it aside and my JSP pages use an object-based
> > > approach... that's why I refer to the object-based iterator in my sample
> > > code...
> > >
> > > > ...my index page does it because I was too lazy to do it properly...
> > >
> > > ... but perhaps the SQL tag is useful for the same reason that you use
> > > JSP instead of writing servlets: to save time, to get something
> > > prototyped rapidly, to delegate to less-sophisticated members of your
> > > team.
> > >
> > > I'm out of the e-commerce space for the moment, but a tool like this
> > > would have saved my butt back in '98.
> > >
> > > -- boyd
> > >
> > > ---------
> > > Boyd Waters bwaters@nrao.edu
> > > National Radio Astronomy Observatory http://www.nrao.edu
> > > PO Box 0 Socorro, NM 87801 505.835.7346
> > >
> > > http://www.zocalo.net/~waters
> > > waters@zocalo.net
> > > ---------
> >
>
> -----------------------------------------------------------
> Joseph B. Ottinger joeo@cupid.suninternet.com
> http://cupid.suninternet.com/~joeo HOMES.COM Developer
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by "Joseph B. Ottinger" <jo...@suninternet.com>.
On Tue, 9 May 2000, Eduardo Pelegri--Llopart wrote:
> Call me biased :-) but I don't see why in some cases a taglib that
> encapsulates SQL is such a bad idea.
Perhaps it's a personal bias, one that encourages JSP to be very simple -
simple enough that web designers don't have to know Java or SQL or
anything but HTML or XML in order to use JSP as a viable solution. I know
a number of people (we'll call them "clients") who are very comfortable
sending me boilerplate HTML, but who'd balk immediately at writing their
own JSP... but who could be convinced to modify their own pages if the
syntax was consistent. I realise that my bias here certainly isn't a
constraint on JSP overall, and nothing prevents developers from doing
traditional servlets via JSP (yes, guilty!) but in presentation, I far
prefer JSP to remain "dumbed-down," and presentation-only. Generate the
<table>? You bet. Generate the data for the table? That's business logic,
and far better suited to a bean of some kind.
> TO clarify my premise: the page author is not creating the SQL query
> directly but through a wizard/ page authoring tool. In such a case, you
> just fire your wizard, which you use to create the query and probably
> populate a list of fields available. Then you can use the tool, again,
> to generate the presnetaiton interactively.
This works, certainly... but why couldn't the tool create a reusable
component just as easily? What's more the reusable component would be more
efficient in the long run...
> We have a demo that does about 3/4ths of this using a DreamWeaver
> extension that we will try to bring to JavaOne. A similar thing could
> be done for GoLive5 using their SDK.
>
> DB queries are so important that I'd expect most authoring tools to
> wire-in something like this.
<rant>They probably would. Yay! Let's make JSP like PHP, and screw design
methodologies!</rant> :)
> Or I might be wrong... :-) Other opinions?
>
> - eduard/o
>
>
> Boyd Waters wrote:
> >
> > "Joseph B. Ottinger" wrote:
> >
> > > really think an SQL taglib really is a lousy replacement for proper
> > > design, such as a bean that retrieves data from an indeterminate source.
> >
> > YES!! TOTALLY CORRECT! After implementing the example SQL tag, I
> > immediately set it aside and my JSP pages use an object-based
> > approach... that's why I refer to the object-based iterator in my sample
> > code...
> >
> > > ...my index page does it because I was too lazy to do it properly...
> >
> > ... but perhaps the SQL tag is useful for the same reason that you use
> > JSP instead of writing servlets: to save time, to get something
> > prototyped rapidly, to delegate to less-sophisticated members of your
> > team.
> >
> > I'm out of the e-commerce space for the moment, but a tool like this
> > would have saved my butt back in '98.
> >
> > -- boyd
> >
> > ---------
> > Boyd Waters bwaters@nrao.edu
> > National Radio Astronomy Observatory http://www.nrao.edu
> > PO Box 0 Socorro, NM 87801 505.835.7346
> >
> > http://www.zocalo.net/~waters
> > waters@zocalo.net
> > ---------
>
-----------------------------------------------------------
Joseph B. Ottinger joeo@cupid.suninternet.com
http://cupid.suninternet.com/~joeo HOMES.COM Developer
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Eduardo Pelegri--Llopart <Ed...@eng.sun.com>.
Call me biased :-) but I don't see why in some cases a taglib that
encapsulates SQL is such a bad idea.
TO clarify my premise: the page author is not creating the SQL query
directly but through a wizard/ page authoring tool. In such a case, you
just fire your wizard, which you use to create the query and probably
populate a list of fields available. Then you can use the tool, again,
to generate the presnetaiton interactively.
We have a demo that does about 3/4ths of this using a DreamWeaver
extension that we will try to bring to JavaOne. A similar thing could
be done for GoLive5 using their SDK.
DB queries are so important that I'd expect most authoring tools to
wire-in something like this.
Or I might be wrong... :-) Other opinions?
- eduard/o
Boyd Waters wrote:
>
> "Joseph B. Ottinger" wrote:
>
> > really think an SQL taglib really is a lousy replacement for proper
> > design, such as a bean that retrieves data from an indeterminate source.
>
> YES!! TOTALLY CORRECT! After implementing the example SQL tag, I
> immediately set it aside and my JSP pages use an object-based
> approach... that's why I refer to the object-based iterator in my sample
> code...
>
> > ...my index page does it because I was too lazy to do it properly...
>
> ... but perhaps the SQL tag is useful for the same reason that you use
> JSP instead of writing servlets: to save time, to get something
> prototyped rapidly, to delegate to less-sophisticated members of your
> team.
>
> I'm out of the e-commerce space for the moment, but a tool like this
> would have saved my butt back in '98.
>
> -- boyd
>
> ---------
> Boyd Waters bwaters@nrao.edu
> National Radio Astronomy Observatory http://www.nrao.edu
> PO Box 0 Socorro, NM 87801 505.835.7346
>
> http://www.zocalo.net/~waters
> waters@zocalo.net
> ---------
RE: ANNOUNCE: Example SQL Taglib for JSP...
Posted by rb...@mac.com.
The SQL tags are useful for the same reason people insist on using
COld-Fusion - you don't have to be a programmer to use them. I guess they
will be very used (if done in an easy way - I haven't seen them, but I have
guessed what they are)
> -----Original Message-----
> From: bwaters@aoc.nrao.edu [mailto:bwaters@aoc.nrao.edu]
> Sent: Sunday, May 07, 2000 12:07 AM
> To: taglibs-dev@jakarta.apache.org
> Subject: Re: ANNOUNCE: Example SQL Taglib for JSP...
>
(..)
> ... but perhaps the SQL tag is useful for the same reason that you use
> JSP instead of writing servlets: to save time, to get something
> prototyped rapidly, to delegate to less-sophisticated members of your
> team.
>
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Boyd Waters <bw...@aoc.nrao.edu>.
"Joseph B. Ottinger" wrote:
> really think an SQL taglib really is a lousy replacement for proper
> design, such as a bean that retrieves data from an indeterminate source.
YES!! TOTALLY CORRECT! After implementing the example SQL tag, I
immediately set it aside and my JSP pages use an object-based
approach... that's why I refer to the object-based iterator in my sample
code...
> ...my index page does it because I was too lazy to do it properly...
... but perhaps the SQL tag is useful for the same reason that you use
JSP instead of writing servlets: to save time, to get something
prototyped rapidly, to delegate to less-sophisticated members of your
team.
I'm out of the e-commerce space for the moment, but a tool like this
would have saved my butt back in '98.
-- boyd
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by "Joseph B. Ottinger" <jo...@suninternet.com>.
I'm not sure that embedding SQL in a JSP page is such a great idea,
really. Not that I'm such a perfect coder that I've not done it (in fact,
my index page does it because I was too lazy to do it properly) but I
really think an SQL taglib really is a lousy replacement for proper
design, such as a bean that retrieves data from an indeterminate source.
-----------------------------------------------------------
Joseph B. Ottinger joeo@cupid.suninternet.com
http://cupid.suninternet.com/~joeo HOMES.COM Developer
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Boyd Waters <bw...@aoc.nrao.edu>.
Michal Mosiewicz wrote:
> > Attached is a (10K) jar file that contains source code for
> > implementations of the SQL Taglib discussed in the JavaServer Pages 1.1
> > specification, sections A.2.1 and A.2.2
>
> Poor solution. Run it with Oracle and you'll certainly run out of
> cursors. You have to close connections, you have to close statements,
> you have to close resultSets as soon as they are no longer needed.
>
> -- Mike
Mike:
You're absolutely correct -- in my "normal" JDBC code I am quite careful
about closing JDBC resources as soon as possible. I should have
mentioned this problem in the comments to the example code.
I'm still trying to figure out the interaction between JSP servlet
life-cycles and these JSP tags. I've written JDBC servlets, no problem -
I have control. But with these tags -- ?
CONNECTION MANAGMENT
In particular, with our JDBC library (Ingres (!)) here at NRAO-Socorro,
connections take a *long* time to set up, but after that things are
fast. Connection-pooling is therefore desirable; you keep a small set of
connections "open" and re-use them as much as possible.
In my "in-house" implementation of the Connection tag, I use such a
scheme by delegating to a Connection Factory which implements connection
pooling:
public Connection getConnection() throws JspException {
if( conn == null ) {
try {
conn = ConnectionFactory.Impl.makeConnection( userID, password );
}
catch( SQLException e ) {
throw new JspException( e.getMessage() );
}
}
return conn;
}
RESULTSET MANAGMENT
You'll note that I keep the RecordSet as a memeber variable, and then
close it in the release() method of the Query tag.
You shouldn't do this, because it's difficult to control the creation of
server-side cursors in JDBC. With Visual Basic Active Data Objects (ADO)
and MS SQL Server, you can specify client-side cursors. I can't see a
way to do this exactly in the JDBC 2.0 spec, consult your driver's
documentation.
Note that you can (and should) specify that the ResultSet is read-only;
this might tell your JDBC driver to implement the cursor client-side:
instead of
Statement stmt = conn.createStatement();
say
Statement stmt =
conn.createStatement( ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY );
Finally, what you should *really* do is to "cache" the results in a
Vector of EntityBeans and get rid of the ResultSet ASAP. Or choose not
to cache the results.
So Mike is right about that. You shouldn't keep the ResultSet around. I
was keeping it around because I was going to implement caching and then
thought it would complicate the example.
STATEMENT MANAGMENT
You'll note that I didn't issue a stmt.close() command in the
doAfterBody() -- why not?
Very simple. I forgot. Oops.
--
If you've got an improvemed implementation of the example, please post
it back to me!
Cheers!
-- boyd
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------
Re: ANNOUNCE: Example SQL Taglib for JSP...
Posted by Michal Mosiewicz <mi...@interdata.com.pl>.
Boyd Waters wrote:
>
> Howdy all:
>
> Attached is a (10K) jar file that contains source code for
> implementations of the SQL Taglib discussed in the JavaServer Pages 1.1
> specification, sections A.2.1 and A.2.2
Poor solution. Run it with Oracle and you'll certainly run out of
cursors. You have to close connections, you have to close statements,
you have to close resultSets as soon as they are no longer needed.
-- Mike
ANNOUNCE: Example SQL Taglib for JSP...
Posted by Boyd Waters <bw...@aoc.nrao.edu>.
Howdy all:
Attached is a (10K) jar file that contains source code for
implementations of the SQL Taglib discussed in the JavaServer Pages 1.1
specification, sections A.2.1 and A.2.2
(No, I haven't done the iteration part (Section A.2.3) yet... read
on...)
I hope you find this somewhat illustrative.
Also included in the JAR are the Taglib (TLD) file and an example JSP
file.
Have fun,
-- boyd
PS:
See http://www.orionserver.com/tutorials/tagtut/lesson3/lesson3.html for
Magnus Rydin's excellent tutorial on implementing iteration.
================
JSP SQL TagLib EXAMPLES
Boyd Waters, NRAO bwaters@aoc.nrao.edu
May 3 2000
These Java classes are a toy implementation of the SQL tags
discussed in Section A.2.1 and A.2.2 of the JavaServer Pages 1.1
Specification.
This document should be available at
http://java.sun.com/products/jsp/download.html
THIS IS EXAMPLE CODE INTENDED FOR EDUCATIONAL PURPOSES ONLY!!!
DO NOT USE IN PRODUCTION SYSTEMS!
Also they want us to say this:
//# Copyright (C) 2000 Associated Universities, Inc. Washington DC, USA.
//#
//# This program is free software; you can redistribute it and/or modify
//# it under the terms of the GNU General Public License as published by
//# the Free Software Foundation; either version 2 of the License, or
//# (at your option) any later version.
//#
//# This program is distributed in the hope that it will be useful, but
//# WITHOUT ANY WARRANTY; without even the implied warranty of
//# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
//# General Public License for more details.
//#
//# You should have received a copy of the GNU General Public License
//# along with this program; if not, write to the Free Software
//# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
//#
//# Correspondence concerning OMS software should be addressed as
follows:
//# Array Support Group - VLBA Operations
//# National Radio Astronomy Observatory
//# P. O. Box 0
//# Socorro, NM 87801 USA
Frankly, a much better approach (IMHO) is discussed at
http://www.orionserver.com/tutorials/tagtut/lesson3/lesson3.html
-- that is, you should write Beans which manage their persistent
state (get themselves out of a database) and then use the beans.
But perhaps the SQL tags will lead to some quick-and-dirty useful
sites...
Hoping this helps, let me know if you improve this...
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------
Building the examples, etc...
Posted by Boyd Waters <bw...@aoc.nrao.edu>.
Howdy all...
Some things which have been driving me nuts, hope what I've found out
helps...
1)
The build.xml for the jakarta-taglibs that I'm getting from CVS doesn't
work with my version of Ant.
At least one problem seems to be that my version of Ant ignores the
<property name="varName" value="foobar"/>
declarations in the build.xml files in jakarta-taglibs.
WORKAROUND:
Wrap all these property declarations in an "init" target, and then tell
the other targets about the init. Here's an example from a JSP tutorial
webapp I'm working on:
<target name="init">
<property name="build.compiler" value="classic"/>
<property name="deploy.home"
value="${tomcat.home}/webapps/tutorial"/>
<property name="dist.home" value="${deploy.home}"/>
<property name="dist.src" value="tutorial.jar"/>
<property name="dist.war" value="tutorial.war"/>
<property name="javadoc.home" value="${deploy.home}/javadoc"/>
</target>
<target name="compile" depends="prepare" init="init">
^^^^^^^^^^^
I figured this one out by building the jakarta-tomcat from source.
2)
build.sh scripts for Unix assume $JAVA_HOME (and other) environment
variables are set. With Java 2 installations, it's not unusual to avoid
setting these vars.
FIX:
add these lines to the beginning of your build.sh
f [ -z "$JAVA_HOME" ]
then
JAVACMD=`which java`
if [ -z "$JAVACMD" ]
then
echo "Cannot find JAVA. Please set your PATH."
exit 1
fi
JAVA_BINDIR=`dirname $JAVACMD`
JAVA_HOME=$JAVA_BINDIR/..
fi
Again, got this from jakarta-tomcat...
3)
With all that now working, I can now type ./build.sh and the build looks
like it works.
BUT the jar files have NO classes in them!!! AAARGGGH!!!!
WORKAROUND:
curse, reverse-engineer what Ant was trying to do, build all the classes
with the appropriate javac invocations. Then build jar files from those
classes
4)
The examples dir structure is convoluted and doesn't work well with the
other samples in the jakarta-tomcat distribution.
WORKAROUND:
I created a jsp-examples webapp "by hand".
5)
Fixing broken jsp/java/web.xml files does not fix the webapp, even
through a re-start of tomcat
WORKAROUND:
In $TOMCAT_HOME/work directory, manually delete the directory that
corresponds to your webapp and re-start tomcat.
6)
The taglib .tld files in the xsl-taglibs example does not properly refer
to the fully-qualified xsl tag class files
FIX:
prepend "org.apache.taglibs." to all "xsltags.Classname" class names in
the taglib.
7)
Tomcat does not recognize/load JAR files in the WEB-INF/lib directories.
FIX:
See the Tomcat FAQ, and then add these lines to
TOMCAT_SOURCE_HOME/src/share/org/apache/tomcat/context/DefaultCMSetter.java
line 170:
File f = new File(base + "/WEB-INF/lib");
+ if (!f.isAbsolute()) { //Check that we have the correct path to apps
lib dir
+ ContextManager cm = context.getContextManager();
+ f = new File(cm.getHome(), base + "/WEB-INF/lib");
}
Vector jars = new Vector();
getJars(jars, f);
for(int i=0; i < jars.size(); ++i) {
String jarfile = (String) jars.elementAt(i);
+ System.out.println("Loading jar:" + new File(f,jarfile ));
loader.addRepository( new File( base + "/WEB-INF/lib/" +jarfile ));
and then re-build Tomcat.
8)
The xsl-taglibs example is not working, gets an error which seems to be
related to the thing actually running rather than configuration woes:
java.lang.NullPointerException
at
org.apache.xalan.xpath.xml.FormatterToXML.init(FormatterToXML.java:403)
FIX:
Work on something else for a while...
=====================================================
Whew!
Um, this is not yet an easy-to-use replacement for PHP :-)
Hope this helps,
--boyd
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------