You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by James Turner <tu...@blackbear.com> on 2003/01/04 19:26:34 UTC
Another bright idea, make "indexed" work with JSTL forEach and friends
As has been pointed out, about the only remaining reason to use
logic:iterate over c:forEach is that you can't use an html:text tag (or
friends) with an "indexed" property set, because it only looks for
logic:iterate on the page stack.
Now, it would be very simple (having peered at the source) to have the
html tags also look for JSTL iterators. However, to make this work,
we'd need to add a dependency on jakarta-taglibs so that the class would
be available.
I don't think that this would break anything in terms of JSP version
support, since it wouldn't require evaluation of ELs, just looking up
the stack to see if we find a JSTL interator hanging around.
Opinions?
_________________________________________
James
ICQ#: 8239923
More ways to contact me: http://wwp.icq.com/8239923
See more about me: http://web.icq.com/whitepages/about_me?Uin=8239923
_________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by "V. Cekvenich" <vc...@basebeans.com>.
Oh. Yeah, tiles XML is "OO".
Thanks for the correction!
.V
Martin Cooper wrote:
>
> On Sun, 5 Jan 2003, V. Cekvenich wrote:
>
>
>>Craig wrote :
>>"I'm playing with more interesting
>> ideas like using Jelly scripts (or JSP pages) as Actions so you don't
>>have to write them in Java. "
>>
>>
>>If Actions, or anything goes XML (Jelly), or JSP, EL or generator (or
>>sometimes design patterns) we lose OO.
>
>
> Not necessarily. XML is more a syntax than a language - it's what you do
> with it that supplies the semantics. (This is part of its heritage - SGML
> was designed specifically to avoid embedding of semantics in the original
> document, which is why DSSSL was designed to provide those semantics.)
>
> For example, look at Tiles. I can create a definition in XML, and then I
> can create further definitions that 'extend' the first one.
>
> Just as other languages such as Java and C++ can be used for object
> oriented programming, XML can too. It just depends on how you use it.
>
> --
> Martin Cooper
>
>
>
>>OO gives us productivity as Java is OO capable, and some people use it
>>in OO way. (Similar issue in C++, some people use C++ in C mode, or what
>>I call object disoriented mode).
>>
>>Unless there is a way I do not know of to make above (XML, el,
>>generators) be able to do:
>>- "is a / has a" (extends a base class, or has an extended helper object)
>>- inheritance and delegation (same as above) allows for after the fact
>>programing. After a developer thinks they are done with the scope,
>>*clients like to change the scope*, so when one has a baseAction or a
>>baseActionHelper, one can go to the base class and quickly maintain the
>>code, and not have to go to every place.
>>
>>Java is OO capable, whereas above listed things AFAIK do not have that
>>productivity in maintenance mode.
>>
>>Please take OO in consideration, it is a 10 fold advantage for the OO
>>Java practitioners. (It is not just overriding and polymorphisam. I
>>could give more real life examples. Like one base action that need to
>>act this way or another depedning on the situation.)
>>
>>Same issue is for non Action cases. XML, or JSP, EL, generator, or
>>scripts (or sometimes design patterns) we could lose OO and flexibility.
>>
>>(I can say in EL when you use this expresion here do it this way, BUT
>>over here, use the same expresion in another way)
>>
>>(OT: I was told that Flash (when one does data entery screens in a Flash
>>plug in) can do limited OO)
>>
>>.V
>>
>>
>>
>>Craig R. McClanahan wrote:
>>
>>>On 4 Jan 2003, David M. Karr wrote:
>>>
>>>
>>>
>>>>Date: 04 Jan 2003 17:28:58 -0800
>>>>From: David M. Karr <dm...@earthlink.net>
>>>>Reply-To: Struts Developers List <st...@jakarta.apache.org>
>>>>To: struts-dev@jakarta.apache.org
>>>>Subject: Re: Another bright idea,
>>>> make "indexed" work with JSTL forEach and friends
>>>>
>>>>
>>>>
>>>>>>>>>"Craig" == Craig R McClanahan <cr...@apache.org> writes:
>>>>>>>>
>>>> Craig> On 4 Jan 2003, David M. Karr wrote:
>>>>
>>>> >> Can anyone envision any other situations in the Struts code where indirect
>>>> >> references to the JSTL would be convenient? That, at least, could give us some
>>>> >> additional perspective on this.
>>>>
>>>> Craig> General purpose access to the EL evaluator (which David used in
>>>> Craig> implementing the EL-ized versions of the Struts tag libraries) would
>>>> Craig> definitely be useful in general purpose computing environments. The Jelly
>>>> Craig> project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing
>>>> Craig> the scripting environment that Jelly supports, for example.
>>>>
>>>> Craig> It would be interesting to contemplate where you might usefully leverage
>>>> Craig> EL expressions ... say, in struts-config.xml constructs ...
>>>>
>>>>Could we do this in DynaBean property value initializations?
>>>
>>>
>>>That would certainly make sense, as long as we could identify the
>>>"variable context" (in EL implementation terms) with which variable
>>>references should be resolved.
>>>
>>>
>>>
>>>>I can't think of
>>>>any other places in the config file where this would be useful (yet).
>>>
>>>
>>>
>>>At least one other place would be things like the pattern matching rules
>>>in the <controller> element for calculating URLs.
>>>
>>>Longer term (2.0 time frame probably), I'm playing with more interesting
>>>ideas like using Jelly scripts (or JSP pages) as Actions so you don't have
>>>to write them in Java. We also need a good high level multi-request
>>>framework, and it might be useful there in automating some of the forward
>>>and backward link references.
>>>
>>>Craig
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by Martin Cooper <ma...@apache.org>.
On Sun, 5 Jan 2003, V. Cekvenich wrote:
> Craig wrote :
> "I'm playing with more interesting
> ideas like using Jelly scripts (or JSP pages) as Actions so you don't
> have to write them in Java. "
>
>
> If Actions, or anything goes XML (Jelly), or JSP, EL or generator (or
> sometimes design patterns) we lose OO.
Not necessarily. XML is more a syntax than a language - it's what you do
with it that supplies the semantics. (This is part of its heritage - SGML
was designed specifically to avoid embedding of semantics in the original
document, which is why DSSSL was designed to provide those semantics.)
For example, look at Tiles. I can create a definition in XML, and then I
can create further definitions that 'extend' the first one.
Just as other languages such as Java and C++ can be used for object
oriented programming, XML can too. It just depends on how you use it.
--
Martin Cooper
>
> OO gives us productivity as Java is OO capable, and some people use it
> in OO way. (Similar issue in C++, some people use C++ in C mode, or what
> I call object disoriented mode).
>
> Unless there is a way I do not know of to make above (XML, el,
> generators) be able to do:
> - "is a / has a" (extends a base class, or has an extended helper object)
> - inheritance and delegation (same as above) allows for after the fact
> programing. After a developer thinks they are done with the scope,
> *clients like to change the scope*, so when one has a baseAction or a
> baseActionHelper, one can go to the base class and quickly maintain the
> code, and not have to go to every place.
>
> Java is OO capable, whereas above listed things AFAIK do not have that
> productivity in maintenance mode.
>
> Please take OO in consideration, it is a 10 fold advantage for the OO
> Java practitioners. (It is not just overriding and polymorphisam. I
> could give more real life examples. Like one base action that need to
> act this way or another depedning on the situation.)
>
> Same issue is for non Action cases. XML, or JSP, EL, generator, or
> scripts (or sometimes design patterns) we could lose OO and flexibility.
>
> (I can say in EL when you use this expresion here do it this way, BUT
> over here, use the same expresion in another way)
>
> (OT: I was told that Flash (when one does data entery screens in a Flash
> plug in) can do limited OO)
>
> .V
>
>
>
> Craig R. McClanahan wrote:
> >
> > On 4 Jan 2003, David M. Karr wrote:
> >
> >
> >>Date: 04 Jan 2003 17:28:58 -0800
> >>From: David M. Karr <dm...@earthlink.net>
> >>Reply-To: Struts Developers List <st...@jakarta.apache.org>
> >>To: struts-dev@jakarta.apache.org
> >>Subject: Re: Another bright idea,
> >> make "indexed" work with JSTL forEach and friends
> >>
> >>
> >>>>>>>"Craig" == Craig R McClanahan <cr...@apache.org> writes:
> >>>>>>
> >> Craig> On 4 Jan 2003, David M. Karr wrote:
> >>
> >> >> Can anyone envision any other situations in the Struts code where indirect
> >> >> references to the JSTL would be convenient? That, at least, could give us some
> >> >> additional perspective on this.
> >>
> >> Craig> General purpose access to the EL evaluator (which David used in
> >> Craig> implementing the EL-ized versions of the Struts tag libraries) would
> >> Craig> definitely be useful in general purpose computing environments. The Jelly
> >> Craig> project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing
> >> Craig> the scripting environment that Jelly supports, for example.
> >>
> >> Craig> It would be interesting to contemplate where you might usefully leverage
> >> Craig> EL expressions ... say, in struts-config.xml constructs ...
> >>
> >>Could we do this in DynaBean property value initializations?
> >
> >
> > That would certainly make sense, as long as we could identify the
> > "variable context" (in EL implementation terms) with which variable
> > references should be resolved.
> >
> >
> >> I can't think of
> >>any other places in the config file where this would be useful (yet).
> >
> >
> >
> > At least one other place would be things like the pattern matching rules
> > in the <controller> element for calculating URLs.
> >
> > Longer term (2.0 time frame probably), I'm playing with more interesting
> > ideas like using Jelly scripts (or JSP pages) as Actions so you don't have
> > to write them in Java. We also need a good high level multi-request
> > framework, and it might be useful there in automating some of the forward
> > and backward link references.
> >
> > Craig
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by "V. Cekvenich" <vc...@basebeans.com>.
Craig wrote :
"I'm playing with more interesting
ideas like using Jelly scripts (or JSP pages) as Actions so you don't
have to write them in Java. "
If Actions, or anything goes XML (Jelly), or JSP, EL or generator (or
sometimes design patterns) we lose OO.
OO gives us productivity as Java is OO capable, and some people use it
in OO way. (Similar issue in C++, some people use C++ in C mode, or what
I call object disoriented mode).
Unless there is a way I do not know of to make above (XML, el,
generators) be able to do:
- "is a / has a" (extends a base class, or has an extended helper object)
- inheritance and delegation (same as above) allows for after the fact
programing. After a developer thinks they are done with the scope,
*clients like to change the scope*, so when one has a baseAction or a
baseActionHelper, one can go to the base class and quickly maintain the
code, and not have to go to every place.
Java is OO capable, whereas above listed things AFAIK do not have that
productivity in maintenance mode.
Please take OO in consideration, it is a 10 fold advantage for the OO
Java practitioners. (It is not just overriding and polymorphisam. I
could give more real life examples. Like one base action that need to
act this way or another depedning on the situation.)
Same issue is for non Action cases. XML, or JSP, EL, generator, or
scripts (or sometimes design patterns) we could lose OO and flexibility.
(I can say in EL when you use this expresion here do it this way, BUT
over here, use the same expresion in another way)
(OT: I was told that Flash (when one does data entery screens in a Flash
plug in) can do limited OO)
.V
Craig R. McClanahan wrote:
>
> On 4 Jan 2003, David M. Karr wrote:
>
>
>>Date: 04 Jan 2003 17:28:58 -0800
>>From: David M. Karr <dm...@earthlink.net>
>>Reply-To: Struts Developers List <st...@jakarta.apache.org>
>>To: struts-dev@jakarta.apache.org
>>Subject: Re: Another bright idea,
>> make "indexed" work with JSTL forEach and friends
>>
>>
>>>>>>>"Craig" == Craig R McClanahan <cr...@apache.org> writes:
>>>>>>
>> Craig> On 4 Jan 2003, David M. Karr wrote:
>>
>> >> Can anyone envision any other situations in the Struts code where indirect
>> >> references to the JSTL would be convenient? That, at least, could give us some
>> >> additional perspective on this.
>>
>> Craig> General purpose access to the EL evaluator (which David used in
>> Craig> implementing the EL-ized versions of the Struts tag libraries) would
>> Craig> definitely be useful in general purpose computing environments. The Jelly
>> Craig> project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing
>> Craig> the scripting environment that Jelly supports, for example.
>>
>> Craig> It would be interesting to contemplate where you might usefully leverage
>> Craig> EL expressions ... say, in struts-config.xml constructs ...
>>
>>Could we do this in DynaBean property value initializations?
>
>
> That would certainly make sense, as long as we could identify the
> "variable context" (in EL implementation terms) with which variable
> references should be resolved.
>
>
>> I can't think of
>>any other places in the config file where this would be useful (yet).
>
>
>
> At least one other place would be things like the pattern matching rules
> in the <controller> element for calculating URLs.
>
> Longer term (2.0 time frame probably), I'm playing with more interesting
> ideas like using Jelly scripts (or JSP pages) as Actions so you don't have
> to write them in Java. We also need a good high level multi-request
> framework, and it might be useful there in automating some of the forward
> and backward link references.
>
> Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jelly actions (was Re: Another bright idea, make "indexed" work
with JSTL forEach and friends)
Posted by Ted Husted <hu...@apache.org>.
Sounds like we're all on the same page here. =:0)
I'm also looking at using the Jelly XLST for views as well (a la the
Velocity View Tools).
Martin Cooper wrote:
>
> On Sat, 4 Jan 2003, Craig R. McClanahan wrote:
>
>
>>Longer term (2.0 time frame probably), I'm playing with more interesting
>>ideas like using Jelly scripts (or JSP pages) as Actions so you don't have
>>to write them in Java. We also need a good high level multi-request
>>framework, and it might be useful there in automating some of the forward
>>and backward link references.
>
>
> I've spent some time playing with writing actions in Jelly, and I think
> this has a *lot* of potential. The main issue at the moment has to do with
> the lack of pluggable scopes in Jelly. I actually started to work on this
> a while ago, but got derailed and never got back to it. I hope to find
> some time to finish what I started after Struts 1.1 Final.
>
> --
> Martin Cooper
>
>
>
>>Craig
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jelly actions (was Re: Another bright idea, make "indexed" work
with JSTL forEach and friends)
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 4 Jan 2003, Craig R. McClanahan wrote:
> Longer term (2.0 time frame probably), I'm playing with more interesting
> ideas like using Jelly scripts (or JSP pages) as Actions so you don't have
> to write them in Java. We also need a good high level multi-request
> framework, and it might be useful there in automating some of the forward
> and backward link references.
I've spent some time playing with writing actions in Jelly, and I think
this has a *lot* of potential. The main issue at the moment has to do with
the lack of pluggable scopes in Jelly. I actually started to work on this
a while ago, but got derailed and never got back to it. I hope to find
some time to finish what I started after Struts 1.1 Final.
--
Martin Cooper
>
> Craig
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 4 Jan 2003, David M. Karr wrote:
> Date: 04 Jan 2003 17:28:58 -0800
> From: David M. Karr <dm...@earthlink.net>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Re: Another bright idea,
> make "indexed" work with JSTL forEach and friends
>
> >>>>> "Craig" == Craig R McClanahan <cr...@apache.org> writes:
>
> Craig> On 4 Jan 2003, David M. Karr wrote:
>
> >> Can anyone envision any other situations in the Struts code where indirect
> >> references to the JSTL would be convenient? That, at least, could give us some
> >> additional perspective on this.
>
> Craig> General purpose access to the EL evaluator (which David used in
> Craig> implementing the EL-ized versions of the Struts tag libraries) would
> Craig> definitely be useful in general purpose computing environments. The Jelly
> Craig> project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing
> Craig> the scripting environment that Jelly supports, for example.
>
> Craig> It would be interesting to contemplate where you might usefully leverage
> Craig> EL expressions ... say, in struts-config.xml constructs ...
>
> Could we do this in DynaBean property value initializations?
That would certainly make sense, as long as we could identify the
"variable context" (in EL implementation terms) with which variable
references should be resolved.
> I can't think of
> any other places in the config file where this would be useful (yet).
At least one other place would be things like the pattern matching rules
in the <controller> element for calculating URLs.
Longer term (2.0 time frame probably), I'm playing with more interesting
ideas like using Jelly scripts (or JSP pages) as Actions so you don't have
to write them in Java. We also need a good high level multi-request
framework, and it might be useful there in automating some of the forward
and backward link references.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and friends
Posted by "David M. Karr" <dm...@earthlink.net>.
>>>>> "Craig" == Craig R McClanahan <cr...@apache.org> writes:
Craig> On 4 Jan 2003, David M. Karr wrote:
>> Can anyone envision any other situations in the Struts code where indirect
>> references to the JSTL would be convenient? That, at least, could give us some
>> additional perspective on this.
Craig> General purpose access to the EL evaluator (which David used in
Craig> implementing the EL-ized versions of the Struts tag libraries) would
Craig> definitely be useful in general purpose computing environments. The Jelly
Craig> project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing
Craig> the scripting environment that Jelly supports, for example.
Craig> It would be interesting to contemplate where you might usefully leverage
Craig> EL expressions ... say, in struts-config.xml constructs ...
Could we do this in DynaBean property value initializations? I can't think of
any other places in the config file where this would be useful (yet).
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr@earthlink.net ; SCJP; SCWCD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 4 Jan 2003, David M. Karr wrote:
>
> Can anyone envision any other situations in the Struts code where indirect
> references to the JSTL would be convenient? That, at least, could give us some
> additional perspective on this.
>
General purpose access to the EL evaluator (which David used in
implementing the EL-ized versions of the Struts tag libraries) would
definitely be useful in general purpose computing environments. The Jelly
project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing
the scripting environment that Jelly supports, for example.
It would be interesting to contemplate where you might usefully leverage
EL expressions ... say, in struts-config.xml constructs ...
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and friends
Posted by "David M. Karr" <dm...@earthlink.net>.
>>>>> "James" == James Turner <tu...@blackbear.com> writes:
James> On Sat, 4 Jan 2003, Martin Cooper wrote:
>> If you want to do this, I'd rather see it happen in the html-el taglib
>> than the regular html taglib. Struts-EL already depends on
>> JSTL, and is
>> designed to work in cooperation with it, so it's a much more
>> natural fit
>> than trying to sneak JSTL functionality into the regular tags.
James> I mildly disagree. EL is to allow struts HTML tags to use EL syntax.
James> This deals with letting the standard tags find JSTL looping constructs.
James> As is, you can "*almost* entirely eliminate all the Struts tags except
James> for the HTML tags in favor of JSTL substitutes, since only the HTML tags
James> deal with things like actions. By implementing this, we can eliminate
James> having to use the logic taglibs at all. And the change is pretty darn
James> innocuous, here's the revisted code from BaseHandlerTag, which works
James> very nicely. Note that I'm not even referencing org.apache stuff. And
James> the JSTL stuff is only ever invoked if it fails to find the Iterate tag.
James> One thing I'm considering is caching the classes and methods so that the
James> reflection doesn't need to happen on every invokation.
Sigh. The balance of architectural purity with convenience. It looks like
what you've implemented is about the best you can do (you should implement
reflection object caching, as you mention). It directly pollutes the Struts
code with references to the JSTL, albeit not at compile time. Is that a
problem? Who knows?
Can anyone envision any other situations in the Struts code where indirect
references to the JSTL would be convenient? That, at least, could give us some
additional perspective on this.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr@earthlink.net ; SCJP; SCWCD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 4 Jan 2003, James Turner wrote:
> > From: Martin Cooper [mailto:martinc@apache.org]
> >
> > Sigh. OK, OK.
> >
> > But three changes I'd like to see in the code you posted earlier:
> >
> > 1) Instead of calling Class.forName(), you should use
> > RequestUtils.applicationClass(), to make sure the context
> > class loader is tried first.
>
> I'll do dat.
>
> >
> > 2) Empty catch clauses are evil. ;-) You should at least log a debug
> > message so that real problems can be debugged more easily.
>
> Well, two of them shouldn't log anything because they are simply there
> to catch the "you haven't got JSTL" case, I though about logging the
> other cases but "they should never happen" (famous last words #43456),
> since it would require there to be a loopTag that couldn't handle being
> sent the messages it defines in the Interface, but I guess I can throw
> in some logging If It Makes You Feel Good :-)
It would make me feel so good - thank you. ;-) One case I'm thinking about
here is when someone finds that it's not working for them, and they
*think* they have JSTL, but it's not being picked up for some reason. A
log message would tell them that Struts tried to do what they wanted, but
something went wrong, hopefully helping them determine that there might be
something wrong with their web app config.
--
Martin Cooper
>
> > 3) Always use braces with if clauses. I know the code has
> > plenty of cases
> > where that isn't done, but it's good practice to do that. I
> > seem to recall
> > Craig admitting that he should have done that in the original
> > code base.
>
> I usually do it to, except when my old c-habits sneak in.
>
> James
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Another bright idea, make "indexed" work with JSTL forEach and friends
Posted by James Turner <tu...@blackbear.com>.
> From: Martin Cooper [mailto:martinc@apache.org]
>
> Sigh. OK, OK.
>
> But three changes I'd like to see in the code you posted earlier:
>
> 1) Instead of calling Class.forName(), you should use
> RequestUtils.applicationClass(), to make sure the context
> class loader is tried first.
I'll do dat.
>
> 2) Empty catch clauses are evil. ;-) You should at least log a debug
> message so that real problems can be debugged more easily.
Well, two of them shouldn't log anything because they are simply there
to catch the "you haven't got JSTL" case, I though about logging the
other cases but "they should never happen" (famous last words #43456),
since it would require there to be a loopTag that couldn't handle being
sent the messages it defines in the Interface, but I guess I can throw
in some logging If It Makes You Feel Good :-)
> 3) Always use braces with if clauses. I know the code has
> plenty of cases
> where that isn't done, but it's good practice to do that. I
> seem to recall
> Craig admitting that he should have done that in the original
> code base.
I usually do it to, except when my old c-habits sneak in.
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 4 Jan 2003, James Turner wrote:
> Ok, here's a more practical reason to do it in the base release...
>
> The Struts-EL package doesn't handle the indexed tag at all, it relies
> on the fact that it extends the org.apache.struts.taglib.html versions
> of the tags which in turn eventually extend BaseHandlerTag. So, to
> implement it in Struts-EL, I'll have to more prepareIndex all the way up
> into the Struts-EL class (duplicated the code or wrapping it), and
> change all the Struts-EL classes to extend that class instead. This
> means implementing several dozen new classes in Struts-EL to avoid
> extending one method in the base Struts release.
Sigh. OK, OK.
But three changes I'd like to see in the code you posted earlier:
1) Instead of calling Class.forName(), you should use
RequestUtils.applicationClass(), to make sure the context class loader is
tried first.
2) Empty catch clauses are evil. ;-) You should at least log a debug
message so that real problems can be debugged more easily.
3) Always use braces with if clauses. I know the code has plenty of cases
where that isn't done, but it's good practice to do that. I seem to recall
Craig admitting that he should have done that in the original code base.
;-)
--
Martin Cooper
>
> James
>
> > -----Original Message-----
> > From: Martin Cooper [mailto:martinc@apache.org]
> > Sent: Saturday, January 04, 2003 4:37 PM
> > To: Struts Developers List
> > Subject: RE: Another bright idea, make "indexed" work with
> > JSTL forEach and friends
> >
> >
> >
> >
> > On Sat, 4 Jan 2003, James Turner wrote:
> >
> > > On Sat, 4 Jan 2003, Martin Cooper wrote:
> > >
> > > > If you want to do this, I'd rather see it happen in the
> > html-el taglib
> > > > than the regular html taglib. Struts-EL already depends on
> > > > JSTL, and is
> > > > designed to work in cooperation with it, so it's a much more
> > > > natural fit
> > > > than trying to sneak JSTL functionality into the regular tags.
> > >
> > > I mildly disagree. EL is to allow struts HTML tags to use
> > EL syntax.
> >
> > Yes. And why would you want to do that? Because you're
> > already using JSTL
> > tags in your pages, and you want the two to work together.
> >
> > > This deals with letting the standard tags find JSTL looping
> > constructs.
> >
> > Yes. And why would you want to do that? Because you're
> > already using JSTL
> > tags in your pages, and you want the two to work together.
> >
> > Notice the remarkable similarity in the two reasons for using
> > these pieces
> > of functionality? ;-)
> >
> > That's why I think your suggestion fits much better in
> > Struts-EL than in
> > the Struts core. Once we require Servlets 2.3 / JSP 1.2 for
> > Struts, then
> > I'm all for having this in the core, along with the rest of Struts-EL.
> > Prior to that, I just don't like the idea of muddying the
> > core html taglib
> > with references to JSTL, especially when you have to do it all through
> > reflection.
> >
> > --
> > Martin Cooper
> >
> >
> > > As is, you can "*almost* entirely eliminate all the Struts
> > tags except
> > > for the HTML tags in favor of JSTL substitutes, since only
> > the HTML tags
> > > deal with things like actions. By implementing this, we
> > can eliminate
> > > having to use the logic taglibs at all. And the change is
> > pretty darn
> > > innocuous, here's the revisted code from BaseHandlerTag, which works
> > > very nicely. Note that I'm not even referencing org.apache
> > stuff. And
> > > the JSTL stuff is only ever invoked if it fails to find the
> > Iterate tag.
> > >
> > > One thing I'm considering is caching the classes and
> > methods so that the
> > > reflection doesn't need to happen on every invokation.
> > >
> > > protected void prepareIndex(StringBuffer handlers, String name)
> > > throws JspException {
> > > int index = 0;
> > > boolean found = false;
> > >
> > > // look for outer iterate tag
> > > IterateTag iterateTag = (IterateTag)
> > findAncestorWithClass(this,
> > > IterateTag.class);
> > > // Look for JSTL loops
> > > if (iterateTag == null) {
> > > try {
> > > Class loopClass =
> > > Class.forName("javax.servlet.jsp.jstl.core.LoopTagSupport");
> > > Object loopTag = findAncestorWithClass(this, loopClass);
> > > if (loopTag != null) {
> > > Method getStatus =
> > > loopClass.getDeclaredMethod("getLoopStatus",
> > > null);
> > > Object status = getStatus.invoke(loopTag, null);
> > > Class statusClass =
> > >
> > > Class.forName("javax.servlet.jsp.jstl.core.LoopTagStatus");
> > > Method getIndex =
> > > statusClass.getDeclaredMethod("getIndex", null);
> > > Integer ind = (Integer) getIndex.invoke(status,
> > > null);
> > > index = ind.intValue();
> > > found = true;
> > > }
> > > }
> > > catch (ClassNotFoundException ex) {}
> > > catch (NoSuchMethodException ex) {}
> > > catch (IllegalAccessException ex) {}
> > > catch (IllegalArgumentException ex) {}
> > > catch (InvocationTargetException ex) {}
> > > catch (NullPointerException ex) {}
> > > catch (ExceptionInInitializerError ex) {}
> > > } else {
> > > index = iterateTag.getIndex();
> > > found = true;
> > > }
> > > if (!found) {
> > > // this tag should only be nested in iteratetag, if it's
> > > not, throw exception
> > > JspException e = new
> > > JspException(messages.getMessage("indexed.noEnclosingIterate"));
> > > RequestUtils.saveException(pageContext, e);
> > > throw e;
> > > }
> > > if (name != null)
> > > handlers.append(name);
> > > handlers.append("[");
> > > handlers.append(index);
> > > handlers.append("]");
> > > if (name != null)
> > > handlers.append(".");
> > > }
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:struts-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Another bright idea, make "indexed" work with JSTL forEach and friends
Posted by James Turner <tu...@blackbear.com>.
Ok, here's a more practical reason to do it in the base release...
The Struts-EL package doesn't handle the indexed tag at all, it relies
on the fact that it extends the org.apache.struts.taglib.html versions
of the tags which in turn eventually extend BaseHandlerTag. So, to
implement it in Struts-EL, I'll have to more prepareIndex all the way up
into the Struts-EL class (duplicated the code or wrapping it), and
change all the Struts-EL classes to extend that class instead. This
means implementing several dozen new classes in Struts-EL to avoid
extending one method in the base Struts release.
James
> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org]
> Sent: Saturday, January 04, 2003 4:37 PM
> To: Struts Developers List
> Subject: RE: Another bright idea, make "indexed" work with
> JSTL forEach and friends
>
>
>
>
> On Sat, 4 Jan 2003, James Turner wrote:
>
> > On Sat, 4 Jan 2003, Martin Cooper wrote:
> >
> > > If you want to do this, I'd rather see it happen in the
> html-el taglib
> > > than the regular html taglib. Struts-EL already depends on
> > > JSTL, and is
> > > designed to work in cooperation with it, so it's a much more
> > > natural fit
> > > than trying to sneak JSTL functionality into the regular tags.
> >
> > I mildly disagree. EL is to allow struts HTML tags to use
> EL syntax.
>
> Yes. And why would you want to do that? Because you're
> already using JSTL
> tags in your pages, and you want the two to work together.
>
> > This deals with letting the standard tags find JSTL looping
> constructs.
>
> Yes. And why would you want to do that? Because you're
> already using JSTL
> tags in your pages, and you want the two to work together.
>
> Notice the remarkable similarity in the two reasons for using
> these pieces
> of functionality? ;-)
>
> That's why I think your suggestion fits much better in
> Struts-EL than in
> the Struts core. Once we require Servlets 2.3 / JSP 1.2 for
> Struts, then
> I'm all for having this in the core, along with the rest of Struts-EL.
> Prior to that, I just don't like the idea of muddying the
> core html taglib
> with references to JSTL, especially when you have to do it all through
> reflection.
>
> --
> Martin Cooper
>
>
> > As is, you can "*almost* entirely eliminate all the Struts
> tags except
> > for the HTML tags in favor of JSTL substitutes, since only
> the HTML tags
> > deal with things like actions. By implementing this, we
> can eliminate
> > having to use the logic taglibs at all. And the change is
> pretty darn
> > innocuous, here's the revisted code from BaseHandlerTag, which works
> > very nicely. Note that I'm not even referencing org.apache
> stuff. And
> > the JSTL stuff is only ever invoked if it fails to find the
> Iterate tag.
> >
> > One thing I'm considering is caching the classes and
> methods so that the
> > reflection doesn't need to happen on every invokation.
> >
> > protected void prepareIndex(StringBuffer handlers, String name)
> > throws JspException {
> > int index = 0;
> > boolean found = false;
> >
> > // look for outer iterate tag
> > IterateTag iterateTag = (IterateTag)
> findAncestorWithClass(this,
> > IterateTag.class);
> > // Look for JSTL loops
> > if (iterateTag == null) {
> > try {
> > Class loopClass =
> > Class.forName("javax.servlet.jsp.jstl.core.LoopTagSupport");
> > Object loopTag = findAncestorWithClass(this, loopClass);
> > if (loopTag != null) {
> > Method getStatus =
> > loopClass.getDeclaredMethod("getLoopStatus",
> > null);
> > Object status = getStatus.invoke(loopTag, null);
> > Class statusClass =
> >
> > Class.forName("javax.servlet.jsp.jstl.core.LoopTagStatus");
> > Method getIndex =
> > statusClass.getDeclaredMethod("getIndex", null);
> > Integer ind = (Integer) getIndex.invoke(status,
> > null);
> > index = ind.intValue();
> > found = true;
> > }
> > }
> > catch (ClassNotFoundException ex) {}
> > catch (NoSuchMethodException ex) {}
> > catch (IllegalAccessException ex) {}
> > catch (IllegalArgumentException ex) {}
> > catch (InvocationTargetException ex) {}
> > catch (NullPointerException ex) {}
> > catch (ExceptionInInitializerError ex) {}
> > } else {
> > index = iterateTag.getIndex();
> > found = true;
> > }
> > if (!found) {
> > // this tag should only be nested in iteratetag, if it's
> > not, throw exception
> > JspException e = new
> > JspException(messages.getMessage("indexed.noEnclosingIterate"));
> > RequestUtils.saveException(pageContext, e);
> > throw e;
> > }
> > if (name != null)
> > handlers.append(name);
> > handlers.append("[");
> > handlers.append(index);
> > handlers.append("]");
> > if (name != null)
> > handlers.append(".");
> > }
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-dev-> unsubscribe@jakarta.apache.org>
> > For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 4 Jan 2003, James Turner wrote:
> On Sat, 4 Jan 2003, Martin Cooper wrote:
>
> > If you want to do this, I'd rather see it happen in the html-el taglib
> > than the regular html taglib. Struts-EL already depends on
> > JSTL, and is
> > designed to work in cooperation with it, so it's a much more
> > natural fit
> > than trying to sneak JSTL functionality into the regular tags.
>
> I mildly disagree. EL is to allow struts HTML tags to use EL syntax.
Yes. And why would you want to do that? Because you're already using JSTL
tags in your pages, and you want the two to work together.
> This deals with letting the standard tags find JSTL looping constructs.
Yes. And why would you want to do that? Because you're already using JSTL
tags in your pages, and you want the two to work together.
Notice the remarkable similarity in the two reasons for using these pieces
of functionality? ;-)
That's why I think your suggestion fits much better in Struts-EL than in
the Struts core. Once we require Servlets 2.3 / JSP 1.2 for Struts, then
I'm all for having this in the core, along with the rest of Struts-EL.
Prior to that, I just don't like the idea of muddying the core html taglib
with references to JSTL, especially when you have to do it all through
reflection.
--
Martin Cooper
> As is, you can "*almost* entirely eliminate all the Struts tags except
> for the HTML tags in favor of JSTL substitutes, since only the HTML tags
> deal with things like actions. By implementing this, we can eliminate
> having to use the logic taglibs at all. And the change is pretty darn
> innocuous, here's the revisted code from BaseHandlerTag, which works
> very nicely. Note that I'm not even referencing org.apache stuff. And
> the JSTL stuff is only ever invoked if it fails to find the Iterate tag.
>
> One thing I'm considering is caching the classes and methods so that the
> reflection doesn't need to happen on every invokation.
>
> protected void prepareIndex(StringBuffer handlers, String name)
> throws JspException {
> int index = 0;
> boolean found = false;
>
> // look for outer iterate tag
> IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
> IterateTag.class);
> // Look for JSTL loops
> if (iterateTag == null) {
> try {
> Class loopClass =
> Class.forName("javax.servlet.jsp.jstl.core.LoopTagSupport");
> Object loopTag = findAncestorWithClass(this, loopClass);
> if (loopTag != null) {
> Method getStatus =
> loopClass.getDeclaredMethod("getLoopStatus",
> null);
> Object status = getStatus.invoke(loopTag, null);
> Class statusClass =
>
> Class.forName("javax.servlet.jsp.jstl.core.LoopTagStatus");
> Method getIndex =
> statusClass.getDeclaredMethod("getIndex", null);
> Integer ind = (Integer) getIndex.invoke(status,
> null);
> index = ind.intValue();
> found = true;
> }
> }
> catch (ClassNotFoundException ex) {}
> catch (NoSuchMethodException ex) {}
> catch (IllegalAccessException ex) {}
> catch (IllegalArgumentException ex) {}
> catch (InvocationTargetException ex) {}
> catch (NullPointerException ex) {}
> catch (ExceptionInInitializerError ex) {}
> } else {
> index = iterateTag.getIndex();
> found = true;
> }
> if (!found) {
> // this tag should only be nested in iteratetag, if it's
> not, throw exception
> JspException e = new
> JspException(messages.getMessage("indexed.noEnclosingIterate"));
> RequestUtils.saveException(pageContext, e);
> throw e;
> }
> if (name != null)
> handlers.append(name);
> handlers.append("[");
> handlers.append(index);
> handlers.append("]");
> if (name != null)
> handlers.append(".");
> }
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Another bright idea, make "indexed" work with JSTL forEach and friends
Posted by James Turner <tu...@blackbear.com>.
On Sat, 4 Jan 2003, Martin Cooper wrote:
> If you want to do this, I'd rather see it happen in the html-el taglib
> than the regular html taglib. Struts-EL already depends on
> JSTL, and is
> designed to work in cooperation with it, so it's a much more
> natural fit
> than trying to sneak JSTL functionality into the regular tags.
I mildly disagree. EL is to allow struts HTML tags to use EL syntax.
This deals with letting the standard tags find JSTL looping constructs.
As is, you can "*almost* entirely eliminate all the Struts tags except
for the HTML tags in favor of JSTL substitutes, since only the HTML tags
deal with things like actions. By implementing this, we can eliminate
having to use the logic taglibs at all. And the change is pretty darn
innocuous, here's the revisted code from BaseHandlerTag, which works
very nicely. Note that I'm not even referencing org.apache stuff. And
the JSTL stuff is only ever invoked if it fails to find the Iterate tag.
One thing I'm considering is caching the classes and methods so that the
reflection doesn't need to happen on every invokation.
protected void prepareIndex(StringBuffer handlers, String name)
throws JspException {
int index = 0;
boolean found = false;
// look for outer iterate tag
IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
IterateTag.class);
// Look for JSTL loops
if (iterateTag == null) {
try {
Class loopClass =
Class.forName("javax.servlet.jsp.jstl.core.LoopTagSupport");
Object loopTag = findAncestorWithClass(this, loopClass);
if (loopTag != null) {
Method getStatus =
loopClass.getDeclaredMethod("getLoopStatus",
null);
Object status = getStatus.invoke(loopTag, null);
Class statusClass =
Class.forName("javax.servlet.jsp.jstl.core.LoopTagStatus");
Method getIndex =
statusClass.getDeclaredMethod("getIndex", null);
Integer ind = (Integer) getIndex.invoke(status,
null);
index = ind.intValue();
found = true;
}
}
catch (ClassNotFoundException ex) {}
catch (NoSuchMethodException ex) {}
catch (IllegalAccessException ex) {}
catch (IllegalArgumentException ex) {}
catch (InvocationTargetException ex) {}
catch (NullPointerException ex) {}
catch (ExceptionInInitializerError ex) {}
} else {
index = iterateTag.getIndex();
found = true;
}
if (!found) {
// this tag should only be nested in iteratetag, if it's
not, throw exception
JspException e = new
JspException(messages.getMessage("indexed.noEnclosingIterate"));
RequestUtils.saveException(pageContext, e);
throw e;
}
if (name != null)
handlers.append(name);
handlers.append("[");
handlers.append(index);
handlers.append("]");
if (name != null)
handlers.append(".");
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 4 Jan 2003, James Turner wrote:
> As has been pointed out, about the only remaining reason to use
> logic:iterate over c:forEach is that you can't use an html:text tag (or
> friends) with an "indexed" property set, because it only looks for
> logic:iterate on the page stack.
>
> Now, it would be very simple (having peered at the source) to have the
> html tags also look for JSTL iterators. However, to make this work,
> we'd need to add a dependency on jakarta-taglibs so that the class would
> be available.
>
> I don't think that this would break anything in terms of JSP version
> support, since it wouldn't require evaluation of ELs, just looking up
> the stack to see if we find a JSTL interator hanging around.
>
> Opinions?
If you want to do this, I'd rather see it happen in the html-el taglib
than the regular html taglib. Struts-EL already depends on JSTL, and is
designed to work in cooperation with it, so it's a much more natural fit
than trying to sneak JSTL functionality into the regular tags.
--
Martin Cooper
>
> _________________________________________
> James
> ICQ#: 8239923
> More ways to contact me: http://wwp.icq.com/8239923
> See more about me: http://web.icq.com/whitepages/about_me?Uin=8239923
> _________________________________________
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and friends
Posted by "David M. Karr" <dm...@earthlink.net>.
>>>>> "Craig" == Craig R McClanahan <cr...@apache.org> writes:
Craig> On Sat, 4 Jan 2003, James Turner wrote:
>> Date: Sat, 4 Jan 2003 13:26:34 -0500
>> From: James Turner <tu...@blackbear.com>
>> Reply-To: Struts Developers List <st...@jakarta.apache.org>
>> To: struts-dev@jakarta.apache.org
>> Subject: Another bright idea,
>> make "indexed" work with JSTL forEach and friends
>>
>> As has been pointed out, about the only remaining reason to use
>> logic:iterate over c:forEach is that you can't use an html:text tag (or
>> friends) with an "indexed" property set, because it only looks for
>> logic:iterate on the page stack.
>>
>> Now, it would be very simple (having peered at the source) to have the
>> html tags also look for JSTL iterators. However, to make this work,
>> we'd need to add a dependency on jakarta-taglibs so that the class would
>> be available.
>>
>> I don't think that this would break anything in terms of JSP version
>> support, since it wouldn't require evaluation of ELs, just looking up
>> the stack to see if we find a JSTL interator hanging around.
Craig> Unless you can do this all with reflection (instead of instanceof and
Craig> direct method calls), you'll create NoClassDefFound errors for people who
Craig> don't have the JSTL library in the stack. Other than that caution, I'm
Craig> +1.
That would be gnarly to try to do this with all string-based reflection (no
"ClassName.class" references or "instanceof" usage). Writing a version of
"findAncestorWithClass" that takes a string instead of a Class is the first
step. You'd also have to deal with allowing subclasses of the tag types.
That's probably the ugliest part.
At this point, I really don't see the urgency.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr@earthlink.net ; SCJP; SCWCD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another bright idea, make "indexed" work with JSTL forEach and
friends
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 4 Jan 2003, James Turner wrote:
> Date: Sat, 4 Jan 2003 13:26:34 -0500
> From: James Turner <tu...@blackbear.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Another bright idea,
> make "indexed" work with JSTL forEach and friends
>
> As has been pointed out, about the only remaining reason to use
> logic:iterate over c:forEach is that you can't use an html:text tag (or
> friends) with an "indexed" property set, because it only looks for
> logic:iterate on the page stack.
>
> Now, it would be very simple (having peered at the source) to have the
> html tags also look for JSTL iterators. However, to make this work,
> we'd need to add a dependency on jakarta-taglibs so that the class would
> be available.
>
> I don't think that this would break anything in terms of JSP version
> support, since it wouldn't require evaluation of ELs, just looking up
> the stack to see if we find a JSTL interator hanging around.
>
Unless you can do this all with reflection (instead of instanceof and
direct method calls), you'll create NoClassDefFound errors for people who
don't have the JSTL library in the stack. Other than that caution, I'm
+1.
> Opinions?
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>