Re: Freeing resources in closing tags
Interesting -- we got it working (must be magic!)... ;-) (Nevermind) -- Oliver Hans Bergsten wrote: > > Oliver Suciu wrote: > > > In JSP 1.1, you simply cook your own try-catch-finally stuff, > > preferrably in a generic base tag, which all your concrete > > tags extend. > > Unfortunately that's not possible in JSP 1.1. If there's an > exception while the custom action's body is processed, the > page processing is aborted and the doEndTag() method is never > called, just like Andrew said. Again, TryCatchFinally in JSP 1.2 > was added specifically to address this problem. > > Hans > > > Hans Bergsten wrote: > > > >>Andrew Cooke wrote: > >> > >> > >>>Hi, > >>> > >>>I would like to use a Custom Tag to open resources in the start tag and free > >>>them in the closing tag. But if there is an exception in the enclosed body, > >>>it seems that I will leak the resource (as the closing tag will not be > >>>called). > >>> > >>>For example, if I open a database connection in doStartTag and fail to close > >>>it in doEndTag (because an exception was thrown) then I will have an open DB > >>>connection that is not returned to the pool. > >>> > >>>What is the best way to avoid this problem? > >>> > >>This is exactly what the TryCatchFinally interface is for, added > >>in JSP 1.2. For a JSP 1.1 container, I'm afraid there is no solution. > >> > >>Hans > >>-- > >>Hans Bergsten [EMAIL PROTECTED] > >>Gefion Software http://www.gefionsoftware.com > >>JavaServer Pageshttp://TheJSPBook.com > >> > >>=== > >>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > >>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". > >>Some relevant FAQs on JSP/Servlets can be found at: > >> > >> http://archives.java.sun.com/jsp-interest.html > >> http://java.sun.com/products/jsp/faq.html > >> http://www.esperanto.org.nz/jsp/jspfaq.jsp > >> http://www.jguru.com/faq/index.jsp > >> http://www.jspinsider.com > >> > > > > === > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". > > Some relevant FAQs on JSP/Servlets can be found at: > > > > http://archives.java.sun.com/jsp-interest.html > > http://java.sun.com/products/jsp/faq.html > > http://www.esperanto.org.nz/jsp/jspfaq.jsp > > http://www.jguru.com/faq/index.jsp > > http://www.jspinsider.com > > > > > > -- > Hans Bergsten [EMAIL PROTECTED] > Gefion Software http://www.gefionsoftware.com > JavaServer Pageshttp://TheJSPBook.com > > === > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://archives.java.sun.com/jsp-interest.html > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.jsp > http://www.jguru.com/faq/index.jsp > http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Freeing resources in closing tags
In JSP 1.1, you simply cook your own try-catch-finally stuff, preferrably in a generic base tag, which all your concrete tags extend. -- Oliver Hans Bergsten wrote: > > Andrew Cooke wrote: > > > Hi, > > > > I would like to use a Custom Tag to open resources in the start tag and free > > them in the closing tag. But if there is an exception in the enclosed body, > > it seems that I will leak the resource (as the closing tag will not be > > called). > > > > For example, if I open a database connection in doStartTag and fail to close > > it in doEndTag (because an exception was thrown) then I will have an open DB > > connection that is not returned to the pool. > > > > What is the best way to avoid this problem? > > This is exactly what the TryCatchFinally interface is for, added > in JSP 1.2. For a JSP 1.1 container, I'm afraid there is no solution. > > Hans > -- > Hans Bergsten [EMAIL PROTECTED] > Gefion Software http://www.gefionsoftware.com > JavaServer Pageshttp://TheJSPBook.com > > === > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://archives.java.sun.com/jsp-interest.html > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.jsp > http://www.jguru.com/faq/index.jsp > http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Custom tags: overloaded setters
Actually, it seems to work with exactly those three setters
mentioned in the example -- I can pass a List in one instance,
and a String in another.
So now I'm wondering whether it's by design or just by accident?...
-- Oliver
Hans Bergsten wrote:
>
> Oliver Suciu wrote:
>
> > OK -- so it's underspecified. That means that the JRun implementation
> > is just as correct or incorrect as Tomcat's...
>
> No. Tomcat is the Reference Implementation, so when in doubt,
> trust Tomcat (yeah, yeah. I know there may be bugs in Tomcat
> as well ;-)
>
> Anyway, this was discussed at length in the spec group. What I
> tell you is the conclusion of how it should work. There may even
> be a blurb about this in the JSP 1.2 spec somewhere. Sorry, but
> I don't have the time to look for it right now.
>
> You believe what you want, of course. I can only tell you that
> if you develop tag handlers with multiple setters, they will
> not work in most containers. I'm just trying to help, not pick
> a fight ;-)
>
> > BTW, there seems to be a simple (JSP- and Tomcat-compliant) way to
> > make use of overloaded setters -- use request-time expressions:
> >
> > modify:
> > to:
> >
> > This bypasses any conversion and correctly invokes the string setter
> > 'public void setData(String dataStr)'.
>
> This only works if the type of the attribute is Object (again,
> just one setter method). In JSP 1.1, yes this is what you have to
> do if you want to assign a String value to the attribute. But it's
> not very "page author friendly", so in JSP 1.2 you can use a literal
> string instead, as in your first example.
>
> Note that Tomcat 4.0 (the RI for JSP 1.2) is buggy in this area.
> It's been fixed in the source, so it should work in the latest
> nightly build.
>
> Hans
>
> > Hans Bergsten wrote:
> >
> >>Oliver Suciu wrote:
> >>
> >>
> >>>You're saying that the spec doesn't say anything about this;
> >>>how comes you then say that the behavior of Tomcat is the
> >>>correct one?...
> >>>
> >>I'm saying that the bean spec does not explicitly say that
> >>a property can not have multiple setter methods, nor that it
> >>can have it. When the spec text is vague, you must look at
> >>the API and the implementation of the bean classes to find
> >>out what to expect. Together they imply that a bean property
> >>can only be associated with one setter method. Look, for
> >>instance, at the java.beans.PropertyDescriptor class. The
> >>constructors allow you to set *one* setter method, and the
> >>getWriteMethod() returns *one* method.
> >>
> >>The bean spec group is aware of this and have indicated to me
> >>that the next rev of the spec will explicitly state this as
> >>well.
> >>
> >>Hans
> >>
> >>
> >>>Hans Bergsten wrote:
> >>>
> >>>
> >>>>Oliver Suciu wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>Can anybody help clarify how a JSP container should handle
> >>>>>overloaded setters in a custom tag:
> >>>>>
> >>>>> public void setData(List dataList) {
> >>>>> this.dataList = dataList;
> >>>>> }
> >>>>> public void setData(Object dataObj) {
> >>>>> this.dataObj = dataObj;
> >>>>> }
> >>>>> public void setData(String dataStr) {
> >>>>> this.dataStr = dataStr;
> >>>>> }
> >>>>>
> >>>>>We want to give the JSP author the convenience of passing data
> >>>>>to a tag using different types, whichever comes in more handy.
> >>>>>The data would be of the same "logical" kind, that's why, ideally,
> >>>>>the setters would bear the same name, just like overloaded methods
> >>>>>in Java.
> >>>>>
> >>>>>As an example, JRun 3.1 accepts the code above, whereas Tomcat
> >>>>>3.2.3 throws a CompileException ("Unable to convert a String
> >>>>>to java.util.List").
> >>>>>
> >>>>>What's the correct behavior?
> >>>>>
> >>>>>
> >>>>Tomcat's behavior is correct. When it comes to attribute setter
> >>>>methods, a tag handler class is a &
Re: Custom tags: overloaded setters
OK -- so it's underspecified. That means that the JRun implementation
is just as correct or incorrect as Tomcat's...
BTW, there seems to be a simple (JSP- and Tomcat-compliant) way to
make use of overloaded setters -- use request-time expressions:
modify:
to:
This bypasses any conversion and correctly invokes the string setter
'public void setData(String dataStr)'.
-- Oliver
Hans Bergsten wrote:
>
> Oliver Suciu wrote:
>
> > You're saying that the spec doesn't say anything about this;
> > how comes you then say that the behavior of Tomcat is the
> > correct one?...
>
> I'm saying that the bean spec does not explicitly say that
> a property can not have multiple setter methods, nor that it
> can have it. When the spec text is vague, you must look at
> the API and the implementation of the bean classes to find
> out what to expect. Together they imply that a bean property
> can only be associated with one setter method. Look, for
> instance, at the java.beans.PropertyDescriptor class. The
> constructors allow you to set *one* setter method, and the
> getWriteMethod() returns *one* method.
>
> The bean spec group is aware of this and have indicated to me
> that the next rev of the spec will explicitly state this as
> well.
>
> Hans
>
> > Hans Bergsten wrote:
> >
> >>Oliver Suciu wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>Can anybody help clarify how a JSP container should handle
> >>>overloaded setters in a custom tag:
> >>>
> >>> public void setData(List dataList) {
> >>>this.dataList = dataList;
> >>> }
> >>> public void setData(Object dataObj) {
> >>>this.dataObj = dataObj;
> >>> }
> >>> public void setData(String dataStr) {
> >>>this.dataStr = dataStr;
> >>> }
> >>>
> >>>We want to give the JSP author the convenience of passing data
> >>>to a tag using different types, whichever comes in more handy.
> >>>The data would be of the same "logical" kind, that's why, ideally,
> >>>the setters would bear the same name, just like overloaded methods
> >>>in Java.
> >>>
> >>>As an example, JRun 3.1 accepts the code above, whereas Tomcat
> >>>3.2.3 throws a CompileException ("Unable to convert a String
> >>>to java.util.List").
> >>>
> >>>What's the correct behavior?
> >>>
> >>Tomcat's behavior is correct. When it comes to attribute setter
> >>methods, a tag handler class is a "bean", so you must go to the
> >>bean spec to see how it deals with property setter methods.
> >>The spec text itself doesn't say anything about multiple setter
> >>methods, but the implementation of the methods that deal with
> >>setter methods only allow one setter method per property. Hence,
> >>multiple setter methods for a tag handler attribute is not
> >>allowed.
> >>
> >>In JSP 1.2 you can get around this by making the type of the
> >>attribute Object, and the figure out which specific type you
> >>got. The reason this only works well with JSP 1.2 is that
> >>JSP 1.1 doesn't accept a string literal as the attribute
> >>value for an attribute of type Object; JSP 1.2 does.
> >>
> >> public void setData(Object data) {
> >> this.data = data;
> >> }
> >>
> >> public int doStartTag() {
> >> if (data instanceof List) {
> >>// Work with it as a List
> >> }
> >> else (data.getClass().isArray()) {
> >>// Work with it as an array
> >> }
> >> else (data instanceof String) {
> >>// Work with as a String
> >> }
> >> else ...
> >> }
> >>
> >>I describe this in more detail in an article that will soon
> >>be published at the O'Reilly site. I'll post the URL here
> >>when it's available.
> >>
> >>Hans
> >>--
> >>Hans Bergsten [EMAIL PROTECTED]
> >>Gefion Software http://www.gefionsoftware.com
> >>Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
> >>
> >>===
> >>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> >>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTERE
Re: Custom tags: overloaded setters
You're saying that the spec doesn't say anything about this;
how comes you then say that the behavior of Tomcat is the
correct one?...
Thx,
-- Oliver
Hans Bergsten wrote:
>
> Oliver Suciu wrote:
>
> > Hi,
> >
> > Can anybody help clarify how a JSP container should handle
> > overloaded setters in a custom tag:
> >
> > public void setData(List dataList) {
> > this.dataList = dataList;
> > }
> > public void setData(Object dataObj) {
> > this.dataObj = dataObj;
> > }
> > public void setData(String dataStr) {
> > this.dataStr = dataStr;
> > }
> >
> > We want to give the JSP author the convenience of passing data
> > to a tag using different types, whichever comes in more handy.
> > The data would be of the same "logical" kind, that's why, ideally,
> > the setters would bear the same name, just like overloaded methods
> > in Java.
> >
> > As an example, JRun 3.1 accepts the code above, whereas Tomcat
> > 3.2.3 throws a CompileException ("Unable to convert a String
> > to java.util.List").
> >
> > What's the correct behavior?
>
> Tomcat's behavior is correct. When it comes to attribute setter
> methods, a tag handler class is a "bean", so you must go to the
> bean spec to see how it deals with property setter methods.
> The spec text itself doesn't say anything about multiple setter
> methods, but the implementation of the methods that deal with
> setter methods only allow one setter method per property. Hence,
> multiple setter methods for a tag handler attribute is not
> allowed.
>
> In JSP 1.2 you can get around this by making the type of the
> attribute Object, and the figure out which specific type you
> got. The reason this only works well with JSP 1.2 is that
> JSP 1.1 doesn't accept a string literal as the attribute
> value for an attribute of type Object; JSP 1.2 does.
>
>public void setData(Object data) {
> this.data = data;
>}
>
>public int doStartTag() {
> if (data instanceof List) {
> // Work with it as a List
> }
> else (data.getClass().isArray()) {
> // Work with it as an array
> }
> else (data instanceof String) {
> // Work with as a String
> }
> else ...
>}
>
> I describe this in more detail in an article that will soon
> be published at the O'Reilly site. I'll post the URL here
> when it's available.
>
> Hans
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software http://www.gefionsoftware.com
> Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
>
> ===
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Custom tags: overloaded setters
Hi,
Can anybody help clarify how a JSP container should handle
overloaded setters in a custom tag:
public void setData(List dataList) {
this.dataList = dataList;
}
public void setData(Object dataObj) {
this.dataObj = dataObj;
}
public void setData(String dataStr) {
this.dataStr = dataStr;
}
We want to give the JSP author the convenience of passing data
to a tag using different types, whichever comes in more handy.
The data would be of the same "logical" kind, that's why, ideally,
the setters would bear the same name, just like overloaded methods
in Java.
As an example, JRun 3.1 accepts the code above, whereas Tomcat
3.2.3 throws a CompileException ("Unable to convert a String
to java.util.List").
What's the correct behavior?
Thanks,
-- Oliver
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: MessageDigest and the database
Make it a string: new String(byte[] buf) -- Oliver "Hernandez, Rey" wrote: > > Hi all, > > How are people using the MessageDigest object to encrypt values before > sending them to the database? > > Maybe I'm using it in the wrong way, but I am trying to do something > like this: > > Get a value from the user, across SSL, like a password. > Encrypt that password with MessageDigest(using MD5). > Put the resulting byte array into the database. > > I can't seem to find a way to get a byte array into the database, Oracle > in this case. I figured I could use a NUMBER datatype, but then how do you > convert a byte array to a java datatype that you can use with one of the > setXXX functions provided with PreparedStatement that will go into a NUMBER? > > Hope I didn't confuse everyone with this question, I'd be happy to clarify. > > Thanks in advance, > Rey > > === > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets -- Oliver Suciu [EMAIL PROTECTED] http://www.tibcofinance.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Packaging Precompiled JSP?
Hi,
JSP 1.1 (and 1.2) specify a way to precompile your pages
and package them as a bunch of Java .class files (eg, in
a WAR file).
However, the spec allows for "implementation dependent"
names in the compiled code -- so the question is, what
else do you need to package in order for your compiled
pages to work?
Eg, JRun 3.0 creates something like this:
> import javax.servlet.*;
> import javax.servlet.http.*;
> import javax.servlet.jsp.*;
> import javax.servlet.jsp.tagext.*;
> import allaire.jrun.jsp.JRunJSPStaticHelpers;
>
> public class jrun__html__MainPage2ejsp12
>extends allaire.jrun.jsp.HttpJSPServlet
>implements allaire.jrun.jsp.JRunJspPage {
> ...
> }
...so there is dependency on classes provided by Allaire,
which I would have to include in the WAR file (if I wanted
to make sure that they work not only with JRun)...
Does anybody have any experience with this?
Is there maybe a JSP compiler that creates independent
code, or that allows you to include its support classes
in your package? (Maybe Tomcat?)
Any hint is much appreciated.
Thanks a lot,
-- Oliver
--
Oliver Suciu
[EMAIL PROTECTED]
http://www.tibcofinance.com
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: Object attributes for custom tags
Yes -- if you fix it to <%=v%>... ;-)
-- Oliver
Dan Cancro wrote:
>
> Can you pass objects other than strings as attributes to a custom tag? I'm
> thinking of something that would look something like this:
>
> <%
> Vector v = new Vector();
> v.addElement("asdfasdf");
> %>
> />
>
> ===
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
--
Oliver Suciu
[EMAIL PROTECTED]
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
