At 20:07 -0400 8/28/02, Henri Yandell wrote:
I always assumed Safari was only for OReilly books.
No, they have books by other publishers, too.
Must check it out a bit more sometime, maybe convince the company to
subscribe me for a book.
Hen
On Wed, 28 Aug 2002, Wendy Smoak wrote:
Shawn
Hey thanks for the book info.
Can JSTL use connection pooling for a databases?
Tim
-Original Message-
From: David M. Karr [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 04, 2002 2:18 AM
To: [EMAIL PROTECTED]
Subject: Re: JSTL in Action: first few chapters
Dave == Dave Newton [EMAIL
On Sun, 4 Aug 2002, The Kelley's wrote:
Can JSTL use connection pooling for a databases?
JSTL lets you configure any DataSource to access a database. The
DataSource may indeed implement connection pooling. Setting it up is as
easy as pointing to a pooling DataSource in your application's
Now if only I learned to proof read or type :P
I skimmed through expression language portion of the book and found it easier to read
than the official spec.
peter
David M. Karr wrote: Dave == Dave Newton writes:
Dave Peter Lin wrote:
reading the spec isn't always as simple as one would
Someone at work bought an electronic version and
ordered a few copies. If you are serious about using
JSTL, I would recommend it.
reading the spec isn't always as simple as one would
like. For example, the use of hashmap was totally
clear to me, until I read the section in shawn's book.
I must
Peter Lin wrote:
reading the spec isn't always as simple as one would
like. For example, the use of hashmap was totally
clear to me, until I read the section in shawn's book.
Er... :D
Dave
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
If you don't want to let the user set information on an object with
c:set, it must not have setter methods. You can always wrap the
underlying object in a wrapper that provides only one-way access, but an
interface does not provide this protection.
mmh?! thanks so fare. i'm a bit
i think the loss of using interfaces is a big disadvantage. on the
serverside it will not be clear, why i have a class User with getter
and setter and a User2 with just setter.
One of the prices we pay for more convenience for page authors is the loss
of some distinctions like this.
i think the loss of using interfaces is a big disadvantage. on the
serverside it will not be clear, why i have a class User with getter
and setter and a User2 with just setter.
I disagree. I believe it's a huge advantage. It means that I don't have to
code server-side objects
On Tue, 16 Jul 2002, Leif Hanack wrote:
with jstl i still can set a new value:
c:set target=${user} property=name value=newname/
why?! is this a bug?!
it seems as if the EL does not care about which interface i defined.
he always work on the real object type.
any help?!
Indeed,
Nevermind, just checking for empty sessionScope works fine
alex
-Original Message-
From: Alex Reznik [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 16, 2002 12:05 PM
To: 'Tag Libraries Users List'
Subject: JSTL: session tracking
Hi,
I am trying to track a session using JSTL that was
On Tue, 16 Jul 2002, Alex Reznik wrote:
I am trying to track a session using JSTL that was originated as a regular
jsp page,
%@page session =true %, i need to make a ckeck something like c:if
test=${empty session}, redirect...
what should be the body of my test?\
Subject: RE: JSTL + XSLT
On Fri, 12 Jul 2002, Manfred Riem wrote:
I actually am doing that. See var=xsl and later
xslt=${xsl}? And
the error stays the Same.
Hmm - I think I actually misread your original code. Sorry
about that.
I've taken a closer look and tried to correlate
Hi there,
Thanx for the prompt reply. Anyway, I've got it to work
like a charm with one base stylesheet. However it seems
to fail when I use an xsl:import in the stylesheet. Is
this supported?
At least Xalan standalone works fine, but now with the
x:transform tag it fails.
Any ideas?
Manfred
On Fri, 12 Jul 2002 [EMAIL PROTECTED] wrote:
Thanx for the prompt reply. Anyway, I've got it to work like a charm
with one base stylesheet. However it seems to fail when I use an
xsl:import in the stylesheet. Is this supported?
Yes, xsl:import should work. Depending on where your stylesheet
-
From: Shawn Bayern [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 6:27 AM
To: Tag Libraries Users List
Cc: [EMAIL PROTECTED]
Subject: RE: JSTL + XSLT
On Fri, 12 Jul 2002 [EMAIL PROTECTED] wrote:
Thanx for the prompt reply. Anyway, I've got it to work
like a charm
with one
AM
To: Manfred Riem
Cc: 'Tag Libraries Users List'
Subject: RE: JSTL + XSLT
On Fri, 12 Jul 2002, Manfred Riem wrote:
I've tried a couple of times and I don't seem to get it
working with
the x:transform tag. Should it be url=...S... or
xsltSystemId=S... ?
Oops - sorry
On Fri, 12 Jul 2002 [EMAIL PROTECTED] wrote:
c:set var=xslc:import
url=style/default/chapter_content.xsl//c:set
c:set var=xmlc:import url=source/${param.id}/index.xml//c:set
x:transform xml=${xml} xslt=${xsl}
xsltSystemId=style/default/chapter_content.xsl/
The problem is just that these
To: [EMAIL PROTECTED]
Cc: 'Tag Libraries Users List'
Subject: RE: JSTL + XSLT
On Fri, 12 Jul 2002 [EMAIL PROTECTED] wrote:
c:set var=xslc:import
url=style/default/chapter_content.xsl//c:set
c:set var=xmlc:import
url=source/${param.id}/index.xml//c:set
x:transform xml=${xml} xslt
On Mon, 8 Jul 2002, Manfred Riem wrote:
Hi there,
I've got a question about the XSLT stuff available in JSTL.
I want to be able to do the following thing.
1. Load the XML document from a specific URL
2. Load the XSL document from a specific URL
3. Add runtime parameters to the
Well, I tried that just now and I had the same result.
I just tried getting the DataSource manually and feeding it to the tag
and got a little more descriptive error:
%
javax.naming.InitialContext ctx = new javax.naming.InitialContext();
javax.sql.DataSource ds =
I'm browsing through the source of DataSourceUtil.java and the
Exception is generated here:
if (rawDataSource instanceof String) {
try {
Context ctx = new InitialContext();
// relative to standard JNDI root for J2EE app
HI, Mike.
Well, I tried that just now and I had the same result.
I just tried getting the DataSource manually and feeding it to the tag
and got a little more descriptive error:
%
javax.naming.InitialContext ctx = new javax.naming.InitialContext();
Doh!, This is my fault... I tried to set the dataSource earlier by doing a :
c:set var=ds%= ds %/c:set
Once I realized that this was going to cause the objects toString()
method to be called, I changed the code to do:
request.setAttribute(ds, ds);
Well, I forgot to remove the c:set
On Sun, 30 Jun 2002, Michael Forster wrote:
is there a way in JSTL to get the length of a java.util.List?
Not easily, unfortunately. This functionality will be added in JSP 2.0.
In the meantime, you can wrap the List in an object that returns both the
List and the count:
getList() {
You know, I think you're correct... I'll grab the developers version of
4.0 which should support it.
Shawn Bayern wrote:
Others have been having this problem too, and since I don't have JRun, I
can't look more closely into the problem. Does JRun 3.1 support JSP 1.2?
I was under the
I'll try to isolate the problem more tommorrow, but I'm off home now
:-)
It's OK now. And I'm too embarrassed to admit what the problem was.
Amazing what a night's sleep can do!
Steve Slatcher
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
Hi, Peter,
Thanks for your information.
The latest Tomcat I can find on the jakarta site is 4.1.3. After I drop the three
jarballs from it in the lib directory, I get an
error:
java.lang.NoClassDefFoundError: org/apache/commons/collections/FastHashMap
What step I miss? Or where I can get
, it's not recomended, only for testing.
-Original Message-
From: Vernon Wu [mailto:[EMAIL PROTECTED]]
Sent: 26. júní 2002 09:22
To: Tag Libraries Users List; Peter Lin
Subject: Re: JSTL leads to a serious performance issue
Hi, Peter,
Thanks for your information.
The latest
]
-Original Message-
From: Vernon Wu [mailto:[EMAIL PROTECTED]]
Sent: 26. júní 2002 10:31
To: Tag Libraries Users List
Subject: Re: RE: JSTL leads to a serious performance issue
Hi, Reynir,
Your suggestion seems to be a reasonable solution.
I, however, get another error
, only for testing.
-Original Message-
From: Vernon Wu [mailto:[EMAIL PROTECTED]]
Sent: 26. júní 2002 09:22
To: Tag Libraries Users List; Peter Lin
Subject: Re: JSTL leads to a serious performance issue
Hi, Peter,
Thanks for your information.
The latest Tomcat I
keep on trying you're almost there!!!
:)
-reynir
-Original Message-
From: Vernon Wu [mailto:[EMAIL PROTECTED]]
Sent: 26. júní 2002 10:54
To: Tag Libraries Users List
Subject: Re: JSTL leads to a serious performance issue
I download the 4.1.5 and drop the four jar files
On Tue, 25 Jun 2002 [EMAIL PROTECTED] wrote:
Hi all
Has anyone had a problem with JSTL becoming too complex?
Here's the story: We are a news site that's migrating to JSTL for complex
news stories. Now, you can imagine that a story contains a number of
paragraphs which in return contain
On Tue, 25 Jun 2002, Steve Slatcher wrote:
If table blah had 3 records, wouldn't you expect
sql:query var=queryselect * from blah/sql:query
c:forEach var=row items=${query.rows} varStatus=status
pc:out value=${status.count}//p
/c:forEach
to produce something like
p1/p
p2/p
Shawn Bayern wrote:
On Tue, 25 Jun 2002, Steve Slatcher wrote:
If table blah had 3 records, wouldn't you expect
sql:query var=queryselect * from blah/sql:query
c:forEach var=row items=${query.rows} varStatus=status
pc:out value=${status.count}//p
/c:forEach
to produce something
Hi John,
Thanks for your detailed message! Some responses:
On Fri, 21 Jun 2002, John Hicks wrote:
1. The KISS approach
I first tried a simple:
UPDATE programs
SET org = 'c:out value=${param.org} default= /',
name = 'c:out value=${param.name} default= /',
. .
Thanks for your superfast reponse!!
I'll be happy to forward you my JSP etc. (I'm not fast as
you, so give me a few more minutes!!)
In the meantime, one point to ponder:
On Friday 21 June 2002 03:09 pm, you wrote:
I finally traced this problem to undefined request
parameter fields,
On Fri, 21 Jun 2002, John Hicks wrote:
On Friday 21 June 2002 03:09 pm, you wrote:
I finally traced this problem to undefined request
parameter fields, specifically radio buttons and check
boxes (i.e. whenever a check box was left unchecked or
when the user didn't select any of
On Tue, 18 Jun 2002, Halvorson, Loren wrote:
I just downloaded the standard tag library RC1 newly posted by Shawn which
is supposed to be the same as the 1.0 release. I noticed that the XML
parser has been changed from Xerces to Crimson, and wonder if this is what
is causing the following
Hi,
Shawn Bayern wrote:
| On Thu, 13 Jun 2002, Wolfgang Röckelein wrote:
|is it possible to set a BigInteger property with the c:set target=
|property= in the EL JSTL? Same for a parameter in a prepared SQl
|statement?
|
| You can set any sort of property with
|
| c:set target=... property=...
On Thu, 13 Jun 2002, Wolfgang Röckelein wrote:
is it possible to set a BigInteger property with the c:set target=
property= in the EL JSTL? Same for a parameter in a prepared SQl
statement?
You can set any sort of property with
c:set target=... property=... value=... /
The type of the
: Re: JSTL XML, URL, and SQL tags, does anyone use them?
Thanks Boris, that is a good insight.
If you don't mind, have you personally found the JSTL SQL, XML, or URL
tags (or equivalent other taglibs) helpful while working on a project?
I.E. has there been a situation where you needed to get
At 22:39 -0400 6/11/02, Jayson Falkner wrote:
Paul DuBois wrote:
Why make that assumption? One of JSTL's strongest points (my opinion) is
that it makes it easy to start writing JSP applications *without* having
to know any Java. At the very least, JSTL certainly minimizes the amount
of Java you
List [EMAIL PROTECTED]
Sent: Tuesday, June 11, 2002 10:12 PM
Subject: Re: JSTL XML, URL, and SQL tags, does anyone use them?
Thanks Boris, that is a good insight.
If you don't mind, have you personally found the JSTL SQL, XML, or URL
tags (or equivalent other taglibs) helpful while working
Paul DuBois wrote:
Well, now you're re-framing your question to get the answer you want. Your
original message asked a much more general question, which was whether
anyone
uses JSTL and finds it helpful.
Yes I am, sorry I don't mean to waste time, but, I loaded the question
so I could
From: Jayson Falkner [EMAIL PROTECTED]
if the applications performs sufficiently well without finer-grained
management of such resources, then development is easier with no loss
in quality of the code.
I agree. Do you think the JSTL SQL and XML tags hurt future quality of
code?
Huh?
On Mon, 10 Jun 2002, Jayson Falkner wrote:
In general, JSTL requires that users know less, making its use
easier. For instance, users of JSTL tags don't need to understand
the lifecycle considerations associated with a JDBC Connection,
Statement, or ResultSet;
Do you think it
Thank James, this is some good feedback.
James Strachan wrote:
I agree. Do you think the JSTL SQL and XML tags hurt future quality of
code?
Huh?
Just meaning maintenance as you answered later on in the e-mail.
For instance, a MVC pattern can keep all of its View components
regardless of
Thanks again for the comments Shawn,
Shawn Bayern wrote:
I think making functionality available to those who know less is what
abstraction is all about. As a point of comparison, Microsoft .NET claims
to let a number of languages interoperate. But all of these languages
exist at roughly
Thanks for the feedback Hans,
Hans Bergsten wrote:
Absolutely. If you have experience with a real programming language,
learning Java in itself is a lot of work. Learning servlets, JDBC,
and at least a basic idea about multithreading issues on top of that
is just too much. And some people
At 14:51 -0400 6/11/02, Jayson Falkner wrote:
Thanks for the feedback Hans,
Hans Bergsten wrote:
Absolutely. If you have experience with a real programming language,
learning Java in itself is a lot of work. Learning servlets, JDBC,
and at least a basic idea about multithreading issues on top of
11, 2002 1:15 PM
Subject: Re: JSTL XML, URL, and SQL tags, does anyone use them?
Thank James, this is some good feedback.
James Strachan wrote:
I agree. Do you think the JSTL SQL and XML tags hurt future quality of
code?
Huh?
Just meaning maintenance as you answered later on in the e
On Tue, 11 Jun 2002, Borislav Iordanov wrote:
In short, at least in my experience, this presentation only layer
where data is only formatted to look nice is a myth. Or where it is
not a myth, the high decoupling is somewhat artificial and creates an
unnecessary complexity at least as
Paul DuBois
I have your book MySQL Edicion Especial - Prentice Hall ISBN 84-205-2956-7
of Spain.
It is really good.
I have a problem. this is:
I have a database in MySQL with 13618 books. I make SQL queries to this
database via JSP taglibs activated with a form. An example:
De windows a
-
From: Jayson Falkner [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Tuesday, June 11, 2002 1:15 PM
Subject: Re: JSTL XML, URL, and SQL tags, does anyone use them?
Thank James, this is some good feedback.
James Strachan wrote:
I agree. Do you think the JSTL
Jayson Falkner wrote:
Thanks for the feedback Hans,
Hans Bergsten wrote:
Absolutely. If you have experience with a real programming language,
learning Java in itself is a lot of work. Learning servlets, JDBC,
and at least a basic idea about multithreading issues on top of that
is just
Paul DuBois wrote:
Why make that assumption? One of JSTL's strongest points (my opinion) is
that it makes it easy to start writing JSP applications *without* having
to know any Java. At the very least, JSTL certainly minimizes the amount
of Java you have to know.
The assumption would be if
Hans Bergsten wrote:
I'm not sure where you're going with these questions. If you're asking
if the majority would be better off not learning JSTL at all, I say
you're wrong; JSTL is a far better alternative than scriptlets for
the iterations and conditional processing you will always have in
In short, at least in my experience, this presentation only layer
where data is only formatted to look nice is a myth. Or where it is
not a myth, the high decoupling is somewhat artificial and creates an
unnecessary complexity at least as difficult to maintain as the
mixture of
Thanks for the comments Hans.
As Shawn and David, I think these types of actions make sense. It's
dangerous to think that one size fits all.
Agreed, but could you elaborate on your reasons? You didn't explain why
it is dangerous.
By one size fits all, do you mean assuming everyone should
On Mon, 10 Jun 2002, Jayson Falkner wrote:
Overall your opinion seems to be the JSTL tags would just be easier
and accomplish the same thing. I tend to think they are not easier at
all, just a different approach. Do you think it is wise to promote
the use of these tags to new users?
On Fri, 7 Jun 2002, David Geary wrote:
Good question. One thing to consider is that you can use some of those
tags in read-only mode, and not break the MVC paradigm.
In fact (just to expand on this), out of the tags Jayson listed,
sql:update is the only one that typically will have a
On Tue, 28 May 2002, Paul DuBois wrote:
In an EL expression, does the identifier null return to the literal
null value, or does it refer to a JSTL variable named null.
null is a keyword in the EL, and it refers to null itself, not a
variable named null
For example, if I want to explicitly
On Tue, 28 May 2002, Paul DuBois wrote:
In an EL expression, does the identifier null return to the literal
null value, or does it refer to a JSTL variable named null.
null is a keyword in the EL, and it refers to null itself, not a
variable named null
Thanks.
For example, if I want to
On Tue, 28 May 2002, Paul DuBois wrote:
So, for example:
c:set var=myVar scope=session value=${null} /
would be equivalent to this?
% session.removeAttribute (myVar) %
Yes, or
c:remove var=myVar scope=session /
I've read that section, but I wasn't quite clear on how to interpret
Hi Paul. Sorry for my delay in answering questions! I've been on the
road.
Yeah, I wondered about that. Usually JSTL questions on this list get
answered in a matter of minutes. :-)
JSTL allows varName[propertyName] syntax. I'm curious about the quoting
requirements for propertyName.
On Mon, 20 May 2002, Paul DuBois wrote:
I'm curious whether it's possible to use dotted names as lvalues in
JSTL tags.
I assume you mean, can you assign to them? Not as such. But c:set
now lets you perform the assignment you're looking for. Instead of this:
c:set var=sessionScope.count
On Mon, 20 May 2002, Paul DuBois wrote:
I'm curious whether it's possible to use dotted names as lvalues in
JSTL tags.
I assume you mean, can you assign to them?
Right, exactly.
Not as such. But c:set
now lets you perform the assignment you're looking for. Instead of this:
c:set
On Mon, 20 May 2002, Paul DuBois wrote:
Thanks!
By now lets you perform ... do you mean in beta2, or in more recent
nightly builds? (I just tried it with beta2 and got an
UnsupportedOperationException.)
I don't believe it was fully implemented in Beta2; try one of the recent
nightly
The article you refer to is out of date. You can use c:import to
retrieve them from external URLs or via the RequestDispatcher: e.g.,
c:import var=xml url=http://my/file.xml/
c:import var=xslt url=/stylesheets/1.xslt/
--
Shawn Bayern
JSP Standard Tag Library http://www.jstlbook.com
If anybody were to place a 1.1-ified JSTL port under
sourceforge, I'm sure it would get used.
I think Jakarta would be happy to host such a thing. It's been mentioned
once or twice and is really just waiting for someone with the itch to go
ahead and do it. I imagine that those with the itch
Thanks Stu, your email helps clarify the situation for me. I won't be
able to volunteer do the work to get JSTL back into 1.1 now although
I did tweak a few tags in JSTL to see if it work with 1.1 just to ask
what if...? At least it sounds like backporting is a possibility
though.
As for my
At 20:12 -0500 5/9/02, Ryan LeCompte wrote:
Hello,
I am trying to use the JSTL in my JSP with the following:
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
However, I get an error that says:
Error: (line 1): Could not parse deployment descriptor:
java.io.IOException: can
not resolve
/lib directory. Any ideas?
Ryan LeCompte
[EMAIL PROTECTED]
http://www.ull.edu/~rml7669
- Original Message -
From: Paul DuBois [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Thursday, May 09, 2002 9:21 PM
Subject: Re: JSTL taglib not found.
At 20:12 -0500 5/9/02
List [EMAIL PROTECTED]
Sent: Thursday, May 09, 2002 9:21 PM
Subject: Re: JSTL taglib not found.
At 20:12 -0500 5/9/02, Ryan LeCompte wrote:
Hello,
I am trying to use the JSTL in my JSP with the following
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
However, I get
Yes, this is definitely Beta2. It's such a strange problem..
Ryan
- Original Message -
From: Shawn Bayern [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Thursday, May 09, 2002 11:08 PM
Subject: Re: JSTL taglib not found.
Are you sure you're working
On Thu, 9 May 2002, Ryan LeCompte wrote:
Yes, this is definitely Beta2. It's such a strange problem..
This may not make a difference, but you will also need the other JARs
included in the Beta2 distribution. (Your prior message mentioned you
installed standard.jar to WEB-INF/lib.) In
I was hoping to find a way in which I could build 1.2 and 1.1 compliant
taglibs from the same project. If it was just a case of adding some 1.2
tags then I'd imagine it could be done, but if I add the evaluator then
it would hit my main tags and I'd have to find some other build method.
I'd
Paul DuBois wrote:
After issuing a SELECT query with sql:query, you can access the row
count with ${rs.rowCount} (where rs is the result set variable).
However, in other APIs such as Perl DBI, the equivalent construct
is deprecated because some drivers do not return a count reliably;
the
At 14:57 -0700 5/6/02, Hans Bergsten wrote:
Paul DuBois wrote:
After issuing a SELECT query with sql:query, you can access the row
count with ${rs.rowCount} (where rs is the result set variable).
However, in other APIs such as Perl DBI, the equivalent construct
is deprecated because some drivers
Paul DuBois wrote:
At 14:57 -0700 5/6/02, Hans Bergsten wrote:
Paul DuBois wrote:
After issuing a SELECT query with sql:query, you can access the row
count with ${rs.rowCount} (where rs is the result set variable).
However, in other APIs such as Perl DBI, the equivalent construct
is
At 02:41 PM 5/6/2002, Henri Yandell wrote:
This is probably for Shawn, but maybe another JSTL implementor.
Is there any documentation describing how to add JSTL-EL support to a
taglib?
None yet published that I'm aware of. Also, since this isn't part of the
JSTL standard, it would necessarily
We choose to withhold our extreme it knowledge from your benefit. Next
please.
Brady Moritz
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 5:50 PM
To: Tag Libraries Users List
Subject: Re: JSTL emulation
At 02:41 PM 5/6/2002, Henri
Martin's right -- that's currently the best interface. The internal
organization of the EL (where it's going to end up being distributed from,
what the precise language-level interface will be) are still somewhat in
flux, so I've refrained, for the moment, from documenting its current
state too
Just to amplify what Hans said, the reason that retrieving a row count
isn't problematic in JSTL is that the exposed interface (Result) is
designed to cache rows. Effectively, JSTL does count the rows as you
fetch them, and ${result.rowCount} simply resolves to the internal
counter we keep. We
Sorry guys, this was actually meant as a joke message to a friend,
somehow I sent it here instead... kinda funny though ;)
Brady Moritz
-Original Message-
From: Brady Moritz [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 9:20 PM
To: 'Tag Libraries Users List'
Subject: RE: JSTL
On Fri, 3 May 2002, Shawn Bayern wrote:
How have you set up the standard-examples web application? Somehow, it
seems you've picked up the JAXP 1.2 support classes. The current build,
however, uses JAXP 1.1.
As I said, all I did was make a symlink inside /usr/java/tomcat/webapps
that points
Very very unlikely. I don't think any drivers provide this yet. The JDBC
3.0 spec does have such a thing, but it's new and not really common.
Two Options:
1) Find some SQL that is mysql specific to find it out. I know there is
something, I'm just not sure what. I'll try to hunt it out.
2) Look
this might not be the answer you're looking for, but in high end
databases, the recommended method of doing incremental unique ID is to
use a stored procedure which gets the next id and uses it in an insert
statement. The stored procedure then passes the unique id back.
autoincrement is
Right - there isn't a portable way of doing this with JDBC. You can use a
database-specific feature to acquire the info, but note that you'll need
to do this inside a sql:transaction tag, since the last OID-type
features are always connection-specific, and sql:transaction is
currently the only
The problem is not about your own thread doing several related updates,
but some other thread doing an INSERT just after you do,
and before you get a chance to SELECT LAST_INSERT_ID()
If there is any chance of it (anything except a single user can do it)
you must ensure thread safety with either
At 13:35 -0400 5/1/02, Morris Hirsch wrote:
The problem is not about your own thread doing several related updates,
but some other thread doing an INSERT just after you do,
and before you get a chance to SELECT LAST_INSERT_ID()
If there is any chance of it (anything except a single user can do
Message -
From: Morris Hirsch [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Wednesday, May 01, 2002 10:35 AM
Subject: Re: JSTL: sql
The problem is not about your own thread doing several related updates,
but some other thread doing an INSERT just after you do
Is this valid on Oracle as well, or just mysql? If not, is there any
universal way to do it?
Thanks,
Elizabeth Baron
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 01, 2002 1:47 PM
To: Tag Libraries Users List
Subject: Re: JSTL: sql
As long
Henri Yandell wrote:
Very very unlikely. I don't think any drivers provide this yet. The JDBC
3.0 spec does have such a thing, but it's new and not really common.
Two Options:
1) Find some SQL that is mysql specific to find it out. I know there is
something, I'm just not sure what. I'll
At 13:59 -0400 5/1/02, Baron, Elizabeth wrote:
Is this valid on Oracle as well, or just mysql? If not, is there any
universal way to do it?
Thanks,
Elizabeth Baron
LAST_INSERT_ID() is MySQL-specific, just like AUTO_INCREMENT columns.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For
On Wed, 1 May 2002, Hans Bergsten wrote:
Another alternative is to develop your own class for generating unique
IDs:
public class IDGenerator {
public long getNextId() {
// Some algorithm, possibly based on a timestamp and a sequence
// number, to generate the next
From: Morris Hirsch [EMAIL PROTECTED]
Reply-To: Tag Libraries Users List [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Subject: Re: JSTL: sql
Date: Wed, 1 May 2002 13:35:21 -0400 (EDT)
The problem is not about your own thread doing several related updates,
but some other
Sorry I should have read this message first.
From: Paul DuBois [EMAIL PROTECTED]
The problem is not about your own thread doing several related updates,
but some other thread doing an INSERT just after you do,
and before you get a chance to SELECT LAST_INSERT_ID()
If there is any chance of it
On Thu, 2 May 2002, Soefara Redzuan wrote:
But why is it even necessary to use sql:transaction ? Is it enough
that the JSP uses the same database connection for all sql: tags on
the page ? I think so.
sql:query and sql:update don't accept individual Connections; they
operate on
401 - 500 of 561 matches
Mail list logo
