jakarta site leftovers

[Henri Yandell]

Now that tomcat.apache.org contains a site, anyone mind if I remove
/www/jakarta.apache.org/tomcat and tomcat-temp?

Also, could the watchdog directory be moved over to
/www/tomcat.apache.org/watchdog please?

Thanks,

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Missing tag in SVN

[Henri Yandell]

It was pointed out to me that Tomcat/servletapi is missing a tag. In
https://svn.apache.org/repos/asf/tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/
there is no TOMCAT_5_5_12.

Looking at /home/cvs/servletapi-5/LICENSE,v there definitely was such
a tag, and a quick set of find's and a diff show that said tag was
identical to the TOMCAT_5_5_11 tag.


-bash-2.05b$ find . -type f | xargs grep TOMCAT_5_5_12 | sed
's/5_5_12/5_5_X/' > ~/TC-12
-bash-2.05b$ find . -type f | xargs grep TOMCAT_5_5_11 | sed
's/5_5_11/5_5_X/' > ~/TC-11
-bash-2.05b$ diff ~/TC-12 ~/TC-11
-bash-2.05b$ wc ~/TC-*
 207 436   12846 /home/bayard/TC-11
 207 436   12846 /home/bayard/TC-12
 414 872   25692 total
-bash-2.05b$


So it seems to me that we could just copy the 5_5_11 tag to 5_5_12 and
everything would be rosy.

Any thoughts?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Missing tag in SVN

[Henri Yandell]

Nope, just a colleague looking to prove they can recreate the 5.5.12 build.

On 1/5/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> Hi,
> Hmm, strange.  But this shouldn't be a big deal to anyone: we can copy
> the tag as you suggest IMHO.  Did the person pointing it out have some
> problem/issue, or just happen to notice this oddity?
>
> Yoav
>
> On 1/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > It was pointed out to me that Tomcat/servletapi is missing a tag. In
> > https://svn.apache.org/repos/asf/tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/
> > there is no TOMCAT_5_5_12.
> >
> > Looking at /home/cvs/servletapi-5/LICENSE,v there definitely was such
> > a tag, and a quick set of find's and a diff show that said tag was
> > identical to the TOMCAT_5_5_11 tag.
> >
> > 
> > -bash-2.05b$ find . -type f | xargs grep TOMCAT_5_5_12 | sed
> > 's/5_5_12/5_5_X/' > ~/TC-12
> > -bash-2.05b$ find . -type f | xargs grep TOMCAT_5_5_11 | sed
> > 's/5_5_11/5_5_X/' > ~/TC-11
> > -bash-2.05b$ diff ~/TC-12 ~/TC-11
> > -bash-2.05b$ wc ~/TC-*
> >  207 436   12846 /home/bayard/TC-11
> >  207 436   12846 /home/bayard/TC-12
> >  414 872   25692 total
> > -bash-2.05b$
> > 
> >
> > So it seems to me that we could just copy the 5_5_11 tag to 5_5_12 and
> > everything would be rosy.
> >
> > Any thoughts?
> >
> > Hen
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA, USA
> [EMAIL PROTECTED] / www.yoavshapira.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat DBCP modification

[Henri Yandell]

Just noticed while digging into the Tomcat build that Tomcat pulls the
source to dbcp/collections/pool and repackages it under
org.apache.tomcat.dbcp after making a source change.

I was wondering if this is just done to remove the UnmodifiableList
bit, or is it done for size or classloading issues?

Anything that could be done in Commons to make things easier?

Thanks,

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binary build procedures

[Henri Yandell]

On 5/25/06, Mark Claassen <[EMAIL PROTECTED]> wrote:

I have a question about two optional packages: mx4j and junit.

Are they really optional?  I realize that some build processes may use junit
to test the build, but does it need to in the distribution?


Looking at the latest binary, junit doesn't get shipped.


Also, what is mx4j used for.  If I don't it, can I not use JMX?


connectors/jk/java/org/apache/jk/common/JkMX.java is the only class
using mx4j. Check its javadoc out to decide if you want to be
distributing mx4j in your Tomcat build.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Taglibs] Is anyone looking after taglibs?

[Henri Yandell]

I'll take care of it as a part of the Jakarta retirement.

Hen

On Thu, Nov 3, 2011 at 10:33 AM, sebb  wrote:
> The Jakarta TLP is about to retire to the attic; however the taglibs
> site still refers to non-existent jakarta pages for the downloads.
>
> A bug [1] was raised for this for this some while ago, but there
> appears to be no-one interested in fixing the issue.
>
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51382
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Time for Taglibs to be sent to the archive?

[Henri Yandell]

Hard to argue against it. I've no energy for Taglibs coding. I wish
we'd got a JSTL 1.2 released, but c'est la vie.

All the steps listed sound good except removing the website.
Historically on the Attic side we've kept the websites up with a
notice that the project is dead, rather than going dark on people.

Hen

On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez  wrote:
> If there is no activity, it make sense.
>
> +0
>
> 2012/10/1 Mark Thomas :
>> In the two+ years since Taglibs moved to the Tomcat project there have
>> been a few short bursts of activity totalling just over 200 commits but
>> no releases. There has also been no progress towards a migration to
>> svnpubsub for the taglibs part of the web site.
>>
>> Given the lack of progress I would propose that Taglibs is moved to our
>> archive. This would mean:
>>
>> - removing the Taglibs link from tomcat.a.o
>> - removing the Taglibs web pages
>> - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs
>> - making the Taglibs BZ project read-only
>> - moving the Taglibs committers to emeritus status
>> - removing the Taglibs from Gump
>>
>> There is nothing to remove from dist.a.o since there have been no releases
>>
>> Note: This is intended as a discussion topic - not a formal proposal/vote.
>>
>> Thoughts?
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Taglibs SVN migration to Tomcat

[Henri Yandell]

Post discussion between Tomcat PMC and Jakarta PMC (with myself as the
go between), the Jakarta Taglibs subproject is going to move over to
Tomcat land. Chiefly this means:

* The JSTL implementations: 1.0, 1.1 and unreleased 1.2.
* RDC Taglib.
* An in development 'extended' taglib.

The Jakarta Taglibs site will become a Retired page, and move into the
Attic once a few remaining bits of code have been picked over for the
extended taglib. A year or so.

I'd like to do the SVN move, dev@ permitting. This would mean
something like the following in the ASF public repo:

tomcat/
  taglibs/
  standard/
 tags/
 branches/
 trunk/
  extended/
 tags/ (empty)
 branches/ (empty)
 trunk/
  rdc/
 tags/
 branches/ (empty)
 trunk/
  site/   [subsite -> tomcat.apache.org/taglibs/]
  taglibs-parent/   [maven parent pom]

The tags and branches are generally historical in that they're hard to
build directly as there are missing parent build.xml and common.xml
files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL
1.1 bugfix is needed, then migrating them to Maven2 or fixing their
build systems are options.

Tomcat svn karma would be given to bayard, kris + rahul.

Mailing lists - I'm thinking of moving the taglibs-user@ list from
Jakarta to Tomcat while killing the taglibs-dev list in favour of
d...@tomcat.

Anyway - all open to discussion + debate; let me know what works best
from this list's point of view.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Taglibs SVN migration to Tomcat

[Henri Yandell]

SVN move done. The Jakarta side points over to Tomcat for now, I'll be
retiring what's left over there later.

I hand edited the RDC website to point over to the Tomcat SVN location
on people.apache.org.  The Standard taglib's site is not in a happy
state so I'll be working on getting that setup next. Rahul and I both
have the tomcat unix group now, so I'll work on moving the sites over
into tomcat.apache.org/taglibs this week; and setting up the redirects
on the Jakarta side.

Hen

On Thu, Aug 13, 2009 at 1:48 AM, Henri Yandell wrote:
> Post discussion between Tomcat PMC and Jakarta PMC (with myself as the
> go between), the Jakarta Taglibs subproject is going to move over to
> Tomcat land. Chiefly this means:
>
> * The JSTL implementations: 1.0, 1.1 and unreleased 1.2.
> * RDC Taglib.
> * An in development 'extended' taglib.
>
> The Jakarta Taglibs site will become a Retired page, and move into the
> Attic once a few remaining bits of code have been picked over for the
> extended taglib. A year or so.
>
> I'd like to do the SVN move, dev@ permitting. This would mean
> something like the following in the ASF public repo:
>
> tomcat/
>  taglibs/
>      standard/
>         tags/
>         branches/
>         trunk/
>      extended/
>         tags/ (empty)
>         branches/ (empty)
>         trunk/
>      rdc/
>         tags/
>         branches/ (empty)
>         trunk/
>      site/   [subsite -> tomcat.apache.org/taglibs/]
>      taglibs-parent/   [maven parent pom]
>
> The tags and branches are generally historical in that they're hard to
> build directly as there are missing parent build.xml and common.xml
> files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL
> 1.1 bugfix is needed, then migrating them to Maven2 or fixing their
> build systems are options.
>
> Tomcat svn karma would be given to bayard, kris + rahul.
>
> Mailing lists - I'm thinking of moving the taglibs-user@ list from
> Jakarta to Tomcat while killing the taglibs-dev list in favour of
> d...@tomcat.
>
> Anyway - all open to discussion + debate; let me know what works best
> from this list's point of view.
>
> Hen
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Taglibs SVN migration to Tomcat

[Henri Yandell]

On Mon, Aug 17, 2009 at 10:51 AM, Rahul Akolkar wrote:
> On Mon, Aug 17, 2009 at 1:04 AM, Henri Yandell wrote:
>
>> I hand edited the RDC website to point over to the Tomcat SVN location
>> on people.apache.org.
> 
>
> Not clear what that means.

I modified the pom and edited
http://jakarta.apache.org/taglibs/rdc/source-repository.html - but I
missed that RDC has multiple poms in it.

>>  The Standard taglib's site is not in a happy
>> state so I'll be working on getting that setup next. Rahul and I both
>> have the tomcat unix group now, so I'll work on moving the sites over
>> into tomcat.apache.org/taglibs this week; and setting up the redirects
>> on the Jakarta side.
>>
> 
>
> I can certainly push out a site or two -- if you want, I can do RDC
> (and extended even) while you appease Standard.

No real site for extended yet - but feel very free to put something
simple together if you'd like :)

> Which reminds me, our commit messages are not hitting the list (I made
> a pom update as well). I'll wait a bit more and then will ping
> dev-owner to allow {bayard,rahul,kris}.

Thanks.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Taglibs SVN migration to Tomcat

[Henri Yandell]

On Tue, Aug 18, 2009 at 9:16 PM, Rahul Akolkar wrote:
> On Mon, Aug 17, 2009 at 1:51 PM, Rahul Akolkar wrote:
>> On Mon, Aug 17, 2009 at 1:04 AM, Henri Yandell wrote:
> 
>>>  The Standard taglib's site is not in a happy
>>> state so I'll be working on getting that setup next. Rahul and I both
>>> have the tomcat unix group now, so I'll work on moving the sites over
>>> into tomcat.apache.org/taglibs this week; and setting up the redirects
>>> on the Jakarta side.
>>>
>> 
>>
>> I can certainly push out a site or two -- if you want, I can do RDC
>> (and extended even) while you appease Standard.
>>
>
> A start: http://tomcat.apache.org/taglibs/rdc/

General theme looks good :)

The title still mentions Jakarta. Should rename to:

"Apache RDC Taglib - Reusable Dialog Components Tag Library"

Basically we should have been branding ourselves with "Apache" rather
than "Jakarta" for about 6 years now :)

> For the main site, couple of changes come to mind before deploying, we should:
> (a) flatten out the directory structure a bit (stuff in this site
> directory [1] can just go in the parent xdoc directory really)

I've found it makes things easier to have these all together (like
redirecting them for example), but given that Maven puts other files
into the parent directory anyway it's not much of a justification.

> (b) list only the bits moved over in the LHS menu.
>
> -Rahul
>
> [1] http://svn.apache.org/repos/asf/tomcat/taglibs/site/src/site/xdoc/site/

I think we also need a simultaneous page in
jakarta/site/retired/taglibs.html that lists out the retired taglibs.
Plus that means a bit of complexity in the .htaccess; we'll want to
keep the old sites for retired taglibs so no global redirect of
/taglibs/ over. Instead we'll need to list explicitly the items to
redirect over to the Tomcat side.

So... steps:

* New Standard site that merges 1.0, 1.1 and 1.x docs together, rather
than treating them as separate taglibs.
* Retired Jakarta Taglibs page.
* New Taglibs site that flattens and updates for Tomcat land.
* RDC Taglib regenerated from final taglib-parent.
* Extended Taglib site. Can be pretty minimal.
* Jakarta Taglibs htaccess rules.
* Link on tomcat.apache.org when all looks good and Tomcat dev@ approves.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Taglibs SVN migration to Tomcat

[Henri Yandell]

On Wed, Aug 19, 2009 at 9:25 PM, Rahul Akolkar wrote:
> On Wed, Aug 19, 2009 at 11:00 AM, Henri Yandell wrote:

>> So... steps:
>>
>> * New Standard site that merges 1.0, 1.1 and 1.x docs together, rather
>> than treating them as separate taglibs.
>> * Retired Jakarta Taglibs page.
>> * New Taglibs site that flattens and updates for Tomcat land.
>> * RDC Taglib regenerated from final taglib-parent.
>> * Extended Taglib site. Can be pretty minimal.
>> * Jakarta Taglibs htaccess rules.
>> * Link on tomcat.apache.org when all looks good and Tomcat dev@ approves.
>>
> 
>
> Looks reasonable to me.

I've created a Retired Jakarta Taglibs page. Not hooked up yet; two
small missing steps at the end of the above are:

* Add link to Retired Jakarta Taglibs page from Jakarta Retired page.
* Move Taglibs into the Ex-Jakarta on the LHS.

We should also link to the Retired Jakarta Taglibs page from the
Tomcat Taglibs front page.

Once the rsync happens, the url will be:

http://jakarta.apache.org/site/retired-taglibs.html

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Testing new website sync process

[Henri Yandell]

Generally +1.

Noting that this includes the Taglibs subsites which are Maven based.

Hen

On Thu, Sep 3, 2009 at 3:59 AM, Mark Thomas wrote:
> Folks,
>
> As part of the response to the recent compromise of ASF servers [1] the
> infrastructure team are introducing a new way to sync web sites from svn
> and are looking for PMS to volunteer to test the new process.
>
> I'd like to volunteer the Tomcat website. Any objections? I'm happy to
> take on fixing any teething problems.
>
> The advantage is that commits to svn will be reflected on the live site
> within a few seconds.
>
> If we want we can also have a staging site tomcat.staging.a.o where we
> could preview stuff [2]
>
> My own view is that a staging site isn't necessary. Our site is simple.
> We can test locally before committing and with commits affecting the
> live site within a few seconds, fixing any snafus should be easy.
>
> Cheers,
>
> Mark
>
> [1] http://blogs.apache.org/infra/
>
> [2] This require a separate svn location to sync from. Something like:
> http://svn.apache.org/repos/asf/tomcat/site/branches/live
> would sync to
> http://tomcat.apache.org/
> and
> http://svn.apache.org/repos/asf/tomcat/site/trunk
> would sync to
> http://tomcat.staging.apache.org/
> and we would have to svn merge changes from trunk to live.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Testing new website sync process

[Henri Yandell]

Did this go through Mark?

Where do I commit the Taglibs site?

Hen

On Thu, Sep 3, 2009 at 3:59 AM, Mark Thomas  wrote:
> Folks,
>
> As part of the response to the recent compromise of ASF servers [1] the
> infrastructure team are introducing a new way to sync web sites from svn
> and are looking for PMS to volunteer to test the new process.
>
> I'd like to volunteer the Tomcat website. Any objections? I'm happy to
> take on fixing any teething problems.
>
> The advantage is that commits to svn will be reflected on the live site
> within a few seconds.
>
> If we want we can also have a staging site tomcat.staging.a.o where we
> could preview stuff [2]
>
> My own view is that a staging site isn't necessary. Our site is simple.
> We can test locally before committing and with commits affecting the
> live site within a few seconds, fixing any snafus should be easy.
>
> Cheers,
>
> Mark
>
> [1] http://blogs.apache.org/infra/
>
> [2] This require a separate svn location to sync from. Something like:
> http://svn.apache.org/repos/asf/tomcat/site/branches/live
> would sync to
> http://tomcat.apache.org/
> and
> http://svn.apache.org/repos/asf/tomcat/site/trunk
> would sync to
> http://tomcat.staging.apache.org/
> and we would have to svn merge changes from trunk to live.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Taglibs website migration

[Henri Yandell]

I've pushed the current state of the Taglibs site out:

http://tomcat.apache.org/taglibs/

It's not ready to go live, but it gives us a good feel for what's left to do.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r816441 - /tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml

[Henri Yandell]

On Tue, Sep 22, 2009 at 10:06 AM, Rahul Akolkar  wrote:
> On Thu, Sep 17, 2009 at 10:32 PM,   wrote:
>> Author: bayard
>> Date: Fri Sep 18 02:32:18 2009
>> New Revision: 816441
>>
>> URL: http://svn.apache.org/viewvc?rev=816441&view=rev
>> Log:
>> Commenting out the list of taglibs. Changing urls to be tomcat.apache.org 
>> except for the Download one which we'll handle later. Hope this doesn't hurt 
>> RDC Rahul.
>>
> 
>
> Thanks Hen, should be OK now that the migration is complete -- ISTR
> running into relative URL issues when the RDC site was migrated but
> the parent and rest were still pointing to Jakarta.
>
> Out of curiosity, whats your m2 and site plugin version?
>
> -Rahul

My m2 is 2.2.0. Latest site plugin in .m2 is 2.0-beta-7.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Taglibs website migration

[Henri Yandell]

This is now live.

The Jakarta side of things has been retired and some redirects exist.
It's ready to be linked to from tomcat.apache.org.

What do people think is best?

a) A "Taglibs" entry under the Home link.
b) Individual entries per Taglib under Download and Documentation.
c) A Taglibs entry under Download and one under Documentation
(currently there's not a Taglibs download page - each taglib handles
its own).
d) Something else.

Hen

On Sat, Sep 19, 2009 at 2:40 AM, Henri Yandell  wrote:
> I've pushed the current state of the Taglibs site out:
>
>    http://tomcat.apache.org/taglibs/
>
> It's not ready to go live, but it gives us a good feel for what's left to do.
>
> Hen
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Taglibs website migration

[Henri Yandell]

Thanks all - I've gone with option a) and will change if there's a
change of consensus. Should show up on the site in a few hours.

Migration complete :)

Hen

On Tue, Oct 6, 2009 at 6:58 AM, Rainer Jung  wrote:
> On 05.10.2009 22:11, Henri Yandell wrote:
>> This is now live.
>>
>> The Jakarta side of things has been retired and some redirects exist.
>> It's ready to be linked to from tomcat.apache.org.
>>
>> What do people think is best?
>>
>> a) A "Taglibs" entry under the Home link.
>
> +1

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]

[Henri Yandell]

(dropping tomcat-users@)

The BSF Taglib was deprecated in July 2007, one of the first to be
recognized as unsupported. And as you say below, retired in the
Taglibs move to Tomcat.

If BSF users still have a strong need for it for legacy reasons, I'd
suggest it go in Jakarta BSF. There's been no one in the Jakarta
Taglibs (and now Tomcat I'll assume) project with an interest for many
years now (the last code change being in 2002). If there's strong
interest in JSP support of the JSR-223, that would be tempting either
for Extended Taglib if simple enough an API or its own BSF/JSR223
Taglib that (assuming people wanted to actually code it) could be in
Apache Taglibs at Tomcat.

An opinion anyway :)

Hen

On Fri, Oct 9, 2009 at 4:30 AM, Rony G. Flatscher (Apache)
 wrote:
> Hi there,
>
> not sure whether this is a user or dev question, hence sending it to
> both, please forgive, if wrong.
>
> Learning about the finalization of moving taglib from jakarta to tomcat,
> one could also learn that the BSF taglib got retired in the process.
> AFAIK the BSF taglib has been allowing one to add code in all of the BSF
> supported scripting languages to JSPs. Not knowing, wheter there are
> alternatives available in the current Tomcat (did a coarse research on
> that issue, but did not find any info on this) I created the enclosed
> e-mail to the BSF user and dev list to make sure, that users of the BSF
> taglib learn about where it has moved to, in case it is still needed.
>
> In case the BSF taglib is needed for adding scripts in scripting
> languages to JSPs, I would kindly suggest to not retire it, but to keep
> it available for interested parties in the Tomcat realm. In case there
> are alternatives available in Tomcat to the BSF taglib, please be so
> kind and point them out (just short pointers would suffice!).
>
> TIA,
>
> ---rony
>
> P.S.: If the BSF taglib is still needed, then one more (dev) point to
> discuss/raise would be to create in a addition a new JSR-223/BSF3 taglib
> for the newly released BSF 3.0, which implements the JSR-223
> (javax.script) specs. Unlike JSR-223, which is only available starting
> with Java 6, BSF 3 supplies the same functionality for Java 1.4
> installations or higher, making it a very attractive technology for Java
> 1.4 and 1.5 installations, as they gain the standard scripting APIs with
> it. There would be more to this, but should only be discussed, if a need
> for this exists.
>
>
>  Original Message 
> Subject:        In the move of some taglibs to Tomcat, the BSF taglib got 
> retired
> Date:   Fri, 09 Oct 2009 12:18:31 +0200
> From:   Rony G. Flatscher 
> Reply-To:       Bean Scripting Framework developers 
> 
> To:     Bean Scripting Framework developers ,
> Bean Scripting Framework users 
>
>
>
> Hi there,
>
> just learned from the announcement that in the process of moving taglibs
> from Jakarta to Tomcat a lot of taglibs got retired, among them the BSF
> taglib.
>
> Not sure at the moment how Tomcat will allow for creating JSPs that
> embed code in scripting languages, which was one of the original
> applications of BSF, when it was originally developed at IBM (as a
> matter of fact, IBM's WebSphere distributed BSF in order to enable Java
> Server Page authors to embed scripts in any of its supported scripting
> languages, very much like MS allows for in their ASPs).
>
> So for those who have a need for the BSF taglib, here the relevant links:
>
> Information about BSF taglib and examples on how to use it:
>
>    
>
> Download BSF taglib from:
>
>    
>
> Retired taglibs as of 2009-10:
>
>    
>
> ---rony
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]

[Henri Yandell]

Not sure where Christopher's email was, but:

If there is any interest in a retired taglib, I'm all for it being
merged into the Extended Taglib. Currently I plan to consider
replacing the functionality from String Taglib (mostly as EL
functions), Log Taglib and JNDI Taglib (perhaps).

It sounds like BSF taglib, given it has only the two tags, might be
very interesting if a dependency on BSF itself can be avoided (ie:
base it on javax.script).

Hen

On Sun, Oct 11, 2009 at 4:31 AM, Rony G. Flatscher (Apache)
 wrote:
> Christopher,
>
> thanks for your information!
>
>> > AFAIK the BSF taglib has been allowing one to add code in all of the
>> > BSF supported scripting languages to JSPs. Not knowing, wheter there
>> > are alternatives available in the current Tomcat
>>
>> Tomcat itself contains little in the way of tag libraries, except for
>> the JSTL required by the JSP 2.1 specification (and higher).
>>
>> > In case the BSF taglib is needed for adding scripts in scripting
>> > languages to JSPs, I would kindly suggest to not retire it, but to
>> > keep it available for interested parties in the Tomcat realm.
>>
>> So, let me clear a few things up:
>>
>> 1. The Tomcat team didn't retire the BSF tag library. The Jakarta BSF
>> tag library folks retired it. You should complain to them.
> They are all off (enjoying retirement) ...
> ;-)
>
>> 2. The Apache Software Foundation (ASF) never deletes code forever. Just
>> because it's retired doesn't mean it's no longer available: it just
>> means that they will no longer be maintaining it by adding features,
>> fixing bugs, or answering questions about it.
> Yes, but the semantics of "retirement" indicates that they go out of
> service (are not useful in todays world anymore).
>
>> Note that the jakarta-taglibs-BSF project hadn't had a news announcement
>> since 2002, so it was pretty much already dead.
> Yes, but does that mean it is not useful anymore, needs to get retired,
> has become irrelevant?
>
> In this particular case it is just a sign that this particular
> functionality has become stable and there has not been a need to add new
> functionality (what functionality would have been needed in this taglib,
> other than enabling scripting languages to become usable to create
> scripts embedded in JSPs) ?
>
> Coming from BSF (which BSF taglib exploits) it is not clear to me,
> whether Tomcat users have been exploiting this taglib or not (actually,
> if it gets retired, this means that either the taglib is not needed
> anymore, because of an alternative technology put in place, or the
> taglib has not been exploited, used at all).
>
>> > In case there are alternatives available in Tomcat to the BSF taglib,
>> > please be so kind and point them out (just short pointers would
>> > suffice!).
>>
>> What is it that you are trying to do, exactly? It's possible that simply
>> using the BSF library directly (without a tag library) is your best
>> option. There was a fad for a while where everything was being wrapped
>> into a tag library and JSP was starting to look like ColdFusion. CF was
>> eventually re-implemented in Java using JSP tag libraries so I guess JSP
>> had the last laugh.
>>
>> I never thought non-UI-related tag libraries had any business existing
>> because I firmly believe in separation between model/controller and
>> view: the view simply should not be sending emails, communicating with
>> databases (at least not directly), sending JMS messages, or copying
>> files around.
> E.g. if you look into the MS world you will immediately stumble over
> tons of ASPs which employ tons (even a mix) of scripting languages.
> Scripting languages in that world empower even end-user kind of
> programmers to quickly and easily insert code in a language they can
> master for web-based applications (and again, they take advantage of
> that possibility). (There are more reasons, arguments, why it may
> actually make sense to allow scripting languages to be used in server
> pages, of cours.)
>
> Also, experts in once scripting language are enabled to apply their
> knowledge for Web apps by creating the needed logic in their scripting
> language for server pages, removing the need for them to learn a new
> programming language. (Again, there are other good reasons as well.)
>
>> If you want to use another scripting language to generate content, then
>> why bother with JSP in the first place? Why not use a tool geared
>> towards allowing you to use your scripting-language of choice outside of
>> a JSP context?
> This would lead to environments that lock-in the developers in specific
> environments, which only are available for themselves (cf. PHP, Ruby,
> etc. environments). Having an established and proven environment
> available, like Tomcat, making it possible to mix-in code in scripting
> languages, would be a boon.
>
> If it is possible to include script code into JSPs, then why not allow
> for that? The BSF taglib would allow for that, making it possible to
> mix-an

Re: SSL & Tomcat

[Henri Yandell]

On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas  wrote:
> All,
>
> I was thinking about this on my way back from ApacheCon and we probably
> need to get some advice out to users early next week.
>
> My current understanding is that the MITM attack is triggered by a
> renegotiation.
>
> On this basis I suggest something along the following lines:
>
> SSL using JSSE (BIO and NIO connectors)
> - Don't use SSL configs that require renegotiation. i.e. SSL config
> should be the same for the entire host. Sites that require SSL in some
> places and SSL + CLIENT-CERT in others will require reconfiguration.
> Sites that require SSL for some parts should be OK.
> - Keep watch for a Sun update to the JDK that may help address the issue

Also IBM, BEA, Apple etc. I'm not sure if JSSE is something Sun
license to everyone, or if other JVMs have their own implementation
(maybe OpenSSL based?). Harmony presumably does, though no idea if
it's OpenSSL or clean room (couldn't see anything on a vague browse
through their svn).

> SSL using tc Native
> - tcnative does not support renegotiation
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now
> users of tc native with SSL should be OK

+1

> We also need to think about what to do with tc native. Maybe something like:
> - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is
> disabled)
> - keep an eye on httpd and if they find a work-around, copy it and
> release 1.1.18 with renegotiation enabled

Plus keeping an eye on the next openssl version for
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
?

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: SSL & Tomcat

[Henri Yandell]

On Wed, Nov 11, 2009 at 12:09 AM, Luciana Moreira Sa de Souza Signed
by  - PrivaSphere AG  wrote:
> Hello,
>
> I am currently working on my company's platform to get around this security
> problem during re-negotiation. After discussing with my group about the
> progress being made towards a fix for tomcat, some questions were raised and
> I was hoping you could help me answer them.
>
> We use Tomcat 5.5 with JSSE installed via apt-get in the debian lenny
> distribution. Are there any plans of putting this fix as an update in the
> debian package?
>
> The other question is in relation to the configuration of this fix. I saw
> proposals of putting a property in the server.xml to prevent renegotiation
> from happening. Will this be done on a per Connector basis or will this be
> Server setting? I ask this since we have parts of the server were we would
> like to keep the old behavior and other parts that we have to completely
> stop re-negotiations.

Noting that the patch disables handshake renegotiation by default and
it's enabled per connector. i.e. opposite of your question.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] Questions in ForEachSupport

[Henri Yandell]

On Tue, Jun 29, 2010 at 11:45 PM, Jeremy Boynes  wrote:
> In bug 45197 https://issues.apache.org/bugzilla/show_bug.cgi?id=45197 Henri 
> wrote:
> * Look at questions in the length method in ForEachSupport.java
> * Look at commented out code in prepre in ForEachSupport.java
>
> By "in the length method" did you mean line #241 where the length gets set to 
> 0? That's
> different to the non-deferred case which throws an exception on line #402. 
> I'd suggest we do
> the same for both (throwing the exception).

That was the one. And agreed - throwing a JspTagException makes sense.

> The commented code in prepare that sets the itemsName EL variable is 
> redundant as that is
> also done in LoopTagSupport line #532 (assuming the Apache implementation of 
> the JSTL
> API). Looks like this can just be deleted.

Looks good; and that would have been the commented code in question.
The commented out ResultSet code below is also presumably just chaff,
but it was the variable setting that was newly introduced.

> if that sounds good, I'll contribute a patch for those changes.

Many thanks :)

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] Null handling in Functions

[Henri Yandell]

Agreed on 1.18.2. For String params (and Number, Character and
Boolean) it looks like Functions should be able to assume that they're
null-safe.

Hen

On Sun, Jul 4, 2010 at 12:20 PM, Jeremy Boynes  wrote:
> Different methods in our Functions implementation handle null parameters 
> inconsistently; for example, toUpperCase does not perform any null check 
> whereas indexOf does. If I grok the EL spec correctly, all String parameter 
> values should be coerced by the rules in 1.18.2 which would guarantee that 
> nulls are converted to "" and hence the null checks in the implementation are 
> redundant. I confirmed that  the EL implementation in Tomcat 7 [1] does this.
>
> My thought would be to remove them and rely on the JSP Engine to coerce 
> correctly. If this isn't safe then we should add similar checks to the other 
> methods.
>
> Thoughts?
> Thanks
> Jeremy
>
> [1] 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/lang/ELSupport.java?view=markup#l405
>  called from AstFunction#getValue
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] Null handling in Functions

[Henri Yandell]

With Tomcat 7 now out, it's tempting to focus on Taglibs in that space
rather than worrying about JavaEE5.

Does it do much for the user to add the annotations? Does it do much
for us on the development side?

On Mon, Jul 5, 2010 at 12:17 AM, Jeremy Boynes  wrote:
> I work on a patch to remove them and add JavaDoc.
>
> What do you think of adding JSR-303 javax.validation annotations like 
> NotNull? Those are part of JavaEE 6 so are guaranteed to be available there 
> but would require a dependency for a JavaEE5 environment. My thought would be 
> not to use them yet.
>
> Jeremy
>
> On Jul 4, 2010, at 11:36 PM, Henri Yandell wrote:
>
>> Agreed on 1.18.2. For String params (and Number, Character and
>> Boolean) it looks like Functions should be able to assume that they're
>> null-safe.
>>
>> Hen
>>
>> On Sun, Jul 4, 2010 at 12:20 PM, Jeremy Boynes  wrote:
>>> Different methods in our Functions implementation handle null parameters 
>>> inconsistently; for example, toUpperCase does not perform any null check 
>>> whereas indexOf does. If I grok the EL spec correctly, all String parameter 
>>> values should be coerced by the rules in 1.18.2 which would guarantee that 
>>> nulls are converted to "" and hence the null checks in the implementation 
>>> are redundant. I confirmed that  the EL implementation in Tomcat 7 [1] does 
>>> this.
>>>
>>> My thought would be to remove them and rely on the JSP Engine to coerce 
>>> correctly. If this isn't safe then we should add similar checks to the 
>>> other methods.
>>>
>>> Thoughts?
>>> Thanks
>>> Jeremy
>>>
>>> [1] 
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/lang/ELSupport.java?view=markup#l405
>>>  called from AstFunction#getValue
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.28

[Henri Yandell]

On Thu, Jul 8, 2010 at 3:59 AM, Rainer Jung  wrote:
> On 08.07.2010 01:14, sebb wrote:
>>
>> On 7 July 2010 21:19, Rainer Jung  wrote:
>>>
>>> On 07.07.2010 21:00, sebb wrote:

 On 7 July 2010 10:47, Rainer Jung    wrote:
>
> On 29.06.2010 17:17, jean-frederic clere wrote:
>>>
>  - build.properties: it would be nice, if you did the release changes
> to
> the
> file before tagging (and undo after) like Mark does for TC 7
> (properties
> version and version.build). That way checking the identity between the
> tag
> and the release source would be easier (less deltas to ignore).

 Or:

 Create clean workspace from SVN.

 Make any necessary updates that apply to the tag only.

 Create the tag from the workspace using svn copy dir https://.../

 Trunk is then untainted by unnecessary changes, and the tag commit
 e-mail shows the changes made.
 History is also preseved.
>>>
>>> I personally do not like edits of tags. I think tags should be used as a
>>> single cross cut through the code (like in CVS) and uniquely identify one
>>> revision, so not be edited. Personal preference though.
>>
>> My preference too. Tags should be immutable.
>>
>> I see now that my phrase "the tag commit e-mail shows the changes
>> made." could be taken to mean that the tag is editted.
>>
>> However that is not the case.
>>
>> The tag is created from the workspace + changes; the e-mail shows the
>> changes from the initial workspace checkout.
>>
>> So instead of seeing the changes as commits to trunk, followed by a
>> simple SVN copy which creates the tag, the copy and changes appear in
>> the tag creation e-mail itself.
>>
>> OK?
>
> Interesting, never tried that, sounds good, especially since the email you
> describe would contain the info you'd like to see (the changes relative to
> trunk). Good idea.

IIUC, it means the tag would not refer to any trunk revision. It gets
around having a commit to a tag by hiding the change in the copy.

I'd rather get over the notion that tags can't be modified than be
tagging uncommitted code.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.28

[Henri Yandell]

On Thu, Jul 8, 2010 at 9:36 AM, sebb  wrote:
> On 8 July 2010 16:22, Henri Yandell  wrote:
>>
>> IIUC, it means the tag would not refer to any trunk revision.
>
> Strictly speaking, yes, there is no exact match in trunk, because the
> version fixes are deliberately not applied to trunk.
>
>> It gets around having a commit to a tag by hiding the change in the copy.
>
> Sort of. The changes are not hidden, they are shown in the commit e-mail.

e-mails are fairly worthless though. The issue for me is that while it
is in the svn log history, it's in a trunk->tag copy that many will
assume is an atomic step.

Immutability of tags vs atomic commits.

>> I'd rather get over the notion that tags can't be modified than be tagging 
>> uncommitted code.
>
> All the code is committed; it's just not all in trunk.
>
> However, if you modify the tag after creation as you suggest, again
> the revisions to the tag won't appear in trunk.
>
> AFAICT, the only way to ensure that a tag corresponds to a trunk
> revision is to tag from trunk and then never change the tag =>
> immutable tag.

Agreed; but not agreed on it being important. The need for a tag to
point to a trunk revision is an arbitrary invention of our development
process; instead:

* Create release branch.
* Develop on release branch.
* Declare release branch releaseable [vote].
* 'Tag' by making release branch read-only. In SVN terms, mv the
release branch from 7.0.0-release to 7.0.0.

Not saying that's great, just that issue may be in how we're defining
the problem.

> The end result of the method I propose is similar to creating the tag
> and then updating it, but it's easier to spot violations, because a
> tag should only appear the once, and never in an update commit.

But obscures history. I may be weird - I seem to spend a lot of my
time in source control history so care a lot about keeping it simple.

Also I'm bikeshedding - I've not been a Tomcat release manager, so
there may be details that differ from my experience elsewhere.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] XPath support

[Henri Yandell]

On Fri, Jul 9, 2010 at 12:51 PM, Jeremy Boynes  wrote:
> In light of the performance issues logged against the XML taglib and 
> functional issues like #49578, I was looking at refactor the XML tags to use 
> the JAXP XPath API to pre-compile expressions and dynamically resolve 
> variables. I think this can be done fairly easily and will eliminate a lot of 
> the integration code in XPathUtil. However, I could not see how to expose the 
> full iteration context described in the spec for :
>
> * the context position is the iteration 'count' (with the same meaning as in 
> )
> * the context size is equal to the number of nodes in the node-set over which 
>  is iterating
>
> It looks like the current implementation does not support this:
>        https://issues.apache.org/bugzilla/show_bug.cgi?id=22765
> and in testing these functions always return -1 and 0 respectively.
>
> Presumably these should be returned by the XPath core functions position() 
> and last() respectively. However, the JAXP API only allows a single Node to 
> be passed in for evaluation and I could not see a way to provide the context 
> needed by these functions. I think this might be a limitation of JAXP.
>
> I plan to go ahead with the refactor as I think by simplifying our 
> implementation we will address the current performance issues and fix some of 
> the functional edge cases. It will also remove the hard dependency on the 
> Xalan implementation.The iteration context functions will remain broken 
> consistent with the current implementation.
>
> It might be possible to make this work using the low-level internal Xalan 
> APIs as this functionality is supported in Xalan's XSLT processing. To 
> support this in the future, I'll try to make the XPath usage pluggable so we 
> can drop in a Xalan-specific version in the future.
>
> Thoughts?

+1. Resolving the speed and some of the issues is worth making it
harder to resolve the other issues imo.

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] XPath support

[Henri Yandell]

On Wed, Jul 14, 2010 at 8:45 PM, Jeremy Boynes  wrote:
> On Jul 12, 2010, at 7:04 PM, Jeremy Boynes wrote:
>
>> I'm going to ping Xalan about the increase in time taken as expressions are 
>> evaluated as I would assume I'm doing something silly.
>
> I looked into the Xalan implementation and the problem appears to be in 
> creation of the DTM used by the underlying implementation. To evaluate the 
> expression it walks up the DOM tree to the parent and then iterates forward 
> over the tree until it reaches the initial context node. This leads to a 
> linear increase in execution time as the context node progresses through the 
> NodeList from the .
>
> I changed  and  to use Jaxen and did not see this issue. 
> The execution time for xpath evalutation over 1000 iterations was constant 
> and substantially faster than with Xalan: total of 62ms reparsing each time 
> or 21ms if precompiled, down from 1800ms.
>
> In light of this I'd like to propose we switch to Jaxen and add it as a 
> dependency.

Absolutely: +1

Great work :)

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] Tab police

[Henri Yandell]

+1 for reformatting.

I've lived with the terrible code style in taglibs for years because I
felt that reformatting it just for me was over the top. Now there are
more eyes on the code; PLEASE MAKE IT READABLE! :)

I'm assuming it's a one-time only reformat to get us onto something sane.

Hen

On Tue, Nov 16, 2010 at 7:45 PM, Rex Wang  wrote:
> What's the formatter you plan to use? Is it public and other committer
> obeyed? Otherwise, it will mess up again in future..
>
> Anyway, +1 for tab replacement with 4 spaces.
>
> -Rex
>
> 2010/11/16 Jeremy Boynes 
>
>> As well as the tabs, there are broader inconsistencies in the style (e.g.
>> consistent braces, missing javadoc, and the like) that lead to IDE warnings.
>>
>> How about running everything through a re-formatter to clean this up?
>> Downside is that it will make back-patching harder.
>> +1 from me.
>>
>> On Nov 16, 2010, at 5:28 AM, bugzi...@apache.org wrote:
>>
>> > https://issues.apache.org/bugzilla/show_bug.cgi?id=50279
>> >
>> >           Summary: Tab police
>> >           Product: Taglibs
>> >           Version: unspecified
>> >          Platform: PC
>> >        OS/Version: Windows XP
>> >            Status: NEW
>> >          Severity: normal
>> >          Priority: P2
>> >         Component: Unknown Taglib
>> >        AssignedTo: dev@tomcat.apache.org
>> >        ReportedBy: s...@apache.org
>> >
>> >
>> > Created an attachment (id=26301)
>> > --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26301)
>> > Fix tabs in examples code
>> >
>> > There are oodles of tabs in the Taglibs code.
>> >
>> > Tabs seem to be set at 8 spaces, at least in the examples section.
>> >
>> > I can provide patches for the other code if required.
>> >
>> > --
>> > Configure bugmail:
>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> > --- You are receiving this mail because: ---
>> > You are the assignee for the bug.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> > For additional commands, e-mail: dev-h...@tomcat.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat 7 & regex

[Henri Yandell]

May I suggest you emit a warning to the logs when comma is used in the
regexp for a few versions?

Hen

On Fri, Dec 24, 2010 at 10:34 AM, Mark Thomas  wrote:
> There are a number of configuration properties defined as "comma
> separated regular expressions". As someone pointed out at at ApacheCon
> that is a little odd. It stops "," being used in an expression and is
> inefficient.
>
> Having just been bitten by this while setting up the new Jira instance,
> I intend change all properties that take regex in Tomcat 7 to use a
> single regex. This will simplify the code, simplify configuration and
> make the regex processing faster.
>
> I probably won't get around to actually doing this until the new year.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] Move to pre-req Java 1.6 for Locale services?

[Henri Yandell]

+1, Java 1.5 is EOL as you say.

While Oracle are in the business of supporting the old versions when
it gets painful, we're not.

Hen

On Sun, Jan 2, 2011 at 3:27 PM, Jeremy Boynes  wrote:
> In Java6 support was added for LocaleServiceProviders that extend the Locales 
> supported by the java.text formatters. This causes #46052 as 
> getAvailableLocales() now needs to scan the entire classpath rather than just 
> return the Locales built in to the JRE. It also means we cannot continue to 
> cache the returned set of Locales if the taglib is shared between different 
> applications (for example, in a JavaEE6 environment where the taglibs are 
> supplied by the container) as it will now vary with context ClassLoader.
>
> The java.text getInstance() methods work around this by not scanning the 
> classpath if a match is found with one of the built-in providers. We can use 
> this method directly if the context only requires a single Locale (either 
> because we are using application-specified Locales, or because the request 
> only specified a single one, or because multiple ones in the request match 
> the resolution order (e.g. Firefox's "en-us,en").
>
> However, where a request specifies multiple Locales with different prefixes, 
> we still need to perform the matching ourselves as the JRE will *always* 
> match something (at least the ROOT Locale) but we cannot tell which. If we 
> stick to using the 1.5 level API we will trigger the uncacheable classpath 
> scan on 1.6 level VMs; however, 1.6 provides the 
> ServiceLoader#loadInstalled() API which can be used to determine the locales 
> installed in the JRE and hence avoid the application classpath scan for JRE 
> supplied locales (which are likely to be the most commonly used).
>
> As most users are likely to be running on 1.6 and we've not actually released 
> a version needing 1.5 and Sun's 1.5 is generally end-of-lifed, I'd like to 
> propose solving this with the 1.6 APIs and making it a pre-requisite. Any 
> issue with this?
>
> Cheers
> Jeremy
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] Move to pre-req Java 1.6 for Locale services?

[Henri Yandell]

As an alternative - can we implement this such that it uses this in
Java6 and falls back to the old bad code in 1.5 and before?

On Tue, Jan 11, 2011 at 1:43 AM, Henri Yandell  wrote:
> +1, Java 1.5 is EOL as you say.
>
> While Oracle are in the business of supporting the old versions when
> it gets painful, we're not.
>
> Hen
>
> On Sun, Jan 2, 2011 at 3:27 PM, Jeremy Boynes  wrote:
>> In Java6 support was added for LocaleServiceProviders that extend the 
>> Locales supported by the java.text formatters. This causes #46052 as 
>> getAvailableLocales() now needs to scan the entire classpath rather than 
>> just return the Locales built in to the JRE. It also means we cannot 
>> continue to cache the returned set of Locales if the taglib is shared 
>> between different applications (for example, in a JavaEE6 environment where 
>> the taglibs are supplied by the container) as it will now vary with context 
>> ClassLoader.
>>
>> The java.text getInstance() methods work around this by not scanning the 
>> classpath if a match is found with one of the built-in providers. We can use 
>> this method directly if the context only requires a single Locale (either 
>> because we are using application-specified Locales, or because the request 
>> only specified a single one, or because multiple ones in the request match 
>> the resolution order (e.g. Firefox's "en-us,en").
>>
>> However, where a request specifies multiple Locales with different prefixes, 
>> we still need to perform the matching ourselves as the JRE will *always* 
>> match something (at least the ROOT Locale) but we cannot tell which. If we 
>> stick to using the 1.5 level API we will trigger the uncacheable classpath 
>> scan on 1.6 level VMs; however, 1.6 provides the 
>> ServiceLoader#loadInstalled() API which can be used to determine the locales 
>> installed in the JRE and hence avoid the application classpath scan for JRE 
>> supplied locales (which are likely to be the most commonly used).
>>
>> As most users are likely to be running on 1.6 and we've not actually 
>> released a version needing 1.5 and Sun's 1.5 is generally end-of-lifed, I'd 
>> like to propose solving this with the 1.6 APIs and making it a 
>> pre-requisite. Any issue with this?
>>
>> Cheers
>> Jeremy
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] Move to pre-req Java 1.6 for Locale services?

[Henri Yandell]

*nod*.

Why don't we go ahead and release and leave this for a bugfix/minor
release afterwards?

If we choose to move to JDK 1.6; there will be a 1.5 available for use
that can be branched for serious bugfixes. If we choose to implement
both, we can but it won't hold up any release. It also gives us
something to do after the release so we can move to a release-often
mantra.

Hen

On Sun, Jan 16, 2011 at 1:38 PM, Jeremy Boynes  wrote:
> It's not really bad code in 1.5 - 1.6 added the ability to dynamically 
> support Locales with the consequence of needing to scan the classpath for 
> services when the locale is not provided by the VM. It works fine when 
> there's only a single Locale involved but falls short when you're trying to 
> best-match one of a set of Locales as there's no way to determine if fallback 
> has occurred (like you can with ResourceBundle#getLocale()).
>
> Supporting both JVMs can be done - it's just more work refactoring things out 
> from being built into the tag implementations.
>
> Another alternative would be to use Joda instead of the JVM date/time 
> formatters. That would also avoid the synchronization issues as Joda is 
> thread safe; the downside is that it's an external dependency. And we would 
> still need a solution for numbers.
>
> On Jan 16, 2011, at 11:33 AM, Henri Yandell wrote:
>
>> As an alternative - can we implement this such that it uses this in
>> Java6 and falls back to the old bad code in 1.5 and before?
>>
>> On Tue, Jan 11, 2011 at 1:43 AM, Henri Yandell  wrote:
>>> +1, Java 1.5 is EOL as you say.
>>>
>>> While Oracle are in the business of supporting the old versions when
>>> it gets painful, we're not.
>>>
>>> Hen
>>>
>>> On Sun, Jan 2, 2011 at 3:27 PM, Jeremy Boynes  wrote:
>>>> In Java6 support was added for LocaleServiceProviders that extend the 
>>>> Locales supported by the java.text formatters. This causes #46052 as 
>>>> getAvailableLocales() now needs to scan the entire classpath rather than 
>>>> just return the Locales built in to the JRE. It also means we cannot 
>>>> continue to cache the returned set of Locales if the taglib is shared 
>>>> between different applications (for example, in a JavaEE6 environment 
>>>> where the taglibs are supplied by the container) as it will now vary with 
>>>> context ClassLoader.
>>>>
>>>> The java.text getInstance() methods work around this by not scanning the 
>>>> classpath if a match is found with one of the built-in providers. We can 
>>>> use this method directly if the context only requires a single Locale 
>>>> (either because we are using application-specified Locales, or because the 
>>>> request only specified a single one, or because multiple ones in the 
>>>> request match the resolution order (e.g. Firefox's "en-us,en").
>>>>
>>>> However, where a request specifies multiple Locales with different 
>>>> prefixes, we still need to perform the matching ourselves as the JRE will 
>>>> *always* match something (at least the ROOT Locale) but we cannot tell 
>>>> which. If we stick to using the 1.5 level API we will trigger the 
>>>> uncacheable classpath scan on 1.6 level VMs; however, 1.6 provides the 
>>>> ServiceLoader#loadInstalled() API which can be used to determine the 
>>>> locales installed in the JRE and hence avoid the application classpath 
>>>> scan for JRE supplied locales (which are likely to be the most commonly 
>>>> used).
>>>>
>>>> As most users are likely to be running on 1.6 and we've not actually 
>>>> released a version needing 1.5 and Sun's 1.5 is generally end-of-lifed, 
>>>> I'd like to propose solving this with the 1.6 APIs and making it a 
>>>> pre-requisite. Any issue with this?
>>>>
>>>> Cheers
>>>> Jeremy
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>
>>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] Time to release 1.2.0?

[Henri Yandell]

On Sun, Jan 23, 2011 at 12:41 PM, Jeremy Boynes  wrote:
> The only bug remaining that impact the JSTL libraries is #46052 (locale 
> performance on 1.6). Henri suggested releasing in its current form which 
> sounds reasonable. Should we release this as 1.2.0? Is this a good version 
> number - should we use something like 1.2.0-beta?
>
> This will be the first release in a long time and the first since the switch 
> to a Maven based build. The process is described here
>        http://www.apache.org/dev/publishing-maven-artifacts.html
>
> I think we need to release the parent POM first to get it in the central 
> repo, and then the artifacts that depend on it.
>
> I'd volunteer to RM this but:
> 1) I'm not a PMC member (which I don't think matters if we get enough votes 
> from PMC members)

None of the Taglib committers are, so not an important one :)

> 2) I'd need to update my PGP key in the WoT (somehow)

Do we need new keys now? I can obviously hook you into the WoT if I'm
still in it given that we can arrange something during the day.

> 3) I've not done the above process before so will likely mess things up.

Me neither. Best foot forward etc :)

+1

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [taglibs] downloads and Jakarta references

[Henri Yandell]

Yeah, we need to add some local pages.

Hen

On Thu, Feb 24, 2011 at 3:58 AM, sebb  wrote:
> The RDC and JSTL pages still point to the Jakarta site for download links.
>
> Would it be possible to create local download pages instead?
>
> The download links don't appear on the Jakarta site, so it means the
> html and cgi files need special handling.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Standard Taglib 1.2.1

[Henri Yandell]

A very late and non-binding +1 :)


On Wed, Nov 13, 2013 at 6:58 PM, Jeremy Boynes  wrote:

> I'd like to release Apache Standard Taglib 1.2.1. This is an update to the
> withdrawn 1.2.0, built with JDK 1.7.0_45 to address JavaDoc issues and
> incorporating feedback on the documentation.
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachetomcat-132/
>
> Source Distribution:
>
> https://repository.apache.org/content/repositories/orgapachetomcat-132/org/apache/taglibs/taglibs-standard/1.2.1/
>
> SVN tag:
>
> https://svn.apache.org/repos/asf/tomcat/taglibs/standard/tags/taglibs-standard-1.2.1@
>  r1541786
> https://svn.apache.org/r1541786
>
> KEYS: https://svn.apache.org/repos/asf/tomcat/trunk/KEYS
>
> The proposed 1.2.1 release is:
> [ ] Broken - do not release
> [ ] OK - release as 1.2.1
>
> Thanks
> Jeremy
>

Taglib Site Update

[Henri Yandell]

Started digging into this last night. New computer so checkout, figure out
right version of Maven etc. 3.1.1 has issues with the site, so you have to
stay on 3.0.5.

I've made some initial changes, then discovered that we seem to have lost
the xdoc for the website (one file) for the standard subcomponent. So my
task tonight is to hunt that page down in the svn history and bring it
back.

Hen

Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/

[Henri Yandell]

Shouldn't be changing the copyright date until we actually make a
copyrightable modification to that product.

Hen


On Fri, Jan 3, 2014 at 10:08 AM,  wrote:

> Author: rjung
> Date: Fri Jan  3 18:08:32 2014
> New Revision: 1555177
>
> URL: http://svn.apache.org/r1555177
> Log:
> Happy new 2014!
>
> Modified:
> tomcat/taglibs/extended/trunk/NOTICE.txt
> tomcat/taglibs/rdc/trunk/NOTICE.txt
> tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt
> tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt
> tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt
> tomcat/taglibs/site/NOTICE.txt
> tomcat/taglibs/standard/trunk/NOTICE
> tomcat/taglibs/taglibs-parent/trunk/NOTICE
>
> Modified: tomcat/taglibs/extended/trunk/NOTICE.txt
> URL:
> http://svn.apache.org/viewvc/tomcat/taglibs/extended/trunk/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
>
> ==
> --- tomcat/taglibs/extended/trunk/NOTICE.txt (original)
> +++ tomcat/taglibs/extended/trunk/NOTICE.txt Fri Jan  3 18:08:32 2014
> @@ -1,5 +1,5 @@
>  Apache Extended Taglib
> -Copyright 2009-2012 The Apache Software Foundation
> +Copyright 2009-2014 The Apache Software Foundation
>
> -This product includes software developed by
> +This product includes software developed at
>  The Apache Software Foundation (http://www.apache.org/).
>
> Modified: tomcat/taglibs/rdc/trunk/NOTICE.txt
> URL:
> http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
>
> ==
> --- tomcat/taglibs/rdc/trunk/NOTICE.txt (original)
> +++ tomcat/taglibs/rdc/trunk/NOTICE.txt Fri Jan  3 18:08:32 2014
> @@ -1,5 +1,5 @@
>  Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library
> -Copyright 2004-2012 The Apache Software Foundation
> +Copyright 2004-2014 The Apache Software Foundation
>
> -This product includes software developed by
> +This product includes software developed at
>  The Apache Software Foundation (http://www.apache.org/).
>
> Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt
> URL:
> http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
>
> ==
> --- tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt (original)
> +++ tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt Fri Jan  3
> 18:08:32 2014
> @@ -1,5 +1,5 @@
>  Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library
> Distributions
> -Copyright 2004-2012 The Apache Software Foundation
> +Copyright 2004-2014 The Apache Software Foundation
>
> -This product includes software developed by
> +This product includes software developed at
>  The Apache Software Foundation (http://www.apache.org/).
>
> Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt
> URL:
> http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
>
> ==
> --- tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt (original)
> +++ tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt Fri Jan  3
> 18:08:32 2014
> @@ -1,5 +1,5 @@
>  Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library
> Examples Application
> -Copyright 2004-2012 The Apache Software Foundation
> +Copyright 2004-2014 The Apache Software Foundation
>
> -This product includes software developed by
> +This product includes software developed at
>  The Apache Software Foundation (http://www.apache.org/).
>
> Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt
> URL:
> http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
>
> ==
> --- tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt (original)
> +++ tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt Fri Jan  3 18:08:32
> 2014
> @@ -1,5 +1,5 @@
>  Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library
> -Copyright 2004-2012 The Apache Software Foundation
> +Copyright 2004-2014 The Apache Software Foundation
>
> -This product includes software developed by
> +This product includes software developed at
>  The Apache Software Foundation (http://www.apache.org/).
>
> Modified: tomcat/taglibs/site/NOTICE.txt
> URL:
> http://svn.apache.org/viewvc/tomcat/taglibs/site/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
>
> ==
> --- tomcat/taglibs/site/NOTICE.txt (original)
> +++ tomcat/taglibs/site/NOTICE.txt Fri Jan  3 18:08:32 2014
> @@ -1,5 +1,5 @@
>  Apache Jakarta Taglib Website
> -Copyright 2009-2012 The Apache Software Foundatio

Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/

[Henri Yandell]

On Saturday, January 11, 2014, Konstantin Kolinko wrote:

> 2014/1/12 Henri Yandell >:
> > Shouldn't be changing the copyright date until we actually make a
> > copyrightable modification to that product.
> >
>
> I think this itself is one,  as it fixes typos in the NOTICE files.
>
>
That's not a copyrightable change :)


> Best regards,
> Konstantin Kolinko
>
> > On Fri, Jan 3, 2014 at 10:08 AM,  wrote:
> >
> >> Author: rjung
> >> Date: Fri Jan  3 18:08:32 2014
> >> New Revision: 1555177
> >>
> >> URL: http://svn.apache.org/r1555177
> >> Log:
> >> Happy new 2014!
> >>
> >> Modified:
> >> tomcat/taglibs/extended/trunk/NOTICE.txt
> >> tomcat/taglibs/rdc/trunk/NOTICE.txt
> >> tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt
> >> tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt
> >> tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt
> >> tomcat/taglibs/site/NOTICE.txt
> >> tomcat/taglibs/standard/trunk/NOTICE
> >> tomcat/taglibs/taglibs-parent/trunk/NOTICE
> >>
> >> Modified: tomcat/taglibs/extended/trunk/NOTICE.txt
> >> URL:
> >>
> http://svn.apache.org/viewvc/tomcat/taglibs/extended/trunk/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
> >>
> >>
> ==
> >> --- tomcat/taglibs/extended/trunk/NOTICE.txt (original)
> >> +++ tomcat/taglibs/extended/trunk/NOTICE.txt Fri Jan  3 18:08:32 2014
> >> @@ -1,5 +1,5 @@
> >>  Apache Extended Taglib
> >> -Copyright 2009-2012 The Apache Software Foundation
> >> +Copyright 2009-2014 The Apache Software Foundation
> >>
> >> -This product includes software developed by
> >> +This product includes software developed at
> >>  The Apache Software Foundation (http://www.apache.org/).
> >>
> >> Modified: tomcat/taglibs/rdc/trunk/NOTICE.txt
> >> URL:
> >>
> http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
> >>
> >>
> ==
> >> --- tomcat/taglibs/rdc/trunk/NOTICE.txt (original)
> >> +++ tomcat/taglibs/rdc/trunk/NOTICE.txt Fri Jan  3 18:08:32 2014
> >> @@ -1,5 +1,5 @@
> >>  Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library
> >> -Copyright 2004-2012 The Apache Software Foundation
> >> +Copyright 2004-2014 The Apache Software Foundation
> >>
> >> -This product includes software developed by
> >> +This product includes software developed at
> >>  The Apache Software Foundation (http://www.apache.org/).
> >>
> >> Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt
> >> URL:
> >>
> http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff
> >>
> >>
> ==
> >> --- tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt (original)
> >> +++ tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt Fri Jan  3
> >> 18:08:32 2014
> >> @@ -1,5 +1,5 @@
> >>  Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library
> >> Distributions
> >> -Copyright 2004-2012 The Apache Software Foundation
> >> +Copyright 2004-2014 The Apache Software Foundation
> >>
> >> -This product includes software developed by
> >> +This product includes software developed at
> >>  The Apache Software Foundation (http://www.apache.org/).
> >>
> >> Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt
> >> URL:
> >>
> <http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt?rev=1555177&r1=1555176&r2=1555177&view=diff>

Re: Taglib Site Update

[Henri Yandell]

Thanks. Wish I'd looked here before digging myself. I assumed it was
something weird I did when moving over from Jakarta and spent far too much
time digging into the old code there :)

---

I've gone ahead and put that file back in, but in the overall Taglibs site.
I'm not convinced we need a separate Maven generated site. A single file,
and copy the apidocs over from the taglib itself.

I'm also going to dump the link to CI (not working), test javadoc (dull)
and the link to the wiki (not there). The main loss in ditching the
separate Maven site are any items of value in the project reports at
http://tomcat.apache.org/taglibs/standard/project-info.html. Most are noise
or duplicates. Primarily we lack a page showing where to get the source.

Remaining tasks:

* Create a page to show source location.
* Create a .cgi page for download mirrors *I hope that's gotten easier*
* Change urls to point to mirror rather than archive
* Push content into tomcat-site/taglibs manually
* Change the news item on Tomcat itself to announce the release

Hen



On Sat, Jan 11, 2014 at 3:52 PM, Konstantin Kolinko
wrote:

> 2014/1/12 Henri Yandell :
> > Started digging into this last night. New computer so checkout, figure
> out
> > right version of Maven etc. 3.1.1 has issues with the site, so you have
> to
> > stay on 3.0.5.
> >
> > I've made some initial changes, then discovered that we seem to have lost
> > the xdoc for the website (one file) for the standard subcomponent. So my
> > task tonight is to hunt that page down in the svn history and bring it
> > back.
>
> https://svn.apache.org/r1540559
> ?
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Taglib Site Update

[Henri Yandell]

On Sun, Jan 12, 2014 at 8:52 AM, Jeremy Boynes  wrote:

> On Jan 11, 2014, at 10:58 PM, Henri Yandell  wrote:
>
> > Thanks. Wish I'd looked here before digging myself. I assumed it was
> > something weird I did when moving over from Jakarta and spent far too
> much
> > time digging into the old code there :)
> >
> > ---
> >
> > I've gone ahead and put that file back in, but in the overall Taglibs
> site.
> > I'm not convinced we need a separate Maven generated site. A single file,
> > and copy the apidocs over from the taglib itself.
> >
> > I'm also going to dump the link to CI (not working), test javadoc (dull)
> > and the link to the wiki (not there). The main loss in ditching the
> > separate Maven site are any items of value in the project reports at
> > http://tomcat.apache.org/taglibs/standard/project-info.html. Most are
> noise
> > or duplicates. Primarily we lack a page showing where to get the source.
> >
> > Remaining tasks:
> >
> > * Create a page to show source location.
> > * Create a .cgi page for download mirrors *I hope that's gotten easier*
> > * Change urls to point to mirror rather than archive
> > * Push content into tomcat-site/taglibs manually
> > * Change the news item on Tomcat itself to announce the release
>
> Is this all in taglibs/site?
> I’d like to add a page with docs on how to use the libraries as that has
> changed in this version (basically a web copy of the README for the binary).
>

Yup - taglibs/site/src/site/xdoc/standard/.xml.

Hen

Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/

[Henri Yandell]

On Sun, Jan 12, 2014 at 3:39 AM, Rainer Jung wrote:

> Hi Henri,
>
> On 11.01.2014 22:15, Henri Yandell wrote:
> > Shouldn't be changing the copyright date until we actually make a
> > copyrightable modification to that product.
>
> Not sure whether the "until we actually make a copyrightable
> modification" part is required. The various site pages about the NOTICE
> file don't clarify it. The best I could find was
>
> http://www.apache.org/legal/src-headers.html
>
> "The top of each NOTICE file should include the following text, suitably
> modified to reflect the product name and year(s) of distribution of the
> current and past versions of the product:".
>
> Then there's the legal issue (still open)
>
> https://issues.apache.org/jira/browse/LEGAL-51
>
> in which you participated and finally a reference to
>
> http://www.oppedahl.com/copyrights/#notice
>
> Most of the discussion seems to be about using only one year or a range,
> and if only one year whether the first year or the current publication
> year. The legal texts cited do not contain the terminology "version" for
> software and thus it seems unclear how to apply them.
>
> Concerning the point in time when to adopt the year (if at all): I got
> the impression the whole discussion is only about a release. As long as
> the files are only in svn the correct copyright handling is not of big
> importance. Now if it is acceptable at the time of a release to use the
> copyright notice of the form FirstYear-CurrentYear, then I think it is
> fine and helpful to adjust the NOTICE line at the start of a year to
> prevent forgetting the adjustment at the time of release. That was my
> motivation.
>
> Of course in the light of LEGAL-51 it might be that the whole adjustment
> of Copyright year in unnecessary at all - but the issue is not finally
> decided - and it also might be that some future release does not contain
> any copyrightable change. I would prefer the risk of using the wrong
> (newer) copyright year in this very unlikely case instead of the risk of
> forgetting to update NOTICE during the release process. But that's of
> course a very personal view. Since I never contributed to taglibs I am
> very unfamiliar to the project specific policies and would be fine to
> revert if you would prefer that.


My main concern is it makes inactive codebases seem alive. ie) extended
looks as though there's been code change in the last 5 years instead of
only having had code in it in 2009. Similar with RDC.

Other than that, I think it's mainly pedantry :) 80 years is so far off
that I don't see anyone caring that the copyright to a piece of code here
just expired, especially given our licence. It also seems unlikely that
there would be any gain in having stated a copyright year as being later
than it was; again given our license.

Hen

Re: Taglib Site Update

[Henri Yandell]

>
>
> On Jan 11, 2014, at 10:58 PM, Henri Yandell  wrote:
>>
>> > Remaining tasks:
>> >
>> > * Create a page to show source location.
>> > * Create a .cgi page for download mirrors *I hope that's gotten easier*
>> > * Change urls to point to mirror rather than archive
>> > * Push content into tomcat-site/taglibs manually
>> > * Change the news item on Tomcat itself to announce the release
>>
>
*http://tomcat.apache.org/download-taglibs.cgi
<http://tomcat.apache.org/download-taglibs.cgi>* now exists.

Jeremy - could you upload your public sig to a KEYS file at:

https://www.apache.org/dist/tomcat/taglibs/KEYS

It seems there's a trunk/KEYS for all Tomcat RMs, but also specific KEYS
files per downloaded product. I'm not sure of the right way to put files in
dist.apache.org nowadays, but I figure you would have hit it during release
:)

Hen

Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/

[Henri Yandell]

On Sun, Jan 12, 2014 at 9:16 PM, Henri Yandell  wrote:

>
>
> My main concern is it makes inactive codebases seem alive. ie) extended
> looks as though there's been code change in the last 5 years instead of
> only having had code in it in 2009. Similar with RDC.
>
>
On this topic, I've pinged Rahul offline to get his thoughts on retiring
RDC to the Attic. I'm assuming he's not tracking the dev list.

Hen

[Taglibs] Extended?

[Henri Yandell]

Any thoughts Jeremy on our containing tags outside of the Standard
implementation?

I was pondering folding the Extended one (which contains two very tiny
tags) into the Standard taglib, or if you don't see any likelihood for
adding new ones, just removing it.

Hen

Re: [Taglibs] Extended?

[Henri Yandell]

+1 to that vision.

I'll ditch the current Extended code.

Hen


On Tue, Jan 14, 2014 at 8:47 AM, Jeremy Boynes  wrote:

> On Jan 13, 2014, at 9:51 PM, Henri Yandell  wrote:
>
> > Any thoughts Jeremy on our containing tags outside of the Standard
> > implementation?
> >
> > I was pondering folding the Extended one (which contains two very tiny
> > tags) into the Standard taglib, or if you don't see any likelihood for
> > adding new ones, just removing it.
>
> If anything, I think I would rather go in the other direction, breaking
> Standard down into individual taglibs. I think there are a number of users
> who primarily rely only on core & fn in their applications, using other
> libraries for the functionality in fmt, sql, and xml. It would be nice to
> be able to consume them that way. Splitting them up would also allow
> specific libraries to be optimized through tag plugins or by Jasper itself.
>
> Those other libraries have also not really kept up with the times. For
> example, fmt is heavily coupled to native Java L10N which I think still
> lags behind icu4j and hasn’t added basics like named placeholders, sql has
> been superseded by frameworks like JPA but even the basic JDBC support
> could take advantage of “new" things like @Resource injection, and we’ve
> added a hard dependency on Xalan to address xml performance and the spec
> still hasn’t touched new features like XPath 2 or XQuery.
>
> “Extended” is a vague name so I would be in favor of just dropping it and
> replacing it with more specific libraries e.g. localization, xpath, json or
> whatever we decide to work on.
>
> Cheers
> Jeremy
>
>

Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/

[Henri Yandell]

Per the below, I'll go ahead and move RDC to the Attic; waiting 72 hours in
case there's a -1.

Hen


On Tue, Jan 14, 2014 at 4:23 PM, Rahul Akolkar wrote:

> On Tue, Jan 14, 2014 at 12:49 AM, Henri Yandell 
> wrote:
> >
> > On Sun, Jan 12, 2014 at 9:16 PM, Henri Yandell 
> wrote:
> >
> > > My main concern is it makes inactive codebases seem alive. ie) extended
> > > looks as though there's been code change in the last 5 years instead of
> > > only having had code in it in 2009. Similar with RDC.
> > >
> > >
> > On this topic, I've pinged Rahul offline to get his thoughts on retiring
> > RDC to the Attic. I'm assuming he's not tracking the dev list.
> >
> 
>
> I'm here, but no dev cycles for RDC at the moment or in the near
> future. So, attic sounds right.
>
> -Rahul
>
>

[PMC] KEYS copying [Was: Taglib Site Update]

[Henri Yandell]

Could someone on the PMC copy Jeremy's entry at the end of the KEYS file
located here:

https://svn.apache.org/repos/asf/tomcat/trunk/KEYS

to here?

https://www.apache.org/dist/tomcat/taglibs/KEYS

Thanks :)

Hen

On Mon, Jan 13, 2014 at 6:58 AM, Jeremy Boynes  wrote:

> On Jan 12, 2014, at 10:56 PM, Henri Yandell  wrote:
>
> >>
> >>
> >> On Jan 11, 2014, at 10:58 PM, Henri Yandell  wrote:
> >>>
> >>>> Remaining tasks:
> >>>>
> >>>> * Create a page to show source location.
> >>>> * Create a .cgi page for download mirrors *I hope that's gotten
> easier*
> >>>> * Change urls to point to mirror rather than archive
> >>>> * Push content into tomcat-site/taglibs manually
> >>>> * Change the news item on Tomcat itself to announce the release
> >>>
> >>
> > *http://tomcat.apache.org/download-taglibs.cgi
> > <http://tomcat.apache.org/download-taglibs.cgi>* now exists.
> >
> > Jeremy - could you upload your public sig to a KEYS file at:
> >
> > https://www.apache.org/dist/tomcat/taglibs/KEYS
> >
> > It seems there's a trunk/KEYS for all Tomcat RMs, but also specific KEYS
> > files per downloaded product. I'm not sure of the right way to put files
> in
> > dist.apache.org nowadays, but I figure you would have hit it during
> release
> > :)
>
> I don’t think I can - access to the release tree is limited to PMC
> members. I have added my key here:
>   https://svn.apache.org/repos/asf/tomcat/trunk/KEYS
> if someone can copy it.
>
> Thanks
> Jeremy
>
>

[Taglibs] Site updated; ready for announce.

[Henri Yandell]

I've updated the site to point to the 1.2.1 release. It's a bit of a kludge
right now. Once RDC heads in the direction of the Attic, I'd like to move
the site fully into the tomcat-site directory, avoiding any of the
generated Maven noise. Then the only oddity is copying the javadoc in.

Jeremy - would you like to do the honours and send the announcement email
to users@tomcat and to annou...@apache.org?

Hen

Re: Removal of author tags in trunk

[Henri Yandell]

On Fri, Jan 24, 2014 at 11:35 PM, Mladen Turk  wrote:

> On 01/24/2014 07:51 PM, Rainer Jung wrote:
>
>> On 24.01.2014 17:24, Mladen Turk wrote:
>>
>>> On 01/24/2014 03:14 PM, Mark Thomas wrote:
>>>

 If you have are for *your* @author tags to be removed from trunk, reply
 here and I'll make the changes.


>>> Remove either all or none.
>>>
>>
>> - there's to many authors we won't reach
>>
>
> Yes, that was my point. We can all decide to remove our
> individual @author tag, but those folks we cannot reach will
> eventually stay as the sole authors of the given code.
>
>
>  - anyone is free to remove his own author tags
>>
>
> Is there anything that prevents us to decide to remove
> all @authors tags from our entire codebase?
> AFAICT most of the people are fine with removing their tags, so
> in case we can do that, I see no reason to go trough individual process.
>
>
>
I don't see why we can't remove all. Put them into a file as the
contributors (pom.xml?) and remove from the source. A lot of Commons
libraries did that 5+ years back and there's been no backlash.

It's not like they're Copyright statements.

Hen

Re: Time for Taglibs to be sent to the archive?

[Henri Yandell]

Should we have a formal vote Mark?

Hen

On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes  wrote:
> +0
>
> It's perhaps not surprising that there is not much activity as there has been 
> no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 
> TCK and could be released if someone had the energy to fix the website and 
> rustle up votes.
>
> On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote:
>
>> Hard to argue against it. I've no energy for Taglibs coding. I wish
>> we'd got a JSTL 1.2 released, but c'est la vie.
>>
>> All the steps listed sound good except removing the website.
>> Historically on the Attic side we've kept the websites up with a
>> notice that the project is dead, rather than going dark on people.
>>
>> Hen
>>
>> On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez  wrote:
>>> If there is no activity, it make sense.
>>>
>>> +0
>>>
>>> 2012/10/1 Mark Thomas :
>>>> In the two+ years since Taglibs moved to the Tomcat project there have
>>>> been a few short bursts of activity totalling just over 200 commits but
>>>> no releases. There has also been no progress towards a migration to
>>>> svnpubsub for the taglibs part of the web site.
>>>>
>>>> Given the lack of progress I would propose that Taglibs is moved to our
>>>> archive. This would mean:
>>>>
>>>> - removing the Taglibs link from tomcat.a.o
>>>> - removing the Taglibs web pages
>>>> - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs
>>>> - making the Taglibs BZ project read-only
>>>> - moving the Taglibs committers to emeritus status
>>>> - removing the Taglibs from Gump
>>>>
>>>> There is nothing to remove from dist.a.o since there have been no releases
>>>>
>>>> Note: This is intended as a discussion topic - not a formal proposal/vote.
>>>>
>>>> Thoughts?
>>>>
>>>> Mark
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Time for Taglibs to be sent to the archive?

[Henri Yandell]

What exactly is left to do the release? Not having a permissively
licensed JSTL 1.2 is a shame when the code is there. Even if we put it
in the Attic, I'd love to say "And here is a 1.2 compliant version,
good luck" rather than "sorry, get it from SVN".

I'd be happy to put in the effort to do the votes/website. I'd need to
hit the site anyway as a part of sending it to the Attic.

Is it 100% good on the TCK, nothing more needed?

Hen

On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes  wrote:
> +0
>
> It's perhaps not surprising that there is not much activity as there has been 
> no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 
> TCK and could be released if someone had the energy to fix the website and 
> rustle up votes.
>
> On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote:
>
>> Hard to argue against it. I've no energy for Taglibs coding. I wish
>> we'd got a JSTL 1.2 released, but c'est la vie.
>>
>> All the steps listed sound good except removing the website.
>> Historically on the Attic side we've kept the websites up with a
>> notice that the project is dead, rather than going dark on people.
>>
>> Hen
>>
>> On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez  wrote:
>>> If there is no activity, it make sense.
>>>
>>> +0
>>>
>>> 2012/10/1 Mark Thomas :
>>>> In the two+ years since Taglibs moved to the Tomcat project there have
>>>> been a few short bursts of activity totalling just over 200 commits but
>>>> no releases. There has also been no progress towards a migration to
>>>> svnpubsub for the taglibs part of the web site.
>>>>
>>>> Given the lack of progress I would propose that Taglibs is moved to our
>>>> archive. This would mean:
>>>>
>>>> - removing the Taglibs link from tomcat.a.o
>>>> - removing the Taglibs web pages
>>>> - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs
>>>> - making the Taglibs BZ project read-only
>>>> - moving the Taglibs committers to emeritus status
>>>> - removing the Taglibs from Gump
>>>>
>>>> There is nothing to remove from dist.a.o since there have been no releases
>>>>
>>>> Note: This is intended as a discussion topic - not a formal proposal/vote.
>>>>
>>>> Thoughts?
>>>>
>>>> Mark
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Time for Taglibs to be sent to the archive?

[Henri Yandell]

Do we have to do any bureaucratize to register as having passed the TCK?

Or is it:

* Generate release artifacts.
* VOTE on release.
* VOTE on Attic.
* Publish.
* Make project read-only.

Hen

On Mon, Dec 31, 2012 at 3:11 PM, Henri Yandell  wrote:
> What exactly is left to do the release? Not having a permissively
> licensed JSTL 1.2 is a shame when the code is there. Even if we put it
> in the Attic, I'd love to say "And here is a 1.2 compliant version,
> good luck" rather than "sorry, get it from SVN".
>
> I'd be happy to put in the effort to do the votes/website. I'd need to
> hit the site anyway as a part of sending it to the Attic.
>
> Is it 100% good on the TCK, nothing more needed?
>
> Hen
>
> On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes  wrote:
>> +0
>>
>> It's perhaps not surprising that there is not much activity as there has 
>> been no update to the JSR in many years. The JSTL code in trunk does pass 
>> the 1.2 TCK and could be released if someone had the energy to fix the 
>> website and rustle up votes.
>>
>> On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote:
>>
>>> Hard to argue against it. I've no energy for Taglibs coding. I wish
>>> we'd got a JSTL 1.2 released, but c'est la vie.
>>>
>>> All the steps listed sound good except removing the website.
>>> Historically on the Attic side we've kept the websites up with a
>>> notice that the project is dead, rather than going dark on people.
>>>
>>> Hen
>>>
>>> On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez  wrote:
>>>> If there is no activity, it make sense.
>>>>
>>>> +0
>>>>
>>>> 2012/10/1 Mark Thomas :
>>>>> In the two+ years since Taglibs moved to the Tomcat project there have
>>>>> been a few short bursts of activity totalling just over 200 commits but
>>>>> no releases. There has also been no progress towards a migration to
>>>>> svnpubsub for the taglibs part of the web site.
>>>>>
>>>>> Given the lack of progress I would propose that Taglibs is moved to our
>>>>> archive. This would mean:
>>>>>
>>>>> - removing the Taglibs link from tomcat.a.o
>>>>> - removing the Taglibs web pages
>>>>> - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs
>>>>> - making the Taglibs BZ project read-only
>>>>> - moving the Taglibs committers to emeritus status
>>>>> - removing the Taglibs from Gump
>>>>>
>>>>> There is nothing to remove from dist.a.o since there have been no releases
>>>>>
>>>>> Note: This is intended as a discussion topic - not a formal proposal/vote.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Mark
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Time for Taglibs to be sent to the archive?

[Henri Yandell]

On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes  wrote:
> On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote:
>> Regarding the two taglibs that are not yet in the attic, I have no
>> interest in "RDC" taglib, but I am interested in JSTL one.
>
> +1
>
>>
>> I think once we make the first release, things should go easier after that.
>>
>> A few notes after quick review of the sources:
>>
>> 1. Can we go up from Java 5 and require/use at least Java 6 to build
>> the project?
>>
>> I am even OK to be brave and go up to Java 7.
>>
>> I do not like Java 5, because
>> a) It is outdated.
>> It would be strange for a "new" project to use that if we are going
>> to support it for long.
>> b) It is not opensource.
>> OpenJDK is since Java 6.
>>
>> The version of Java is important for this class, that implements
>> javax.sql.DataSource:
>>
>> \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java
>>
>> Java 7 will allow us to support a later version of JDBC and will allow
>> this project to build on Gump.
>
> There is also an issue with the I18N tags taking a long time to start on a 
> Java6 platform due to changes in the way Locales are located by the JRE. I 
> remember some discussion on fixing this but a requirement to stay on Java 5 
> meant having to build two implementations and switch between them which I'd 
> planned to do once a release was out. If we pre-req 6 or 7 then the 
> implementation can just be updated and this issue closed easier.

Would the TCK pass if it was on Java 7?

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Time for Taglibs to be sent to the archive?

[Henri Yandell]

On Mon, Jan 28, 2013 at 3:46 AM, Mark Thomas  wrote:
> On 26/01/2013 21:51, Henri Yandell wrote:
>> On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes  wrote:
>>> On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote:
>>>> Regarding the two taglibs that are not yet in the attic, I have no
>>>> interest in "RDC" taglib, but I am interested in JSTL one.
>>>
>>> +1
>>>
>>>>
>>>> I think once we make the first release, things should go easier after that.
>>>>
>>>> A few notes after quick review of the sources:
>>>>
>>>> 1. Can we go up from Java 5 and require/use at least Java 6 to build
>>>> the project?
>>>>
>>>> I am even OK to be brave and go up to Java 7.
>>>>
>>>> I do not like Java 5, because
>>>> a) It is outdated.
>>>> It would be strange for a "new" project to use that if we are going
>>>> to support it for long.
>>>> b) It is not opensource.
>>>> OpenJDK is since Java 6.
>>>>
>>>> The version of Java is important for this class, that implements
>>>> javax.sql.DataSource:
>>>>
>>>> \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java
>>>>
>>>> Java 7 will allow us to support a later version of JDBC and will allow
>>>> this project to build on Gump.
>>>
>>> There is also an issue with the I18N tags taking a long time to start on a 
>>> Java6 platform due to changes in the way Locales are located by the JRE. I 
>>> remember some discussion on fixing this but a requirement to stay on Java 5 
>>> meant having to build two implementations and switch between them which I'd 
>>> planned to do once a release was out. If we pre-req 6 or 7 then the 
>>> implementation can just be updated and this issue closed easier.
>>
>> Would the TCK pass if it was on Java 7?
>
> We are talking about Taglibs 1.2 right? (If not adjust versions below
> accordingly).
>
> Taglibs 1.2 requires JSP 2.1.
>
> JSP 2.1 requires Java 5 or later (as does Servlet 2.5 and J2EE 5).
>
> Based on that, I would say that the TCK has to pass when running on Java 5.
>
> /me goes looking for some TCK docs
>
> I've just checked the latest version of the TCK documentation for JSTL
> 1.2 and while the TCK has been updated so it will run on Java 7, the
> reference runtime remains Java 5. My interpretation of that is that the
> TCK must pass when running with a Java 5 JRE.

We could use the Tomcat trick though. if("passTCKFlag") then do the
no-one-wants option. Then by default it could run smoothly on JDK 7.

I've vague memories that the SQL side of things makes that painful.
Did you look at that Jeremy?

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[taglibs] Building Standard

[Henri Yandell]

Coming back to this after a while :)

Does anyone else get errors when trying to build standard regarding
LocaleUtils?


/Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseDateTag.java:[25,49]
cannot find symbol
symbol  : class LocaleUtil
location: package org.apache.taglibs.standard.tag.common.fmt

/Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseNumberTag.java:[25,49]
cannot find symbol
symbol  : class LocaleUtil
location: package org.apache.taglibs.standard.tag.common.fmt

/Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseDateTag.java:[194,28]
cannot find symbol
symbol  : variable LocaleUtil
location: class org.apache.taglibs.standard.tag.el.fmt.ParseDateTag

/Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseNumberTag.java:[164,28]
cannot find symbol
symbol  : variable LocaleUtil
location: class org.apache.taglibs.standard.tag.el.fmt.ParseNumberTag

?

Re: [taglibs] Building Standard

[Henri Yandell]

Figured out. I was using mvn package rather than mvn install.

Too used to simple dependency structures over in Commons.

Hen

On Fri, Jun 21, 2013 at 7:51 AM, Henri Yandell  wrote:

>
> Coming back to this after a while :)
>
> Does anyone else get errors when trying to build standard regarding
> LocaleUtils?
>
>
> /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseDateTag.java:[25,49]
> cannot find symbol
> symbol  : class LocaleUtil
> location: package org.apache.taglibs.standard.tag.common.fmt
>
> /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseNumberTag.java:[25,49]
> cannot find symbol
> symbol  : class LocaleUtil
> location: package org.apache.taglibs.standard.tag.common.fmt
>
> /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseDateTag.java:[194,28]
> cannot find symbol
> symbol  : variable LocaleUtil
> location: class org.apache.taglibs.standard.tag.el.fmt.ParseDateTag
>
> /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseNumberTag.java:[164,28]
> cannot find symbol
> symbol  : variable LocaleUtil
> location: class org.apache.taglibs.standard.tag.el.fmt.ParseNumberTag
>
> ?
>

[taglibs] Site plans

[Henri Yandell]

FYI that I'm digging into the Taglibs site to figure out how it is we go
from 15 Maven target/site directories to 1 site.

I'm then going to write a dumb shell script that copies the relevant parts
to a Tomcat site/taglibs checkout, allowing for the site to be updated. I'm
sure there's a very clever Maven plugin that can take care of this and
handle the logic of the 15 maven projects becoming 1 site, but I'd rather
build Lego :)

Hen

Re: [taglibs] Site plans

[Henri Yandell]

Help much appreciated - but do we want all the content of all the modules
to be there?

It feels to me that the website does not map directly to the codebase. We
want an overall site, and subsites for Standard and for RDC. We don't want
to have the 14 pom.xmls become a site structure, or the 4 pom.xmls
(tld-generator and extended).

Hen

On Mon, Jun 24, 2013 at 5:23 AM, Olivier Lamy  wrote:

> Hi,
> Can be easy :-)
> mvn site site:stage and all the content of all modules will be in
> ${project.build.directory}/staging (target/staging).
> But to achieve this and having something easy we must the site module
> on the top!
> Means here http://svn.apache.org/repos/asf/tomcat/taglibs/trunks/
> As we don't release the site (that doesn't shok me :-) ).
> With this tree deploying the site will be as easy as: mvn clean site
> site:stage && mvn scm-publish:publish-scm
>
> Make sense ?
> I can work on that or help you if you want.
>
>
>
>
> 2013/6/24 Henri Yandell :
> > FYI that I'm digging into the Taglibs site to figure out how it is we go
> > from 15 Maven target/site directories to 1 site.
> >
> > I'm then going to write a dumb shell script that copies the relevant
> parts
> > to a Tomcat site/taglibs checkout, allowing for the site to be updated.
> I'm
> > sure there's a very clever Maven plugin that can take care of this and
> > handle the logic of the 15 maven projects becoming 1 site, but I'd rather
> > build Lego :)
> >
> > Hen
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [taglibs] Site plans

[Henri Yandell]

On Mon, Jul 1, 2013 at 3:04 AM, Olivier Lamy  wrote:

> Apologize for delayed response.
>
> 2013/6/26 Jeremy Boynes :
> > On Jun 25, 2013, at 7:54 AM, Henri Yandell  wrote:
> >
> >> Help much appreciated - but do we want all the content of all the
> modules
> >> to be there?
> >>
> >> It feels to me that the website does not map directly to the codebase.
> We
> >> want an overall site, and subsites for Standard and for RDC. We don't
> want
> >> to have the 14 pom.xmls become a site structure, or the 4 pom.xmls
> >> (tld-generator and extended).
> >
> > Three mini-sites sounds good: a top-level one holding things together
> and then sub-sites for standard and RDC. Is there a way to associate the
> top-level one with the parent POM and the others with the "root" poms in
> standard and rdc? That would match with the things that are likely to be
> released (being all "standard" packages together, or all "rdc" packages
> together, but not both at the same time). Do we still need an aggregator
> pom as well - how about setting up separate CI jobs for "standard" and
> "rdc"?
> >
>
> Coud be possible but do you want to deploy sites from tagged modules
> versions ? (I presume yes).
> In such case that will changed a bit as all modules will be in a
> different svn path.
>


Apologies for no change on this - I've spent the week with flu.

I wouldn't expect to deploy the site from tags - a site is a live/current
thing.

Hen

Re: [taglibs] Site plans

[Henri Yandell]

On Tue, Jul 2, 2013 at 8:43 PM, Jeremy Boynes  wrote:

> On Jul 2, 2013, at 9:41 AM, Henri Yandell  wrote:
> >
> > I wouldn't expect to deploy the site from tags - a site is a live/current
> > thing.
>
> The core site is a live/current thing, but there is also the
> documentation/reports etc. that would be associated with a specific tag.
> IOW, the site could contain the JavaDoc for 1.1.2, 1.2.0, and 1.2.1 etc.
> That would suggest 1+N parts as Olivier suggests, one for the live site and
> one generated from each tag.
>
>
Fair enough, but why build it from the tag? It's easy enough to use svn cp
to put it in place once and then leave it there rather than keep building
something that shouldn't be changing.

Hen

Re: [VOTE] Release Apache Taglibs 1.2.0-RC1

[Henri Yandell]

Slowly digging into this. Thus far I've confirmed the source builds :)

Next up is working out how to deploy the examples.

Hen

On Fri, Aug 2, 2013 at 12:32 PM, Jeremy Boynes  wrote:

> A proposed release candidate Apache Taglibs 1.2.0-RC1 is now available for
> voting.
>
> This is release candidate for an implementation of JSTL 1.2 and can be
> obtained from the staging repo at:
>   https://repository.apache.org/content/repositories/orgapachetomcat-053/
>
> The source distribution can be obtained from:
>
> https://repository.apache.org/content/repositories/orgapachetomcat-053/org/apache/taglibs/taglibs-standard/1.2.0-RC1/
>
> The proposed 1.2.0-RC1 candidate is:
> [ ] Broken - do not release
> [ ] Alpha - can be released as 1.2.0-RC1 alpha
>
> This is the first release in a long time, and the first since switching to
> Maven. If there are issues, please list all concerns so they can be
> addressed.
>
> Thanks
> Jeremy
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[taglibs] Examples

[Henri Yandell]

To test out Jeremy's proposed alpha Standard 1.2 release I needed some code
to run against it. I turned to the old examples that at some point were
used to verify things (the standard/examples directory).

Surprisingly, I've got them up and running. I build with mvn package then
copy the war to a Tomcat 7 to be deployed. A few examples error - I suspect
because of either issues in setup or because later servlet/jsp/jstl specs
made what they're doing illegal.

I'll aim to go through them tomorrow and list the ones that appear to be
problematic.

Hen

Re: [taglibs] Examples and doc

[Henri Yandell]

+1 to both.

On Friday, August 9, 2013, Jeremy Boynes wrote:

> On Aug 6, 2013, at 10:13 PM, Henri Yandell >
> wrote:
>
> > Slowly digging into this. Thus far I've confirmed the source builds :)
> >
> > Next up is working out how to deploy the examples.
>
> Wondering here if it would be better to release the examples separately as
> they can be decoupled.
> IOW, we would expect the example code not to change wiht releases of the
> main libraries, and vice versa.
>
> Also, how about dropping the "doc" directory and rolling the content into
> the website?
>
> -
> Jeremy
>
>

Re: [taglibs] Examples and doc

[Henri Yandell]

Shall we move the examples up to tomcat/taglibs/standard-examples/trunk?


On Fri, Aug 23, 2013 at 2:37 PM, Henri Yandell  wrote:

> +1 to both.
>
>
> On Friday, August 9, 2013, Jeremy Boynes wrote:
>
>> On Aug 6, 2013, at 10:13 PM, Henri Yandell  wrote:
>>
>> > Slowly digging into this. Thus far I've confirmed the source builds :)
>> >
>> > Next up is working out how to deploy the examples.
>>
>> Wondering here if it would be better to release the examples separately
>> as they can be decoupled.
>> IOW, we would expect the example code not to change wiht releases of the
>> main libraries, and vice versa.
>>
>> Also, how about dropping the "doc" directory and rolling the content into
>> the website?
>>
>> -
>> Jeremy
>>
>>

Re: [taglibs] Examples

[Henri Yandell]

Tomorrow takes time apparently :)

Here's my current status:

General Purpose Tags - PASSED
Conditional Tags - PASSED
Iterator Tags - PASSED
Import Tags
I18N & Formatting Tags
XML Tags
SQL Tags
Functions - PASSED
Tag Library Validators

Hen


On Tue, Aug 6, 2013 at 11:16 PM, Henri Yandell  wrote:

> To test out Jeremy's proposed alpha Standard 1.2 release I needed some
> code to run against it. I turned to the old examples that at some point
> were used to verify things (the standard/examples directory).
>
> Surprisingly, I've got them up and running. I build with mvn package then
> copy the war to a Tomcat 7 to be deployed. A few examples error - I suspect
> because of either issues in setup or because later servlet/jsp/jstl specs
> made what they're doing illegal.
>
> I'll aim to go through them tomorrow and list the ones that appear to be
> problematic.
>
> Hen
>