[PROPOSAL] Change to the 3.3 API

[Bill Barker]

I'd like to add a new method (for now called 'preInitCheck') to the API to
be called before the check for calling the init method.  The current
JspInterceptor.requestMap would be split between the new preInitCheck method
(which would handle the compile), and the requestMap (which would register
the servlet).  In light of bug #7654, we may want to have a 'preInitCheck'
and 'postInitCheck', but I'm still not convinced on how important this case
is.

This is a proposal, since there was a consensus to freeze the API.  I'm not
looking for people to help (although volunteers are always welcome), since
the changes are simple enough.  The only known bug that this fixes is the
rather obscure one that currently a JSP page that is accessed from a
NamedDispatcher will not be re-compiled.  More importantly (IMHO), this will
separate the JSP logic from ServletHandler and put it firmly into
JspInterceptor where it belongs.

Of course, I'm expecting that Pier will veto this on the grounds that he
can't be bothered to keep up with the 3.3 development. ;-)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[costinm]

On Sat, 25 May 2002, Pier Fumagalli wrote:

> > If you are a commiter - you have the same rights with all other commiters.
> > If you don't want to exercise some rights - it's your choice.
> 
> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
> only "rights"... It's also "dues", right?

Yes, the 'due' to spend weekends writing code or answering emails or 
reading flame wars. 

Give me a break with the big 'due' to vote or have a say over how the 
project you're involved with. 


Costin 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Pier Fumagalli]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> I do agree ( and I advocated for this a lot ) on lowering ( or
> eliminating) the walls between projects, so jakarta commiters can commit
> code in any jakarta project ( subject to the normal project rules ).
> Some people didn't agree with that even for commons, and I accepted the
> fact. 

Over my dead body.

> If you are a commiter - you have the same rights with all other commiters.
> If you don't want to exercise some rights - it's your choice.

Hola, you tend to forget a part I'm stressing out quite hardly... It's not
only "rights"... It's also "dues", right?

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> On Fri, 24 May 2002, Pier Fumagalli wrote:
> 
>>> If you want my advice - create a sourceforge account, do all the work
>>> on SSI there, and have fun. ( and maybe give access to other
>>> tomcat commiters who are interested to work on SSI ).
>> 
>> Very constructive, Costin, indeed... See my next email (at least I'm trying
>> to propose something)...
> 
> I believe I proposed something as well.

Indeed a very nice contribution... Go and fork our code out somewhere,
kewl... Nice, I like it...

> Sourceforge is an excelent place to write code and have fun.

I don't know, I don't play with them... I have a hard time enough in
maintainig our infrastructure, trying to write a module, and getting a
paycheck every month to feed my cats...

> And you can make the projects as open as you want and have the
> same technical resources ( or more ).

It still hurts that I kicked you out of Nagoya, huh? :)

> There are quite a few projects there that are doing pretty
> well ( JBoss ? ).

I would like to share what actually that community thinks of this community:

http://www.onjava.com/pub/a/onjava/2002/03/20/jboss_interview.html

Nice freaks! :)

> I'm playing with ant-contrib and cpptasks right now, they even have a
> nice community. I think Coyote started as a sf project as well ( Remy ? )
> Same for Cactus, etc.

Why then you don't go and fork your own little Jakarta project at
sourceforge? I'm legally bound to this organization, and I have
responsibilities towards the other members of this community (like trying to
keep those mailing lists going) and frankly I kinda like it, but you're not,
nothing ties you down here... If you go on SourceForge, you can even write
an up-to-latest-version-of-the-spec compliant servlet engine... Loook! :)

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

Bojan Smojver <[EMAIL PROTECTED]> wrote:

> Maybe there should be a committer status review every so often?

I fought that war last year... Ended up being flamed from everywhere because
I'm the big fat hog who doesn't want to see other people around and want to
remove privileges to people.

At the end the war ended with me removing my own committer privileges from
those projects I wasn't contributing to (I'd like to be honest), and getting
two weeks of antidepressants (not)...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml

[billbarker]

billbarker02/05/24 19:34:59

  Modified:catalina/src/conf web.xml
  Log:
  Fix servlet class name.
  
  Revision  ChangesPath
  1.36  +1 -1  jakarta-tomcat-4.0/catalina/src/conf/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- web.xml   24 May 2002 04:44:29 -  1.35
  +++ web.xml   25 May 2002 02:34:58 -  1.36
  @@ -177,7 +177,7 @@
   
   ssi
   
  -  org.apache.catalina.servlets.SsiServlet
  +  org.apache.catalina.servlets.SSIServlet
   
   
 buffered
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Pier Fumagalli]

Henri Yandell <[EMAIL PROTECTED]> wrote:
> 
> +1.
> 
> Another example if I could. The job role of 'Java admin' is growing more
> and more at companies. Developers shouldn't be adminning things, but would
> you have your unix or oracle admin be the admin of the Java side with zero
> Java knowledge?
> 
> Jakarta houses the 'Java' community at Apache but there's no way for a
> Java admin to be a part of that community. Helping other admins, writing
> documentation, being a consumer at the coders. The only way it can happen
> is if they become a coder, and that's contrary to the concept of a Java
> admin.

That's where my career is going to lately, I didn't think about that in the
first place. I'm going to loose my "committer" status soon now that you make
me think about it! :) :) :)

> I think Pier's suggestion will help to grow the 'ownership' of the
> projects and the apache way of thinking to a larger audience.

Thanks...

> Some possible negatives:
> 
> With more non-codery people around, will the 'noise' level in mail lists
> be too high for coders to want to pay attention?
> [It already is getting that way I find. I delete entire threads if the
> first couple of mails are not of interest to me. It has to be retitled as
> with this email to make me realise there was more going on than the
> original mails. ]

That might as well happen, although I don't feel that there will be many in
one of the two categories without being a "committer". Probably a some more
in the "contributor" side of things (because of corporate involvement and
stuff), but not the other way around... But I believe that we shouldn't give
up this option...

> By growing a large community of non-coders, the coders could have less say
> in the product. Is this good/bad? How would the +1/-1 system work. Would
> votes be open to committers only in some instances, and to non-committing
> members only in others. Who votes membership vs committership vs
> contributorship?

Regarding votes, I believe that the votes for a particular codebase should
be open only to contributors only of that particular codebase, and that's it
(I'm not going to vote on Ant for example, or Turbine)... Votes regarding
accepting new codebases, starting new subprojects,  electing the PMC, that
should go only to members, not contributors...

My stance would be that if you start off being a contributor, no question
asked (from that point of view)... Patch contribute, do all you want and
need, you have fun? You want to spend more time on it and Jakarta is not
only something you're paid to work on? Kewl, just ask, could be fairly
automatic, it might as well happen automatically if someone "nominates" you
to do that... I don't think that a vote is even necessary to promote a
committer who wants to be a contributor, talk with someone who can sponsor
you, and I'll be fine...

For the ones who want to start as member, the procedure to become a
committer on one particular projects are already there, as if I wanted to
start giving some patches to (for example) Ant, and get involved with that
codebase...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[costinm]

On Fri, 24 May 2002, Pier Fumagalli wrote:

> > If you want my advice - create a sourceforge account, do all the work
> > on SSI there, and have fun. ( and maybe give access to other
> > tomcat commiters who are interested to work on SSI ).
> 
> Very constructive, Costin, indeed... See my next email (at least I'm trying
> to propose something)...

I believe I proposed something as well. 

Sourceforge is an excelent place to write code and have fun.

And you can make the projects as open as you want and have the 
same technical resources ( or more ).

There are quite a few projects there that are doing pretty
well ( JBoss ? ). I'm playing with ant-contrib and cpptasks
right now, they even have a nice community.

I think Coyote started as a sf project as well ( Remy ? )
Same for Cactus, etc. 

 
Costin







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Bojan Smojver]

On Fri, 2002-05-24 at 21:00, Pier Fumagalli wrote:

> I hate to be the PITA, as always, and I don't have anything against Dan or
> the patches he submitted to SSIServlet, but I believe that this group (as
> noted on the members meeting this Tuesday) is giving away committer
> privileges a little bit too easily...

Perfectly understand your arguments here - I'm one of those 'one patch'
committers. My commits were always driven by selfishness - if something
I use is broken in the TC version I use (3.3.x), then I'll attempt to
fix it. Otherwise, I'll just cruise along. And since TC 3.3.x is so damn
good and stable these days (and does what I want it to do), I just have
no motivation to do anything else.

Maybe there should be a committer status review every so often?

Bojan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[costinm]

On Fri, 24 May 2002, Denis Benoit wrote:

> All that being said, if it would appear preferable to some that my name be
> removed from the CVS commiters list, I would not mind a bit.  I have just

Denis, your contributions so far have been impressive. If anyone wants to
remove your name from the CVS commiter list, he'll have to remove mine first.



Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[costinm]

-1

If someone doesn't want to be involved in the voting - he can do exaclty
that, abstain. If someone doesn't want to support a particular release -
he can abstain from the release vote( or vote +-0 ). 

If you spend time and write code for a project and are willing to
maintain/support - and if the people on the project vote you in, 
you have the same rights as all the other people on that project.


I do agree ( and I advocated for this a lot ) on lowering ( or 
eliminating) the walls between projects, so jakarta commiters can commit 
code in any jakarta project ( subject to the normal project rules ).
Some people didn't agree with that even for commons, and I accepted the
fact. 

If you are a commiter - you have the same rights with all other commiters.
If you don't want to exercise some rights - it's your choice. 



Costin



On Sat, 25 May 2002, Pier Fumagalli wrote:

> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
> 
> So the major topic of discussion is that I perceive a substantial difference
> between being able to commit code to a CVS repository, and being a
> "committer" committer, with all dues and responsibilities that this role
> concerns...
> 
> For example sometimes someone might want to have commit access just because
> he is working for a company that deals with a particular project in Apache
> (we've seen this happening several times with some projects such as Xerces
> and Tomcat), but he really doesn't care about the whole fuzz of Apache and
> stuff, and once the employment contract ends, the relationship with Apache
> terminates as well (I don't need to enumerate all those examples along those
> lines).
> 
> One other example, if we didn't have Henri building RPMs for basically all
> Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
> don't you think that he would deserve committer status even if he's not tied
> to any particular codebase? We had this "problem" in the current election of
> the members, Sally Khudairi: Sally doesn't code, but she was involved with
> the ASF since before it was even created as a press organizer. Does she
> deserve to be a member of the foundation? Even if she doesn't code? Yes she
> does, IMO (and she was elected and nominated a member today)...
> 
> So, IMO, there's a great difference between being a coder, and being a
> member of the Jakarta community, at least in my opinion. There might be
> coders who are not involved with the community, and there might be
> non-coders who are much involved with it, want to participate, are active
> and deserve to be committers...
> 
> Our current structure doesn't "allow" that to happen, both things. If you
> need to write code in a particular source-base, and you need CVS access, you
> are automagically made a committer, even if you don't care about much else,
> and if you're very much involved with the overall project, but not tied to
> ANY whatsoever codebase, and really, don't want / can't do it.
> 
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
> 
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
> 
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
> 
> And redefining the figure of the "committer" as follows:
> 
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
> 
> I believe this makes sense, more sense than what we have now, also because
> we've seen that happening in the ASF for the very first time with a
> non-coding member. Comments please?
> 
> Pier
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] New Committer Dan Sandberg

[Ignacio J. Ortega]

Hola a Todos, Dennis, Dan:

I didnt vote you prior, mainly because i'm the weekend man :), but too
because having no time to follow every Technical thread here, and yours
were very far from my interests and habilities, and not knowing you,
i've decided to not to vote you better than give an uninformed vote, now
after reading this thread at least you 2 personally have convinced me
that deserve my vote.. 

+1 for both

If something i think we learned from that thread, raised by Pier "The
conspicuous" :), is that people must present himself to the tomcat
communitty at large, for those like me, uninformed of the facts and
ignorants of the more technical threads, can know more of the proposed
committer, and in addition made the desire of be part of this comunitty
something more proactive for the proposed person than it's now..

Saludos ,
Ignacio J. Ortega

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Henri Yandell]

+1.

Another example if I could. The job role of 'Java admin' is growing more
and more at companies. Developers shouldn't be adminning things, but would
you have your unix or oracle admin be the admin of the Java side with zero
Java knowledge?

Jakarta houses the 'Java' community at Apache but there's no way for a
Java admin to be a part of that community. Helping other admins, writing
documentation, being a consumer at the coders. The only way it can happen
is if they become a coder, and that's contrary to the concept of a Java
admin.

I think Pier's suggestion will help to grow the 'ownership' of the
projects and the apache way of thinking to a larger audience.

Some possible negatives:

With more non-codery people around, will the 'noise' level in mail lists
be too high for coders to want to pay attention?
[It already is getting that way I find. I delete entire threads if the
first couple of mails are not of interest to me. It has to be retitled as
with this email to make me realise there was more going on than the
original mails. ]

By growing a large community of non-coders, the coders could have less say
in the product. Is this good/bad? How would the +1/-1 system work. Would
votes be open to committers only in some instances, and to non-committing
members only in others. Who votes membership vs committership vs
contributorship?


None of them that hard to answer I imagine.

Hen

On Sat, 25 May 2002, Pier Fumagalli wrote:

> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
>
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
>
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
>
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
>
> And redefining the figure of the "committer" as follows:
>
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Denis Benoit]

On Fri, 24 May 2002, Pier Fumagalli wrote:

> Ok, we all agree that Denis gave a valuable contribution, but as far as I
> can see, can we say that this is "frequent"? I honestly can't... And again,
> I have _nothing_ against Dan or Dennis, actually, I would like to thank them
> for their patches...
> 
> Pier


I understand your arguments perfectly, and I must admit that I agree with most
of them.  On the other hand, I think there's a tendancy to bring fresh blood
in the tomcat-dev community and that may very well be a good thing.

Personnaly, I don't expect to use my recent commiter status to start to
commit code blindly.  What hooked me to the tomcat-dev community was the
challenge I could get working with guys like Kin-Man.  If you look at my ratio
of lines of e-mail to the list vs lines of code, you'll see that it's pretty
high :)  The most interesting part is the exchange of ideas to arrive at a
better solution than if all parties worked independantly.  I feel that I
grow better, and it feels also rewarding to know that what you build helped
other people too.  And the satisfaction of having done a thing "right" is not
bad either :)

I don't think that "knowing me better" is much relevant to do the actual
"commit" of the code.  Even if you knew me, even if you knew that I'm a good
coder (and I'm not saying that I am), it would not mean that I understand the
architecture of Tomcat, or the long time direction the group has decided to give
to Tomcat.  So a patch, even if it would be all right on its own, may not fit in
the architecture, or the direction that Tomcat is taking.  If only for these
reasons, I would rely on the opinions and feedback of the senior members of
Tomcat-dev.  And whatever status I may have, won't change the way I think.

I feel much more at ease having discussed a patch extensively with a
senior member of the team and submit a patch afterward.  I don't really care if
I'me the one doing the commit or if somebody else does it.  In fact, I
personally prefer to have some senior member audit the code and commit it.  If
the "commiter" status means that I will have to commit my code myself, and it
would be inappropriate to post code to the mailing list for peer review, then
by all means take it back!  I want to remain a developper!

All that being said, if it would appear preferable to some that my name be
removed from the CVS commiters list, I would not mind a bit.  I have just
read a proposition from Kin-Man to reengineer Generator.java and a reply from
Costin, you can bet that I will think about it a few hours and take a stance,
or maybe propose something :)  I sure hope that I can help in some way work on
this class that I came to know more closely with my previous patch, and in other
parts of Tomcat... I have other ideas :)  I really liked working with Kin-Man
(I hope it was mutual!), and I look forward to continue to be active in the
group whatever the status the group feels I should assume.

-- 
Denis Benoit
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[FAQ] jGuru FAQ Update

[Alex Chaffee]

jGuru maintains FAQs and Forums on Servlets, JSP, and Tomcat (as well as
many other Java topics).  Here is an automated update on recent postings to
Tomcat-related FAQs.  Please direct flames and feedback to [EMAIL PROTECTED] .

 - Alex


 JGURU PREMIUM SERVICE!

 How often has jGuru helped you solve a problem?  Contribute to the
 Java community and keep jGuru the best place to get answers by
 becoming a premium member.

 Get the World's BEST JAVA SEARCH ENGINE, FASTER PAGE RENDERING, and
 NO ADS. Just 4.95 a month or subscribe for a year at 49.95 and get
 12 months for the price of 10 and a FREE XL JGURU T-SHIRT!  Sign up
 now and try out the premium service for two weeks at no charge!

http://www.jguru.com/misc/page.jsp?fsm=premiumreg&node=blurb&src=email


Hi.  You asked to be notified weekly when certain jGuru.com items get new entries.


++ JavaServer Pages (JSP) FAQ: http://www.jguru.com/faq/JSP

What are the different ways of declaring a tag library to use from a JSP?  Which 
methods are compatible from any JSP container?
What are the different ways of declaring a tag library to use from a JSP?
Which methods are compatible from any JSP container?
Assume the following directory structure of a WAR deployed under Tomcat 4.0:

Files in / directory:
test.jsp

Files in /WEB-INF directory:
web.xml
ha.tld

Files in /WEB-INF/lib directory:
ha.jar

Files in ha.jar:
/meta-inf/taglib.jar
class files for tag handler(s)
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=889470


You can shut email notification off at the FAQ home
page(s) or:

  http://www.jguru.com/guru/notifyprefs.jsp



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

Dan Sandberg <[EMAIL PROTECTED]> wrote:

> Granting that I'm not as experienced with open-source collaboration as
> the rest of you are,

Don't worry, I'm here since 1997 and I'm probably the most clueless of all
freaks... :)

> my intuition is that the easier it is for people to
> make changes to the code-base ( assuming their contributions are
> reviewed ) the faster the code-base will improve and bugs will be
> eliminated.
> 
> Again, this is contigent on the belief that contributions will be
> reviewed by somebody for security, bugs, and code quality.

This is absolutely true. Fresh blood is what we _need_. I'm not arguing with
it, and I'm not arguing with the fact that it's just _easier_ to have CVS
access...

One example from somewhere else, I have a small patch for APR, the Apache
Portable Runtime, I just need to change a "..." (quote) in a [...] (square
bracket) in an M4 macro because it might break stuff somewhere (it seems
that all M4 versions actually interpret it in the same way, but there's a
slight difference). This is on 3 lines of their "configure.in", and I
submitted it 3 months ago? _noone_ committed it yet, once every week I
resubmit it, but it's such a tiny thing that noone actually cares to commit
(I would do exactly the same). If I had CVS access I would do it myself (I
can actually "grant" me cvs access, commit that patch and be gone, and I'm
sure noone would complain), but...

> As for the question that Pier asked: How much responsibility am I
> willing to take on?
> 
> I am willing to address bugs, and review contributions to the SSI code.
> I would usually not vote on committers unless I >know< that they should
> be + or -, which will be rare.
> 
> Similarly, I would vote on release plans, the future of the project,
> etc., if and only if I feel I had something to add in those areas, which
> will probably be rare.

Great, that's what we expect from committers, I'm going to strike my -1 and
make it a +1, but please don't let me down and disappear in 2 months! :) :)

>> If you want to know the real price of becoming a commiter - it's
>> loosing all control over the code you write, having to play flame wars
>> and grow a thick skin. And you may spend many weekends doing work
>> that is just thrown away.
> 
> I'm thick-headed and thick-skinned, so this is not a problem.   I'll
> skip on the flame wars though. :)

Too bad, I would like to have a flame buddy from time to time...

>> Are you interested? I don't want to sound bad, but hey
>> everything comes at a price :) :) :)
> 
> I don't view committer status as a trophy.  I just want to fix things
> that are broken.  Having commit access makes this easier for me and for
> everyone else.

I do view committer status as a trophy, probably because I had to put sweat
and blood in getting it years ago, and still, I'm struggling to get one on
APR, or on HTTPD, I help out when I can, I play with the big boys, one day
someone will just say "I'd like Pier to be a committer", and that will be
one of the best days in my life... But don't worry that on that day there
won't be anyone who could say "who's this guy?"...

>> If you want my advice - create a sourceforge account, do all the work
>> on SSI there, and have fun. ( and maybe give access to other
>> tomcat commiters who are interested to work on SSI ).
> 
> Not sure how this helps.  If I understand the suggestion correctly, this
> is equivalent to forking the SSI code, which definitely won't help the
> development process.

No, it won't and frankly it's something I wouldn't have wanted to hear from
a committer, a seasoned one, and a PMC member. I am trying, struggling to
build something, like most of us I'm not paid for what I do here (I used to
be, and I can tell you, now that I'm out, I wouldn't go back).

Just saying "get off to SourceForge and build your thing over there" doesn't
go around in my book...

> I just read Pier's proposal, and I agree with him.

Cheers, thanks, I'm going to waive my -1 so that you can vote +1 on my
proposal, then :) :) :)

> Sorry to have instigated all this, but I suppose it's something that
> would have had to be dealt with sooner or later...

You're right, it's just a "casus belli" as Romans might say. Now that the
discussion is undergoing (I hope), I would like to welcome you to the big
PHAT Jakarta Community, and please, as a (rejected before and then welcomed)
committer, keep your thoughts coming...

Pier



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

[kinman]

kinman  02/05/24 16:57:42

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties
  Log:
  - Thanks Jan Luehe for the patch.
  
  According to JSP.7.4 ("The Tag Library Descriptor Format"), it is
  illegal for a tag to define scripting variables in both its TLD and
  TagExtraInfo class.
  
  Jasper already enforces this, but its code generator makes separate
  method calls for declaring/synchronizing scripting variables from a
  TLD and those from the TagExtraInfo class, like this:
  
// Update AT_BEGIN variables
updateVariableInfos(varInfos, VariableInfo.AT_BEGIN, false);
updateTagVariableInfos(tagVarInfos, n.getTagData(),
  
  This can be simplified, since if "varInfos" is non-null, "tagVarInfos"
  must be null, and vice-versa.
  
  The proposed patch collapses the above method calls into one.
  
  Also, the code generator makes separate method calls to declare
  AT_BEGIN scripting variables outside the try-finally block, and then
  synchronizing them inside the try-finally block.
  
  Now that try-finally has been flattened, no separate declaration of
  AT_BEGIN variables is required, that is, AT_BEGIN variables can be
  declared when they are first synchronized (after a call to
  doStartTag()), just as NESTED and AT_END variables. This makes
  declareVariableInfos() and declareTagVariableInfos() redundant
  
  As a summary, the attached patch replaces
  
declareVariableInfos(),
declareTagVariableInfos(),
updateVariableInfos(), and
updateTagVariableInfos()
  
  with a single
  
syncScriptingVariables().
  
  Revision  ChangesPath
  1.16  +47 -94
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- Generator.java24 May 2002 00:35:41 -  1.15
  +++ Generator.java24 May 2002 23:57:42 -  1.16
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
 1.15 2002/05/24 00:35:41 kinman Exp $
  - * $Revision: 1.15 $
  - * $Date: 2002/05/24 00:35:41 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
 1.16 2002/05/24 23:57:42 kinman Exp $
  + * $Revision: 1.16 $
  + * $Date: 2002/05/24 23:57:42 $
*
* 
* 
  @@ -981,11 +981,6 @@
out.println("();");
generateSetters(n, tagHandlerVar, handlerInfo);

  - // Declare AT_BEGIN variables
  - declareVariableInfos(varInfos, VariableInfo.AT_BEGIN);
  - declareTagVariableInfos(tagVarInfos, n.getTagData(),
  - VariableInfo.AT_BEGIN);
  - 
   if (implementsTryCatchFinally) {
   out.printil("try {");
   out.pushIndent();
  @@ -1004,11 +999,10 @@
boolean isBodyTag
= BodyTag.class.isAssignableFrom(tagHandlerClass);
   
  - // Update AT_BEGIN variables
  - updateVariableInfos(varInfos, VariableInfo.AT_BEGIN, false);
  - updateTagVariableInfos(tagVarInfos, n.getTagData(),
  -VariableInfo.AT_BEGIN, false);
  -
  + // Declare and synchronize AT_BEGIN scripting variables
  + syncScriptingVariables(varInfos, tagVarInfos, n.getTagData(),
  +VariableInfo.AT_BEGIN, true);
  + 
if (n.getBody() != null) {
out.printin("if (");
out.print(tagEvalVar);
  @@ -1042,14 +1036,13 @@
}
}
   
  - // Declare and update NESTED variables
  - updateVariableInfos(varInfos, VariableInfo.NESTED, true);
  - updateTagVariableInfos(tagVarInfos, n.getTagData(),
  -VariableInfo.NESTED, true);
  -
  - // Update AT_BEGIN variables
  - updateVariableInfos(varInfos, VariableInfo.AT_BEGIN, false);
  - updateTagVariableInfos(tagVarInfos, n.getTagData(),
  +
  + // Declare and synchronize NESTED scripting variables
  + syncScriptingVariables(varInfos, tagVarInfos, n.getTagData(),
  +VariableInfo.NESTED, true);
  +
  + // Synchronize AT_BEGIN scripting variables
  + syncScriptingVariables(varInfos, tagVarInfos, n.getTagData(),
   VariableInfo.AT_BEGIN, false);
};

  @@ -1074,9 +1067,8 @@
out.println(".doAfterBody() == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_

Re: [VOTE] New Committer Dan Sandberg

[Dan Sandberg]

Granting that I'm not as experienced with open-source collaboration as 
the rest of you are, my intuition is that the easier it is for people to 
make changes to the code-base ( assuming their contributions are 
reviewed ) the faster the code-base will improve and bugs will be 
eliminated.

Again, this is contigent on the belief that contributions will be 
reviewed by somebody for security, bugs, and code quality.

As for the question that Pier asked: How much responsibility am I 
willing to take on?

I am willing to address bugs, and review contributions to the SSI code. 
 I would usually not vote on committers unless I >know< that they should 
be + or -, which will be rare.

Similarly, I would vote on release plans, the future of the project, 
etc., if and only if I feel I had something to add in those areas, which 
will probably be rare.

>If you want to know the real price of becoming a commiter - it's
>loosing all control over the code you write, having to play flame wars
>and grow a thick skin. And you may spend many weekends doing work
>that is just thrown away.

I'm thick-headed and thick-skinned, so this is not a problem.   I'll 
skip on the flame wars though. :)

>Are you interested? I don't want to sound bad, but hey
>everything comes at a price :) :) :)

I don't view committer status as a trophy.  I just want to fix things 
that are broken.  Having commit access makes this easier for me and for 
everyone else.

>If you want my advice - create a sourceforge account, do all the work
>on SSI there, and have fun. ( and maybe give access to other
>tomcat commiters who are interested to work on SSI ).

Not sure how this helps.  If I understand the suggestion correctly, this 
is equivalent to forking the SSI code, which definitely won't help the 
development process.

I just read Pier's proposal, and I agree with him.

Sorry to have instigated all this, but I suppose it's something that 
would have had to be dealt with sooner or later...

-Dan


Pier Fumagalli wrote:

>[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>  
>
>>On Fri, 24 May 2002, Pier Fumagalli wrote:
>>
>>
>>
>>>Just one question on this. Being a committer implies that you're going to
>>>have the right (and the due, of course, like in any good democracy) to (for
>>>example) elect PMC members, have -also- a some sort of responsibility over
>>>what you do, and what others do, meaning code reviews, deciding on the
>>>future of the whole tomcat project, voting on future release plans and
>>>such... As I said, this is not only a right, but also a responsibility. As a
>>>committer you _should_ be doing that.
>>>
>>>Now, my question is, do you want _at_this_point_ to have that
>>>responsibility? Are you interested? I don't want to sound bad, but hey
>>>everything comes at a price :) :) :)
>>>  
>>>
>>Most tomcat commiters review only a small ammount of the commits, that
>>is relevant to what they know.  Voting ( or beeing voted ) in PMC is
>>optional. 
>>
>>If you want to know the real price of becoming a commiter - it's
>>loosing all control over the code you write, having to play flame wars
>>and grow a thick skin. And you may spend many weekends doing work
>>that is just thrown away.
>>
>>
>>Pier is right in this aspect - and I fully agree with him that
>>beeing a jakarta commiter comes at a much bigger price than you
>>may think.  
>>
>>
>>If you want my advice - create a sourceforge account, do all the work
>>on SSI there, and have fun. ( and maybe give access to other
>>tomcat commiters who are interested to work on SSI ).
>>
>>
>
>Very constructive, Costin, indeed... See my next email (at least I'm trying
>to propose something)...
>
>Pier
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PROPOSAL] Committer access and responsibilities...

[Pier Fumagalli]

Chatted with a lot of people, seen many, different development models, went
around, asked, talked, and I believe I have a pretty decent picture, and
maybe even a solution...

So the major topic of discussion is that I perceive a substantial difference
between being able to commit code to a CVS repository, and being a
"committer" committer, with all dues and responsibilities that this role
concerns...

For example sometimes someone might want to have commit access just because
he is working for a company that deals with a particular project in Apache
(we've seen this happening several times with some projects such as Xerces
and Tomcat), but he really doesn't care about the whole fuzz of Apache and
stuff, and once the employment contract ends, the relationship with Apache
terminates as well (I don't need to enumerate all those examples along those
lines).

One other example, if we didn't have Henri building RPMs for basically all
Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
don't you think that he would deserve committer status even if he's not tied
to any particular codebase? We had this "problem" in the current election of
the members, Sally Khudairi: Sally doesn't code, but she was involved with
the ASF since before it was even created as a press organizer. Does she
deserve to be a member of the foundation? Even if she doesn't code? Yes she
does, IMO (and she was elected and nominated a member today)...

So, IMO, there's a great difference between being a coder, and being a
member of the Jakarta community, at least in my opinion. There might be
coders who are not involved with the community, and there might be
non-coders who are much involved with it, want to participate, are active
and deserve to be committers...

Our current structure doesn't "allow" that to happen, both things. If you
need to write code in a particular source-base, and you need CVS access, you
are automagically made a committer, even if you don't care about much else,
and if you're very much involved with the overall project, but not tied to
ANY whatsoever codebase, and really, don't want / can't do it.

So, given this little background, I would like to ask to the PMC, and all
other committers, if others agree that we should "splitting" the "committer"
figure in two parts:

- contributor: a contributor is someone who has access to a particular CVS
tree, but for any reason doesn't want/need to be involved with the whole
Jakarta community. He just wants to code his little bit and live a long
life.

- member: is someone who is involved with the Jakarta community, somehow,
somewhere (might be just giving a great deal in supporting users of our
projects, or providing extra value to projects, like guidance in respect to
overall specifications, binary builds). He is effectively a member of the
community and has all the rights and dues of every member, such as
participate in the election of the PMC.

And redefining the figure of the "committer" as follows:

- committer: is a contributor, but also a member, therefore he has all the
privileges and dues of a contributor (having CVS access, and overlooking the
code he's contributing to) and of a member (can vote for PMCs, should
participate and contribute to discussions on the overall structure of
Jakarta).

I believe this makes sense, more sense than what we have now, also because
we've seen that happening in the ASF for the very first time with a
non-coding member. Comments please?

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> On Fri, 24 May 2002, Pier Fumagalli wrote:
> 
>> Just one question on this. Being a committer implies that you're going to
>> have the right (and the due, of course, like in any good democracy) to (for
>> example) elect PMC members, have -also- a some sort of responsibility over
>> what you do, and what others do, meaning code reviews, deciding on the
>> future of the whole tomcat project, voting on future release plans and
>> such... As I said, this is not only a right, but also a responsibility. As a
>> committer you _should_ be doing that.
>> 
>> Now, my question is, do you want _at_this_point_ to have that
>> responsibility? Are you interested? I don't want to sound bad, but hey
>> everything comes at a price :) :) :)
> 
> Most tomcat commiters review only a small ammount of the commits, that
> is relevant to what they know.  Voting ( or beeing voted ) in PMC is
> optional. 
> 
> If you want to know the real price of becoming a commiter - it's
> loosing all control over the code you write, having to play flame wars
> and grow a thick skin. And you may spend many weekends doing work
> that is just thrown away.
> 
> 
> Pier is right in this aspect - and I fully agree with him that
> beeing a jakarta commiter comes at a much bigger price than you
> may think.  
> 
> 
> If you want my advice - create a sourceforge account, do all the work
> on SSI there, and have fun. ( and maybe give access to other
> tomcat commiters who are interested to work on SSI ).

Very constructive, Costin, indeed... See my next email (at least I'm trying
to propose something)...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[costinm]

On Fri, 24 May 2002, Pier Fumagalli wrote:

> Just one question on this. Being a committer implies that you're going to
> have the right (and the due, of course, like in any good democracy) to (for
> example) elect PMC members, have -also- a some sort of responsibility over
> what you do, and what others do, meaning code reviews, deciding on the
> future of the whole tomcat project, voting on future release plans and
> such... As I said, this is not only a right, but also a responsibility. As a
> committer you _should_ be doing that.
> 
> Now, my question is, do you want _at_this_point_ to have that
> responsibility? Are you interested? I don't want to sound bad, but hey
> everything comes at a price :) :) :)

Most tomcat commiters review only a small ammount of the commits, that
is relevant to what they know.  Voting ( or beeing voted ) in PMC is
optional. 

If you want to know the real price of becoming a commiter - it's 
loosing all control over the code you write, having to play flame wars
 and grow a thick skin. And you may spend many weekends doing work
that is just thrown away.


Pier is right in this aspect - and I fully agree with him that 
beeing a jakarta commiter comes at a much bigger price than you 
may think.  


If you want my advice - create a sourceforge account, do all the work
on SSI there, and have fun. ( and maybe give access to other 
tomcat commiters who are interested to work on SSI ). 

Costin
 



> 
> (I just want to show how committing to a particular codebase, sometimes,
> might be different from "the whole kit'n'kaboodle that being a committer
> involves")...
> 
> > D.Scope.  Must a commiter have scope to the entire project?  Can't the
> > access file be changed only in the o.a.c.ssi directory and the servlet
> > directory?  Would this address any concerns?
> 
> Technically it would be "feasible" to implement that feature, but
> administrivia would become utterly complex.
> 
> Thank you _very_much_ for taking part to all of this :) :) :)
> 
> Pier
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] Simplified scripting-variable declaration/synchronization in Generator.java

[Jan Luehe]

According to JSP.7.4 ("The Tag Library Descriptor Format"), it is
illegal for a tag to define scripting variables in both its TLD and
TagExtraInfo class.

Jasper already enforces this, but its code generator makes separate
method calls for declaring/synchronizing scripting variables from a
TLD and those from the TagExtraInfo class, like this:

  // Update AT_BEGIN variables
  updateVariableInfos(varInfos, VariableInfo.AT_BEGIN, false);
  updateTagVariableInfos(tagVarInfos, n.getTagData(),

This can be simplified, since if "varInfos" is non-null, "tagVarInfos"
must be null, and vice-versa.

The proposed patch collapses the above method calls into one.

Also, the code generator makes separate method calls to declare
AT_BEGIN scripting variables outside the try-finally block, and then
synchronizing them inside the try-finally block.

Now that try-finally has been flattened, no separate declaration of
AT_BEGIN variables is required, that is, AT_BEGIN variables can be
declared when they are first synchronized (after a call to
doStartTag()), just as NESTED and AT_END variables. This makes
declareVariableInfos() and declareTagVariableInfos() redundant

As a summary, the attached patch replaces

  declareVariableInfos(),
  declareTagVariableInfos(),
  updateVariableInfos(), and
  updateTagVariableInfos()

with a single

  syncScriptingVariables().


Jan




? build
? build.xml.SAVE
Index: src/share/org/apache/jasper/compiler/Generator.java
===
RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.15
diff -u -r1.15 Generator.java
--- src/share/org/apache/jasper/compiler/Generator.java 24 May 2002 00:35:41 - 
 1.15
+++ src/share/org/apache/jasper/compiler/Generator.java 24 May 2002 22:12:51 -
@@ -981,11 +981,6 @@
out.println("();");
generateSetters(n, tagHandlerVar, handlerInfo);

-   // Declare AT_BEGIN variables
-   declareVariableInfos(varInfos, VariableInfo.AT_BEGIN);
-   declareTagVariableInfos(tagVarInfos, n.getTagData(),
-   VariableInfo.AT_BEGIN);
-   
 if (implementsTryCatchFinally) {
 out.printil("try {");
 out.pushIndent();
@@ -1004,10 +999,9 @@
boolean isBodyTag
= BodyTag.class.isAssignableFrom(tagHandlerClass);
 
-   // Update AT_BEGIN variables
-   updateVariableInfos(varInfos, VariableInfo.AT_BEGIN, false);
-   updateTagVariableInfos(tagVarInfos, n.getTagData(),
-  VariableInfo.AT_BEGIN, false);
+   // Declare and synchronize AT_BEGIN scripting variables
+   syncScriptingVariables(varInfos, tagVarInfos, n.getTagData(),
+  VariableInfo.AT_BEGIN, true);
 
if (n.getBody() != null) {
out.printin("if (");
@@ -1042,14 +1036,12 @@
}
}
 
-   // Declare and update NESTED variables
-   updateVariableInfos(varInfos, VariableInfo.NESTED, true);
-   updateTagVariableInfos(tagVarInfos, n.getTagData(),
+   // Declare and synchronize NESTED scripting variables
+   syncScriptingVariables(varInfos, tagVarInfos, n.getTagData(),
   VariableInfo.NESTED, true);
 
-   // Update AT_BEGIN variables
-   updateVariableInfos(varInfos, VariableInfo.AT_BEGIN, false);
-   updateTagVariableInfos(tagVarInfos, n.getTagData(),
+   // Synchronize AT_BEGIN scripting variables
+   syncScriptingVariables(varInfos, tagVarInfos, n.getTagData(),
   VariableInfo.AT_BEGIN, false);
};

@@ -1074,9 +1066,8 @@
out.println(".doAfterBody() == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);");
}
 
-   // Update AT_BEGIN variables
-   updateVariableInfos(varInfos, VariableInfo.AT_BEGIN, false);
-   updateTagVariableInfos(tagVarInfos, n.getTagData(),
+   // Synchronize AT_BEGIN scripting variables
+   syncScriptingVariables(varInfos, tagVarInfos, n.getTagData(),
   VariableInfo.AT_BEGIN, false);
 
if (n.getBody() != null) {
@@ -1125,94 +1116,57 @@
 out.println(".release();");
}
 
-   // Declare and update AT_END variables
-   updateVariableInfos(varInfos, VariableInfo.AT_END, true);
-   updateTagVariableInfos(tagVarInfos, n.getTagData(),
+   // Declare and synchronize AT_END variables
+   syncScriptingVariables(varInfos, tagVarInfos, n.getTagData(),
   VariableInfo.AT_END, true);
 
n.setEndJavaLine(out.getJavaLine());
}
 
-   private void declareVariableInfos(VariableInfo[] varInfos, int 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

Dan Sandberg <[EMAIL PROTECTED]> wrote:

> I think Pier's conerns are quite reasonable.

Thank you, and coming from the interested party, that shows me we are in
agreement... :) :) :)

> Let me bring up a few points that I think are central to the debate:

I'm following...

> A.  Security.  This is the most important concern in allowing new
> commiters.  If they purposely or accidently introduce security issues,
> this tarnishes the Tomcat name.  Code review is the most important way
> of preventing this. How much does asking someone else to commit the code
> for you force them to look over it for bugs of this kind?  How much
> would other people look over CVS submissions that were done directly by
> a new commiter?  The ratio between these numbers is critical.  If it is
> 1, then there is no harm in giving commit access easily.

I personally review every CVS commit that concerns me. For example, I don't
review commits to TC3.x because I don't use it, or to mod_jk, because I
don't understand it... I try to help out when I can on those source bases,
but I can't really do much on those trees...

I consider myself a committer of jakarta-tomcat-connectors/webapp (very
restricted scope) but I do have the ability to screw up other code as well
:) And of course, I try to participate to my best to the overall Tomcat 4.x
evolution (but time's limited nowadays).

> B. Introducing bugs.  This is a concern much like A., but because the
> SSI code had glaring bugs to begin with, I don't think it is much of an
> issue in my case.  If a new contributor has commit access, it makes it
> easier for her to fix any bugs they introduce, and presumably they would
> because of the pride-factor.

Most of the bugs (IMO) are introduced by veterans (such as me), because we
get stuck usually on something and we tend not to look at the wider picture,
coming from the outside, it's easier for you to see my fuckups, for
instance, because you see the code still as "a whole"...

> C. Commiter may not stay long.  In my case, I explicitly said that I
> didn't want to be a commiter originally.  I didn't want to spend lots of
> time on this project.  As things turned out, my 3 hour change turned
> into a 3 day change, and it has become obvious to me that a few more
> commits will probably be necessary.  I asked for commit access because
> 1) I want to take the load of others and 2) The latency of waiting for
> others to review/commit the code is fairly high.  Nevertheless, I'll say
> this explicitly: I don't want to become a 'major' contributor to Tomcat.
> Act accoringly.

Just one question on this. Being a committer implies that you're going to
have the right (and the due, of course, like in any good democracy) to (for
example) elect PMC members, have -also- a some sort of responsibility over
what you do, and what others do, meaning code reviews, deciding on the
future of the whole tomcat project, voting on future release plans and
such... As I said, this is not only a right, but also a responsibility. As a
committer you _should_ be doing that.

Now, my question is, do you want _at_this_point_ to have that
responsibility? Are you interested? I don't want to sound bad, but hey
everything comes at a price :) :) :)

(I just want to show how committing to a particular codebase, sometimes,
might be different from "the whole kit'n'kaboodle that being a committer
involves")...

> D.Scope.  Must a commiter have scope to the entire project?  Can't the
> access file be changed only in the o.a.c.ssi directory and the servlet
> directory?  Would this address any concerns?

Technically it would be "feasible" to implement that feature, but
administrivia would become utterly complex.

Thank you _very_much_ for taking part to all of this :) :) :)

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Proposal] Removing 64K limit in jasper 2

[costinm]

I don't think the overhead of calling a private/final method is 
very big, especially with hotspot or any decent jit. 

If this turns to have an impact, we can turn it on only for pages
with many tags, but I think it would be fine for all pages ( without
scriptlets ).

BTW, given that the logic in a JSP page without scriptlets is 
quite simple, using a state machine may also be a good solution.
I mean saving a pre-processed/binary form of the JSP as data, 
and using a sort of interpreter. 
I have big doubts on the benefits of using a compiled form for
this kind of data-driven stuff. That's just an idea - it may also
work well without even compiling the page to .class for most 
non-scriptlet pages.


Costin


On Fri, 24 May 2002, Kin-Man Chung wrote:

> The JVM limits the size of a method to less than 65535 bytes.  This limit
> can easily be reached by a JSP page with 50-80 custom tags, depending
> on the javac compiler and the complexity of the tags.  The use of
> "largefile" option delays reaching the limit a little, but not by much.
> That's one of the reasons largefile option is not implemented in jasper 2.
> 
> My proposal to solving this problem is to generate codes for a tag
> handler (including its body) to a separate method.  This is only feasible
> if the tag action element and its body does not include any scripting
> elements.  The current trend (in the coming JSP1.3) seems to be moving
> to scriptless pages, so this is not as restrictive as it appears.
> 
> I don't have a detailed design yet for Generator, but I don't see any
> obvious problems.  The recent change in flattening out the try/catch
> blocks complicates things a little, but they are manageable.
> 
> There is obviously some performance trade-offs.  I really don't like
> using a compilation option to turn on/off features, especially if it is
> used only to get around limitations the users don't care.  I think jasper
> can make code generation decisions based on the number of tags (both
> sequential and nested) in a page.  I plan to make experimentation ease
> by having parameters (such as number of tags, size of tag body) that can
> be adjusted, and hopefully to arrive at a balance between limiting the size
> of a method to 64K and some reasonable performance.
> 
> Comments?
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Proposal] Removing 64K limit in jasper 2

[Pier Fumagalli]

"Kin-Man Chung" <[EMAIL PROTECTED]> wrote:

> The JVM limits the size of a method to less than 65535 bytes.  This limit
> can easily be reached by a JSP page with 50-80 custom tags, depending
> on the javac compiler and the complexity of the tags.  The use of
> "largefile" option delays reaching the limit a little, but not by much.
> That's one of the reasons largefile option is not implemented in jasper 2.
> 
> My proposal to solving this problem is to generate codes for a tag
> handler (including its body) to a separate method.  This is only feasible
> if the tag action element and its body does not include any scripting
> elements.  The current trend (in the coming JSP1.3) seems to be moving
> to scriptless pages, so this is not as restrictive as it appears.
> 
> I don't have a detailed design yet for Generator, but I don't see any
> obvious problems.  The recent change in flattening out the try/catch
> blocks complicates things a little, but they are manageable.
> 
> There is obviously some performance trade-offs.  I really don't like
> using a compilation option to turn on/off features, especially if it is
> used only to get around limitations the users don't care.  I think jasper
> can make code generation decisions based on the number of tags (both
> sequential and nested) in a page.  I plan to make experimentation ease
> by having parameters (such as number of tags, size of tag body) that can
> be adjusted, and hopefully to arrive at a balance between limiting the size
> of a method to 64K and some reasonable performance.
> 
> Comments?

Go for it, because we hit that limit several times :) :) :)

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Proposal] Removing 64K limit in jasper 2

[Kin-Man Chung]

The JVM limits the size of a method to less than 65535 bytes.  This limit
can easily be reached by a JSP page with 50-80 custom tags, depending
on the javac compiler and the complexity of the tags.  The use of
"largefile" option delays reaching the limit a little, but not by much.
That's one of the reasons largefile option is not implemented in jasper 2.

My proposal to solving this problem is to generate codes for a tag
handler (including its body) to a separate method.  This is only feasible
if the tag action element and its body does not include any scripting
elements.  The current trend (in the coming JSP1.3) seems to be moving
to scriptless pages, so this is not as restrictive as it appears.

I don't have a detailed design yet for Generator, but I don't see any
obvious problems.  The recent change in flattening out the try/catch
blocks complicates things a little, but they are manageable.

There is obviously some performance trade-offs.  I really don't like
using a compilation option to turn on/off features, especially if it is
used only to get around limitations the users don't care.  I think jasper
can make code generation decisions based on the number of tags (both
sequential and nested) in a page.  I plan to make experimentation ease
by having parameters (such as number of tags, size of tag body) that can
be adjusted, and hopefully to arrive at a balance between limiting the size
of a method to 64K and some reasonable performance.

Comments?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: CVS problem with SSIServlet file

[Dan Sandberg]

Perhaps Bill had the same problem when he tried to submit my code.

The code I posted on this list had the file named SSIServlet.java ( not 
SsiServlet.java ) and the web.xml file called it SSIServlet.java.

Bill changed those both to SsiServlet, perhaps because of the problems 
you are having.

Maybe SSIServlet.java is already is in the repository attic and is 
causing a conflict? Maybe there's some case-insensitivity thing going on 
( I know CVS is case-sensitive )?

Can someone muck around in the repository and see what's going on?

-Dan

Remy Maucherat wrote:

>>Remy,
>>
>>I just fixed the SSiCommand.java case and have updated several times from
>>
>>
>CVS
>  
>
>>without any problems.  Tomcat 4 CVS HEAD now builds fine for me.
>>One of my updates did get delayed for 10-15 seconds while you had a lock
>>on one of the SSI files.
>>
>>I no longer see an SSIServlet.java or SSiServlet.java in my local copy
>>of the TOmcat 4 cvs repository.
>>
>>
>
>I removed the file, but wasn't able to add it back, because of the error I
>got from the server :-(
>
>Remy
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Dan Sandberg]

I think Pier's conerns are quite reasonable.  Let me bring up a few 
points that I think are central to the debate:

A.  Security.  This is the most important concern in allowing new 
commiters.  If they purposely or accidently introduce security issues, 
this tarnishes the Tomcat name.  Code review is the most important way 
of preventing this. How much does asking someone else to commit the code 
for you force them to look over it for bugs of this kind?  How much 
would other people look over CVS submissions that were done directly by 
a new commiter?  The ratio between these numbers is critical.  If it is 
1, then there is no harm in giving commit access easily.

B. Introducing bugs.  This is a concern much like A., but because the 
SSI code had glaring bugs to begin with, I don't think it is much of an 
issue in my case.  If a new contributor has commit access, it makes it 
easier for her to fix any bugs they introduce, and presumably they would 
because of the pride-factor.

C. Commiter may not stay long.  In my case, I explicitly said that I 
didn't want to be a commiter originally.  I didn't want to spend lots of 
time on this project.  As things turned out, my 3 hour change turned 
into a 3 day change, and it has become obvious to me that a few more 
commits will probably be necessary.  I asked for commit access because 
1) I want to take the load of others and 2) The latency of waiting for 
others to review/commit the code is fairly high.  Nevertheless, I'll say 
this explicitly: I don't want to become a 'major' contributor to Tomcat. 
 Act accoringly.

D.Scope.  Must a commiter have scope to the entire project?  Can't the 
access file be changed only in the o.a.c.ssi directory and the servlet 
directory?  Would this address any concerns?

Thanks,

Dan

Pier Fumagalli wrote:

>"jean-frederic clere" <[EMAIL PROTECTED]> wrote:
>  
>
>>Remy Maucherat wrote:
>>
>>
In the middle it's good, extremes (I believe) not... And since this is the
second time in less than a week (Denis posted 14 times, the first time on
4/27 if I'm not wrong and Dan 7 times, the first time on 5/1), and it's
starting to be a little bit "extreme" and it doesn't make me feel very
comfortable...


>>>You have to consider the importance and quality of the patch. In Denis'
>>>case, that's why I nominated him.
>>>
>>>I have yet to see trouble caused by a guy who was granted commit access, and
>>>the idea is to encourage people to contribute more.
>>>  
>>>
>>Probably the status of Developer as described in the
>>http://jakarta.apache.org/site/roles.html is not used correctly.
>>
>>For me, if someone that brings one good patch reaches the developer rank, not
>>yet the committer rank (Or are the committers too lazy to commit contributions
>>from the developers?).
>>
>>
>
>>From the same document you mentioned... "Committers: Developers who give
>frequent and valuable contributions to a subproject of the Project can have
>their status promoted to that of a "Committer" for that subproject."
>
>Ok, we all agree that Denis gave a valuable contribution, but as far as I
>can see, can we say that this is "frequent"? I honestly can't... And again,
>I have _nothing_ against Dan or Dennis, actually, I would like to thank them
>for their patches...
>
>Pier
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Proposal] Tomcat and Cactus (Repost)

[costinm]

On Fri, 24 May 2002, Vincent Massol wrote:

> I'm reposting in the secret hope that I got no response to this email I
> sent last week because no one saw it in the flood of Tomcat emails ! If
> I get no answer this time, I will understand that no one finds this of
> interest and will try again in 6 months - 1 year :-)

I think it would be a good idea :-), there is already far too much going 
on, with all the new features and changes ( jmx, 4.1, jk2, jasper2, 
coyote, etc ).

Costin


> 
> Thanks
> -Vincent
> 
> 
> 
> Hi Tomcat developers,
> 
> This is a proposal to bring Jakarta Tomcat and Jakarta Cactus
> (http://jakarta.apache.org/cactus) closer. I hope you'll like it.
>  
> (0) Rationale
> 
> Jakarta Cactus is a unit testing framework for testing Servlet, Taglibs
> and Filters. Jakarta Tomcat is a Servlet engine (Servlet, Taglibs,
> Filters). They are both part of the Jakarta community. At the moment,
> there are no existing Servlet container that have an easy way to unit
> test Servlets. The idea is to bring this ease of use to Tomcat by making
> it easy to use Cactus within Tomcat (in other words, add a unit testing
> service to Tomcat).
> 
> (1) Scope of the proposal
> 
> a) To bundle Cactus within Tomcat so that it provides a unique ease of
> use for Tomcat users who wishes to test their servlet code
> b) To make Cactus the official Tomcat test framework for end users
> 
> (1) From the point of view of Tomcat users
> 
> By providing the bundling defined in point (2) below, Tomcat end users
> would only have to do the following to test their code (see
> http://jakarta.apache.org/cactus/1.4/howto_tomcat.html, steps 4 to 6) :
> 
> a) Create Cactus test classes in their WEB-INF/classes directory
> b) Open a browser and type the URL of the Cactus test runner, passing
> the name of the test class (see the link above for details)
> 
> (2) Cactus bundling in Tomcat
> 
> "Bundling" Cactus in Tomcat means (see steps 1 to 3 on the above link) :
> 
> a) Adding the following jars to common/lib : cactus.jar, junit.jar,
> httpclient.jar, aspectjrt.jar (total of 423 KB)
> b) Adding the Cactus servlet test runner and redirector servlet and
> mappings in conf/web.xml
> 
> (3) Versions
> 
> The target Tomcat version for this proposal is 4.0 and greater. The
> Cactus one is 1.4 and greater (note that Cactus 1.4 is not released yet
> and is still in CVS - It can be downloaded from the nightly build).
> 
> Comments, ideas ?
> 
> Thank you
> -Vincent (from the Cactus team)
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9382] - IOException: Cannot find message associated with key 'responseStream.suspended'

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9382

IOException: Cannot find message associated with key 'responseStream.suspended'

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 18:15 ---
This happens if you're trying to do something with the ouptut stream or writer
after the response has been finished (either by using sendRedirect, sendError,
or after a forward).
If you're not doing any of this, you can try Coyote to see if it fixes the problem.
If this doesn't fix it, reopen the bug and submit a test case or give very
detailed explanations on how to reproduce it.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets ManagerServlet.java

[remm]

remm02/05/24 11:01:50

  Modified:catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
  Log:
  - Improve the type filtering to use instanceof.
  
  Revision  ChangesPath
  1.23  +21 -9 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- ManagerServlet.java   24 May 2002 17:41:48 -  1.22
  +++ ManagerServlet.java   24 May 2002 18:01:50 -  1.23
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
 1.22 2002/05/24 17:41:48 remm Exp $
  - * $Revision: 1.22 $
  - * $Date: 2002/05/24 17:41:48 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
 1.23 2002/05/24 18:01:50 remm Exp $
  + * $Revision: 1.23 $
  + * $Date: 2002/05/24 18:01:50 $
*
* 
*
  @@ -198,7 +198,7 @@
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.22 $ $Date: 2002/05/24 17:41:48 $
  + * @version $Revision: 1.23 $ $Date: 2002/05/24 18:01:50 $
*/
   
   public class ManagerServlet
  @@ -805,7 +805,19 @@
   writer.println(sm.getString("managerServlet.resourcesAll"));
   }
   
  -printResources(writer, "", global, type);
  +Class clazz = null;
  +try {
  +if (type != null) {
  +clazz = Class.forName(type);
  +}
  +} catch (Throwable t) {
  +log("ManagerServlet.resources[" + type + "]", t);
  +writer.println(sm.getString("managerServlet.exception",
  +t.toString()));
  +return;
  +}
  +
  +printResources(writer, "", global, type, clazz);
   
   }
   
  @@ -815,7 +827,7 @@
*/
   protected void printResources(PrintWriter writer, String prefix,
 javax.naming.Context namingContext,
  -  String type) {
  +  String type, Class clazz) {
   
   try {
   NamingEnumeration items = namingContext.listBindings("");
  @@ -824,10 +836,10 @@
   if (item.getObject() instanceof javax.naming.Context) {
   printResources
   (writer, prefix + item.getName() + "/",
  - (javax.naming.Context) item.getObject(), type);
  + (javax.naming.Context) item.getObject(), type, clazz);
   } else {
  -if ((type != null) &&
  -(!type.equals(item.getClassName( {
  +if ((clazz != null) &&
  +(!(clazz.isInstance(item.getObject() {
   continue;
   }
   writer.print(prefix + item.getName());
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Jasper2] New compiler

[Remy Maucherat]

I think the new Ant compiler is done; it builds only the class which has to
be built, does not use a giant sync lock (testing with the frameset in the
admin webapp showed good results), and correctly captures the compilation
error messages.

As usual, only the error messages output from javac can be parsed and
displayed as line numbers.

The abality to select a compiler other than Ant's default (classic javac on
JDK 1.2, modern javac on JDK 1.3 and 1.4) is not implemented yet.

However, I went through the code for compiler handling, and it is a lot more
complex than it should be. I plan to remove all of it, and relying on Ant to
select the right compiler. After that, I'll fix JspC.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets ManagerServlet.java

[remm]

remm02/05/24 10:41:48

  Modified:catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
  Log:
  - Handle resources nested in subcontexts.
  
  Revision  ChangesPath
  1.22  +34 -15
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- ManagerServlet.java   21 May 2002 01:36:36 -  1.21
  +++ ManagerServlet.java   24 May 2002 17:41:48 -  1.22
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
 1.21 2002/05/21 01:36:36 remm Exp $
  - * $Revision: 1.21 $
  - * $Date: 2002/05/21 01:36:36 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
 1.22 2002/05/24 17:41:48 remm Exp $
  + * $Revision: 1.22 $
  + * $Date: 2002/05/24 17:41:48 $
*
* 
*
  @@ -76,8 +76,8 @@
   import java.util.Iterator;
   import java.util.jar.JarEntry;
   import java.util.jar.JarFile;
  +import javax.naming.Binding;
   import javax.naming.InitialContext;
  -import javax.naming.NameClassPair;
   import javax.naming.NamingEnumeration;
   import javax.naming.NamingException;
   import javax.naming.directory.DirContext;
  @@ -198,7 +198,7 @@
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.21 $ $Date: 2002/05/21 01:36:36 $
  + * @version $Revision: 1.22 $ $Date: 2002/05/24 17:41:48 $
*/
   
   public class ManagerServlet
  @@ -804,19 +804,38 @@
   } else {
   writer.println(sm.getString("managerServlet.resourcesAll"));
   }
  +
  +printResources(writer, "", global, type);
  +
  +}
  +
  +
  +/**
  + * List the resources of the given context.
  + */
  +protected void printResources(PrintWriter writer, String prefix,
  +  javax.naming.Context namingContext,
  +  String type) {
  +
   try {
  -NamingEnumeration items = global.list("");
  +NamingEnumeration items = namingContext.listBindings("");
   while (items.hasMore()) {
  -NameClassPair item = (NameClassPair) items.next();
  -if ((type != null) &&
  -(!type.equals(item.getClassName( {
  -continue;
  +Binding item = (Binding) items.next();
  +if (item.getObject() instanceof javax.naming.Context) {
  +printResources
  +(writer, prefix + item.getName() + "/",
  + (javax.naming.Context) item.getObject(), type);
  +} else {
  +if ((type != null) &&
  +(!type.equals(item.getClassName( {
  +continue;
  +}
  +writer.print(prefix + item.getName());
  +writer.print(':');
  +writer.print(item.getClassName());
  +// Do we want a description if available?
  +writer.println();
   }
  -writer.print(item.getName());
  -writer.print(':');
  -writer.print(item.getClassName());
  -// Do we want a description if available?
  -writer.println();
   }
   } catch (Throwable t) {
   log("ManagerServlet.resources[" + type + "]", t);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9400] - No mulitply <%@page language='java' import='xxx' %> allowed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9400

No mulitply <%@page language='java' import='xxx' %> allowed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 17:39 ---
JSP.2.10.1 says:

"However, there shall be only one occurrence of any attributes/value defined by
this directive in a given translation unit with the exception of the "import"
attribute; multiple uses of the attribute are cumulative (with ordered set union
semantics).  Other such multiple attribute/value (re)definitions result in a
fata translation error."

You should file a bug against other JSP engines instead.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9400] - No mulitply <%@page language='java' import='xxx' %> allowed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9400

No mulitply <%@page language='java' import='xxx' %> allowed





--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 17:34 ---
*** Bug 9399 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9399] - No mulitply <%@page language='java' import=

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9399

No mulitply <%@page language='java' import=

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 17:34 ---


*** This bug has been marked as a duplicate of 9400 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9400] New: - No mulitply <%@page language='java' import='xxx' %> allowed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9400

No mulitply <%@page language='java' import='xxx' %> allowed

   Summary: No mulitply <%@page language='java' import='xxx' %>
allowed
   Product: Tomcat 4
   Version: 4.0.4 Beta 3
  Platform: HP
OS/Version: HP-UX
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The JSP parser will throw exception in JSP page if a JSP page have more than
one 
<%@page language='java' import='xxx' %> in JSP page.

To get around the bug, I need to change each
<%@page language='java' import='xxx' %>

to 
<%@page import='xxx' %>.


I have tried other JSP engine like Weblogic, resin etc. Other JSP engine
have no problem to parse JSP page with more then one line
<%@page language='java' import='xxx' %>.

eg.
<%@page language='java' import='java.util.*>
<%@page language='java' import='com.sun.native.track.*>
<%@page language='java' import='com.hp.ebz.conf.*>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9399] New: - No mulitply <%@page language='java' import=

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9399

No mulitply <%@page language='java' import=

   Summary: No mulitply <%@page language='java' import=
   Product: Tomcat 4
   Version: 4.0.4 Beta 3
  Platform: HP
OS/Version: HP-UX
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java

[remm]

remm02/05/24 10:20:00

  Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
  Log:
  - Remove loop in import (the modern compiler doesn't like that, apparently).
  
  Revision  ChangesPath
  1.27  +4 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java
  
  Index: StandardServer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- StandardServer.java   22 May 2002 22:17:23 -  1.26
  +++ StandardServer.java   24 May 2002 17:20:00 -  1.27
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
 1.26 2002/05/22 22:17:23 remm Exp $
  - * $Revision: 1.26 $
  - * $Date: 2002/05/22 22:17:23 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
 1.27 2002/05/24 17:20:00 remm Exp $
  + * $Revision: 1.27 $
  + * $Date: 2002/05/24 17:20:00 $
*
* 
*
  @@ -107,7 +107,6 @@
   import org.apache.catalina.Service;
   import org.apache.catalina.Store;
   import org.apache.catalina.Valve;
  -import org.apache.catalina.core.StandardServer;
   import org.apache.catalina.core.StandardEngine;
   import org.apache.catalina.core.StandardHost;
   import org.apache.catalina.deploy.ApplicationParameter;
  @@ -132,7 +131,7 @@
* (but not required) when deploying and starting Catalina.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.26 $ $Date: 2002/05/22 22:17:23 $
  + * @version $Revision: 1.27 $ $Date: 2002/05/24 17:20:00 $
*/
   
   public final class StandardServer
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: CVS problem with SSIServlet file

[Remy Maucherat]

> Remy,
>
> I just fixed the SSiCommand.java case and have updated several times from
CVS
> without any problems.  Tomcat 4 CVS HEAD now builds fine for me.
> One of my updates did get delayed for 10-15 seconds while you had a lock
> on one of the SSI files.
>
> I no longer see an SSIServlet.java or SSiServlet.java in my local copy
> of the TOmcat 4 cvs repository.

I removed the file, but wasn't able to add it back, because of the error I
got from the server :-(

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: CVS problem with SSIServlet file

[Glenn Nielsen]

Remy,

I just fixed the SSiCommand.java case and have updated several times from CVS
without any problems.  Tomcat 4 CVS HEAD now builds fine for me.
One of my updates did get delayed for 10-15 seconds while you had a lock
on one of the SSI files.

I no longer see an SSIServlet.java or SSiServlet.java in my local copy
of the TOmcat 4 cvs repository.

I don't use WinCVS.

Regards,

Glenn

Remy Maucherat wrote:

> I was having a case problem with one file, and tried to fix it. However, I
> now have problems adding back the file. Maybe it's a WinCVS bug.
> 
> The server returned:
> assertion "key != NULL" failed: file
> "/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/hash.c", line 312
> cvs [server aborted]: received abort signal
> 
> The SSiCommand class also has bad capitalization.
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


-- 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi SSiCommand.java

[glenn]

glenn   02/05/24 09:36:03

  Removed: catalina/src/share/org/apache/catalina/ssi SSiCommand.java
  Log:
  File was not named with correct case

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi SSICommand.java

[glenn]

glenn   02/05/24 09:35:39

  Added:   catalina/src/share/org/apache/catalina/ssi SSICommand.java
  Log:
  File was not named with correct case
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSICommand.java
  
  Index: SSICommand.java
  ===
  /*
   * SSICommand.java
   * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSICommand.java,v
 1.1 2002/05/24 16:35:39 glenn Exp $
   * $Revision: 1.1 $
   * $Date: 2002/05/24 16:35:39 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */
  package org.apache.catalina.ssi;
  
  import java.io.IOException;
  import java.io.PrintWriter;
  
  /**
   * The interface that all SSI commands ( SSIEcho, SSIInclude, ...) must implement.
   * 
   * @author Bip Thelin
   * @author Dan Sandberg
   * @version $Revision: 1.1 $, $Date: 2002/05/24 16:35:39 $
   *
   */
  public interface SSICommand {
  /**
   * Write the output of the command to the writer.
   *
   * @param ssiMediator the ssi mediator
   * @param paramNames The parameter names
   * @param paramValues The parameter values
   * @param writer the writer to output to
   * @throws SSIStopProcessingException if SSI processing should be aborted
   */
  public void process(SSIMediator ssiMediator,
String[] paramNames,
String[] paramValues,
PrintWriter writer) throws SSIStopProcessingException;
  }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

CVS problem with SSIServlet file

[Remy Maucherat]

I was having a case problem with one file, and tried to fix it. However, I
now have problems adding back the file. Maybe it's a WinCVS bug.

The server returned:
assertion "key != NULL" failed: file
"/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/hash.c", line 312
cvs [server aborted]: received abort signal

The SSiCommand class also has bad capitalization.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

"jean-frederic clere" <[EMAIL PROTECTED]> wrote:
> Remy Maucherat wrote:
>>
>>> In the middle it's good, extremes (I believe) not... And since this is the
>>> second time in less than a week (Denis posted 14 times, the first time on
>>> 4/27 if I'm not wrong and Dan 7 times, the first time on 5/1), and it's
>>> starting to be a little bit "extreme" and it doesn't make me feel very
>>> comfortable...
>> 
>> You have to consider the importance and quality of the patch. In Denis'
>> case, that's why I nominated him.
>> 
>> I have yet to see trouble caused by a guy who was granted commit access, and
>> the idea is to encourage people to contribute more.
>
> Probably the status of Developer as described in the
> http://jakarta.apache.org/site/roles.html is not used correctly.
> 
> For me, if someone that brings one good patch reaches the developer rank, not
> yet the committer rank (Or are the committers too lazy to commit contributions
> from the developers?).

>From the same document you mentioned... "Committers: Developers who give
frequent and valuable contributions to a subproject of the Project can have
their status promoted to that of a "Committer" for that subproject."

Ok, we all agree that Denis gave a valuable contribution, but as far as I
can see, can we say that this is "frequent"? I honestly can't... And again,
I have _nothing_ against Dan or Dennis, actually, I would like to thank them
for their patches...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets SsiServlet.java

[remm]

remm02/05/24 09:22:35

  Removed: catalina/src/share/org/apache/catalina/servlets
SsiServlet.java
  Log:
  - I think there's a problem with the case of the filename (checking out the
whole repository didn't fix it).

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[jean-frederic clere]

Remy Maucherat wrote:
>>In the middle it's good, extremes (I believe) not... And since this is the
>>second time in less than a week (Denis posted 14 times, the first time on
>>4/27 if I'm not wrong and Dan 7 times, the first time on 5/1), and it's
>>starting to be a little bit "extreme" and it doesn't make me feel very
>>comfortable...
> 
> 
> You have to consider the importance and quality of the patch. In Denis'
> case, that's why I nominated him.
> 
> I have yet to see trouble caused by a guy who was granted commit access, and
> the idea is to encourage people to contribute more.

Probably the status of Developer as described in the 
http://jakarta.apache.org/site/roles.html is not used correctly.

For me, if someone that brings one good patch reaches the developer rank, not 
yet the committer rank (Or are the committers too lazy to commit contributions 
from the developers?).


> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Remy Maucherat]

> In the middle it's good, extremes (I believe) not... And since this is the
> second time in less than a week (Denis posted 14 times, the first time on
> 4/27 if I'm not wrong and Dan 7 times, the first time on 5/1), and it's
> starting to be a little bit "extreme" and it doesn't make me feel very
> comfortable...

You have to consider the importance and quality of the patch. In Denis'
case, that's why I nominated him.

I have yet to see trouble caused by a guy who was granted commit access, and
the idea is to encourage people to contribute more.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

"GOMEZ Henri" <[EMAIL PROTECTED]> wrote:

> Even if I vote +1 for both tomcat recent commiters,
> Benoit and Dan, I could understand Pier objections.
> 
> Benoit and Dan are new to tomcat-dev (less than 1 month)
> and mail-archive reports 32 refs to Benoit and 17 to Dan.
> 
> http://www.mail-archive.com/cgi-bin/htsearch?config=tomcat-dev_jakarta_apache_
> org&restrict=&exclude=&words=Denis+Benoit
> http://www.mail-archive.com/cgi-bin/htsearch?config=tomcat-dev_jakarta_apache_
> org&restrict=&exclude=&words=Dan+Sandberg

That is why I'm so uncomfortable... Sorry, I don't know them, and if you ask
me "would you give him commit access" (as you do with a vote), I can just
reply "well, who are they?"

This happened several times for the people down at Sun last year, and had no
problem with that, I mean, I had to see Patrick, Amy, Remy and all the
others ugly faces every day (or better, when I was awake enough to drag my
bum in the office, maybe twice a week...)

> But they were on tomcat-user for at least 1 year.

Well, that's one thing I didn't know...

> There is many factors which determine if someone
> could became commiter, proposition, code, patches
> participation in thread, user-support and duration.

Agreed wholeheartedly. From what I can see (for example) Dan has submitted
one patch, and all BillB said was "I'd like to propose Dan Sandberg (x at
cs.stanford.edu) as a new Tomcat committer.  He has already put in a great
deal of work in re-factoring the SSIServlet in Tomcat 4.x, and seems to be
willing to further contribute to working on this."

That's all I know... Someone throw me a bone down here...

> BTW, I think that a mandatory factor is duration,
> people should be granted to commiter level after
> a certain time of presence and activity in
> developper list.

It's not a "requirement" for me, but surely it would ease up things when
coming up and deciding whether to give someone committer access... At least
I would know who I'm talking about.

That's also why I keep pushing everyone (Remy and JF were slapped a couple
of times), not to send me mail privately about Tomcat, but always to the
list, it raises awareness, everyone will know where everyone stands...

> And that's why I understand Pier objections

At least for once :)

> PS: Please don't turn that thread in flam-war.

Absolutely, far from me to do that.

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9375] - JSP class loading failure with derived tags

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9375

JSP class loading failure with derived tags

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 15:30 ---
I didn't know this could also happen with Jasper 1.
It is caused because Jasper uses the classic compiler to compile the generated 
classes. Compiling with the modern compiler (which is the default on JDK 1.3 
and 1.4) by hand should fix the issue.

Jasper 2 now fixes it by using Ant.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] New Committer Dan Sandberg

[GOMEZ Henri]

>I nominated quite a few of the current tomcat commiters, and 
>each of them made important contributions to tomcat. I used the 
>same 'standards' that Bill used when proposing Dan.
>
>I believe we deserve some explanation from the 'members', I'm 
>quite unhappy about this whole issue. If there are some new 
>quantitative standards for becoming a commiter ( or a member )
>we should know about.  

Even if I vote +1 for both tomcat recent commiters,
Benoit and Dan, I could understand Pier objections.

Benoit and Dan are new to tomcat-dev (less than 1 month)
and mail-archive reports 32 refs to Benoit and 17 to Dan.

http://www.mail-archive.com/cgi-bin/htsearch?config=tomcat-dev_jakarta_apache_org&restrict=&exclude=&words=Denis+Benoit
http://www.mail-archive.com/cgi-bin/htsearch?config=tomcat-dev_jakarta_apache_org&restrict=&exclude=&words=Dan+Sandberg

But they were on tomcat-user for at least 1 year.

There is many factors which determine if someone 
could became commiter, proposition, code, patches
participation in thread, user-support and duration.

And I agree with Pier that not all factors reach
a 'critical level'.

BTW, I think that a mandatory factor is duration,
people should be granted to commiter level after
a certain time of presence and activity in 
developper list.

And that's why I understand Pier objections

PS: Please don't turn that thread in flam-war.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[nacho]

nacho   02/05/24 08:17:27

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  * EOL Problems
  * Bug: If not compiled with iis5 support in, then doesnt need to check the iis 
version at all
  
  Revision  ChangesPath
  1.19  +28 -31
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- jk_isapi_plugin.c 22 May 2002 23:48:17 -  1.18
  +++ jk_isapi_plugin.c 24 May 2002 15:17:27 -  1.19
  @@ -60,7 +60,7 @@
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Author:  Larry Isaacs <[EMAIL PROTECTED]>   *
* Author:  Ignacio J. Ortega <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.18 $   *
  + * Version: $Revision: 1.19 $   *
***/
   
   // This define is needed to include wincrypt,h, needed to get client certificates
  @@ -161,20 +161,20 @@
   if (pVer->dwFilterVersion > http_filter_revision) {
   pVer->dwFilterVersion = http_filter_revision;
   }
  -
  -#ifdef SF_NOTIFY_AUTH_COMPLETE
  +
  +#ifdef SF_NOTIFY_AUTH_COMPLETE
   
   pVer->dwFlags = SF_NOTIFY_ORDER_HIGH| 
   SF_NOTIFY_SECURE_PORT   | 
   SF_NOTIFY_NONSECURE_PORT|
   SF_NOTIFY_PREPROC_HEADERS   |
   SF_NOTIFY_AUTH_COMPLETE;
  -#else
  - pVer->dwFlags = SF_NOTIFY_ORDER_HIGH| 
  -SF_NOTIFY_SECURE_PORT   | 
  -SF_NOTIFY_NONSECURE_PORT|
  -SF_NOTIFY_PREPROC_HEADERS;   
  -#endif
  +#else
  + pVer->dwFlags = SF_NOTIFY_ORDER_HIGH| 
  +SF_NOTIFY_SECURE_PORT   | 
  +SF_NOTIFY_NONSECURE_PORT|
  +SF_NOTIFY_PREPROC_HEADERS;   
  +#endif
   
   strcpy(pVer->lpszFilterDesc, VERSION_STRING);
   
  @@ -220,18 +220,15 @@
}
   }
   }
  -#ifdef SF_NOTIFY_AUTH_COMPLETE
  +#ifdef SF_NOTIFY_AUTH_COMPLETE
   if (is_inited &&
(((SF_NOTIFY_PREPROC_HEADERS == dwNotificationType) && !iis5) ||
  ((SF_NOTIFY_AUTH_COMPLETE   == dwNotificationType) &&  iis5)
  )
)
  -#else
  - if (is_inited &&
  - (((SF_NOTIFY_PREPROC_HEADERS == dwNotificationType) && !iis5) 
  -   )
  - )
  -#endif
  +#else
  + if (is_inited && (SF_NOTIFY_PREPROC_HEADERS == dwNotificationType))
  +#endif
{ 
   char uri[INTERNET_MAX_URL_LENGTH]; 
   char snuri[INTERNET_MAX_URL_LENGTH]="/";
  @@ -248,21 +245,21 @@
   DWORD szHost = sizeof(Host);
   DWORD szTranslate = sizeof(Translate);
   
  -#ifdef SF_NOTIFY_AUTH_COMPLETE
  - if (iis5) {
  - 
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)->GetHeader;
  - 
SetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)->SetHeader;
  - 
AddHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)->AddHeader;
  - } else {
  - 
GetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->GetHeader;
  - 
SetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->SetHeader;
  - 
AddHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->AddHeader;
  - }
  -#else
  - 
GetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->GetHeader;
  - 
SetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->SetHeader;
  - 
AddHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->AddHeader;
  -#endif
  +#ifdef SF_NOTIFY_AUTH_COMPLETE
  + if (iis5) {
  + 
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)->GetHeader;
  + 
SetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)->SetHeader;
  + 
AddHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)->AddHeader;
  + } else {
  + 
GetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->GetHeader;
  + 
SetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->SetHeader;
  + 
AddHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->AddHeader;
  + }
  +#else
  + 
GetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)->GetHeader;
  + 
SetHeade

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> That leaves me perplexed for several reasons...
> 
> First, it's the first time I see a commiter rejected - without any
> reference to the quality and importance of his contribution, but some
> new "member's" standard we don't know about. Dan put the SSI system in a
> decent shape, that's similar with the contributions many others have
> done to become commiters.
> 
> Second, if the 'members' and/or PMC has anything to say, I believe
> it should do it directly and in a public forum. Beeing talked about
> behind our back is not very comfortable.
> 
> I nominated quite a few of the current tomcat commiters, and
> each of them made important contributions to tomcat. I used the
> same 'standards' that Bill used when proposing Dan.
> 
> I believe we deserve some explanation from the 'members', I'm
> quite unhappy about this whole issue. If there are some new
> quantitative standards for becoming a commiter ( or a member )
> we should know about.

The ASF members didn't impose any standard. Read my mail on _why_ I CCed the
members list (I just explained it, the "issue" of bars and such was brought
up, meaning that there's interest) and I'd like to do some cross-project
pollination

Dan made some excellent contribution to the SSIServlet, great, but on my
archive, I can see that he posted 7 times to the list, and the first time
exactly 24 days ago.

He sent a patch, thank you, but in my book this is far for being a member of
the developers community. I'm just uncomfortable with the bar set by this
community to accept new committers in, and since nothing gets discussed
unless someone does something "outrageous" like voting -1 on a new
committer, well, there's no better troublemaker than me to do it :)

Pier
 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk

[costinm]

On Fri, 24 May 2002, jean-frederic clere wrote:

> > I did that to get rid of the conditional compilation of files and 
> > simplify the makefiles, all files must be compiled.
> 
> 
> Sure if jk_channel_jni.o is not linked in mod_jk2.so jk2_channel_jni_factory is 
> unresolved!

If HAVE_JNI is undefined, a dummy factory will be linked in ( that will 
just mark the component as disabled ).

This also allows the config system to maintain the configuration for the 
component.

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[costinm]

That leaves me perplexed for several reasons...

First, it's the first time I see a commiter rejected - without any
reference to the quality and importance of his contribution, but some
new "member's" standard we don't know about. Dan put the SSI system in a 
decent shape, that's similar with the contributions many others have 
done to become commiters.

Second, if the 'members' and/or PMC has anything to say, I believe
it should do it directly and in a public forum. Beeing talked about
behind our back is not very comfortable. 

I nominated quite a few of the current tomcat commiters, and 
each of them made important contributions to tomcat. I used the 
same 'standards' that Bill used when proposing Dan.

I believe we deserve some explanation from the 'members', I'm 
quite unhappy about this whole issue. If there are some new 
quantitative standards for becoming a commiter ( or a member )
we should know about.  


Costin

On Fri, 24 May 2002, Pier Fumagalli wrote:

> "Bill Barker" <[EMAIL PROTECTED]> wrote:
> 
> > I'd like to propose Dan Sandberg (x at cs.stanford.edu) as a new Tomcat
> > committer.  He has already put in a great deal of work in re-factoring the
> > SSIServlet in Tomcat 4.x, and seems to be willing to further contribute to
> > working on this.
> 
> -1 Sorry, but 7 messages posted to the -dev mailing list, and two
> patches don't make him reach my bar...
> 
> I hate to be the PITA, as always, and I don't have anything against Dan or
> the patches he submitted to SSIServlet, but I believe that this group (as
> noted on the members meeting this Tuesday) is giving away committer
> privileges a little bit too easily...
> 
> That's my $ 0.02 anyway...
> 
> Pier
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

"Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Pier Fumagalli wrote:
>> 
>> I hate to be the PITA, as always, and I don't have anything against Dan
>> or the patches he submitted to SSIServlet, but I believe that this group
>> (as noted on the members meeting this Tuesday) is giving away committer
>> privileges a little bit too easily...
> 
> Different Apache projects (and subprojects thereof) have different bars.  I
> am actually quite at peace with this notion.

Same here...

> I got committer status to PHP years ago merely by sending an e-mail on an
> idea I wanted to pursue.  At the time, I knew nothing about cvs.

Good, so there are projects even more "loose" than tomcat dev... I didn't
know that, Rasmus might comment???

> Later I got committer status on Tomcat.  I distinctly recall this being on
> the theory that any damage I might do could easily be undone.

Oh, yes, it can... That's not a problem, technically. I've never seen a
rollback in CVS happening in all those years, but it can be easily done.

> My point isn't that Tomcat should have a lower bar, but that the Tomcat
> committers should be free to determine their own bar.

I'm fine with a loose policy on giving committer status, I'm fine with the
difference (for example) between tomcat-dev and httpd-dev, but as I wouldn't
be fine if the httpd folks stopped giving committer status to anyone, and
closing the group (httpd has a very high bar, but they are not a closed
group), at the same time I am not happy with people posting one or two
times, maybe one patch, and having access to our repository...

In the middle it's good, extremes (I believe) not... And since this is the
second time in less than a week (Denis posted 14 times, the first time on
4/27 if I'm not wrong and Dan 7 times, the first time on 5/1), and it's
starting to be a little bit "extreme" and it doesn't make me feel very
comfortable...

I believe I'm the only one who removed himself from the "avail" file at one
point or another, and removed his committer status in projects I wasn't
involved in anymore (I wrote the first draft on Cocoon 2, was a committer,
not anymore since a very long time)

All I'm trying to do is raise awareness over something I (personally) am not
comfortable with, on the mailing list, where everyone can see, asking to my
fellow  co-committers "what do you think"...

I CCed the members list because I know that there is interest over there (we
talked about it at the members meeting), and because I would like to hear
also from other people involved in other projects and who maybe (for sure)
have much more experience than me...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
> On Fri, 24 May 2002, jean-frederic clere wrote:
> 
> 
>>>  ${JK}jk_channel_jni${OEXT}\
>>
>>That would require to have J2SE to compile mod_jk2.
> 
> 
> No, it has an 
> 
> #ifdef HAVE_JNI
>   // jni-specific code
> 
> #else
>  // empty factory
> #endif
> 
> I did that to get rid of the conditional compilation of files and 
> simplify the makefiles, all files must be compiled.


Sure if jk_channel_jni.o is not linked in mod_jk2.so jk2_channel_jni_factory is 
unresolved!
Sorry Henri my comment was a very bad one.

> 
> Based on HAS_APR and HAVE_JNI some sections of code will not 
> be compiled.
> 
> Costin
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

unit testing?

[Immanuel, Gidado-Yisa]

I'm tryinng to write a patch for several bugs listed in Bugzilla.
Was wondering about Junit tests...since I only saw 5 TestCases,
it would seem that testing via junit + ant is not really part of the tomcat4
development process.

Also, in catalina/build.xml, all the test cases are enumerated, instead
of pattern matching on "*TestCase.java".  This means lots of overhead
to add a new test (i.e. update the build.xml file every time a new test is
added.  (I can make a patch for this too, if anyone would like).

So the question is, should I bother to submit junit test cases?

Thanks,
Gidado



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9390] New: - jasper compilation error in tomcat

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9390

jasper compilation error in tomcat

   Summary: jasper compilation error in tomcat
   Product: Tomcat 3
   Version: 3.2.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

I'm having a strange problem: our application is a servlet application using 
Struts and JSP (running in Tomcat 3.2 on a Windows NT4 SP 6 dual processor 
server). The application seems to work fine in normal circumstances (single 
user and multi-user tests have been performed). Recently we did a training 
session of our application with 10 users simultaneously doing the same actions 
(pressing same buttons in the application etc). All of a sudden 1 of the 10 
users received an exception (it appeared to be a jasper compilation error, cf. 
end of message for full exception). All the other users received the same page 
without any problem and the one user that received the error, was able to 
recover by just pressing the reload button of IE. But I'm wondering why this 
could have been caused. The JSP page should normally compiles correctly (it has 
to be correct syntax as all other users received the same page without any 
problem). Might this be a concurrency problem in tomcat or jasper? Is this a 
known issue?

This is the full exception:

Error: 500
Location: /ap2/profile_interview/income_summary.jsp
Internal Servlet Error:

org.apache.jasper.JasperException: Unable to compile class for 
JSPC:\tomcat\work\localhost_8080%2Fap2
\_0002fprofile_0005finterview_0002fincome_0005fsummary_0002ejspincome_0005fsumma
ry_jsp_0.java:452: Invalid expression statement.

^
C:\tomcat\work\localhost_8080%2Fap2
\_0002fprofile_0005finterview_0002fincome_0005fsummary_0002ejspincome_0005fsumma
ry_jsp_0.java:452: ';' expected.

^
C:\tomcat\work\localhost_8080%2Fap2
\_0002fprofile_0005finterview_0002fincome_0005fsummary_0002ejspincome_0005fsumma
ry_jsp_0.java:452: '}' expected.

^
3 errors

at org.apache.jasper.compiler.Compiler.compile(Compiler.java:254)
at org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:462)
at org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:146)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:433)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary
(JspServlet.java:152)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service
(JspServlet.java:164)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at org.apache.tomcat.facade.RequestDispatcherImpl.forward
(RequestDispatcherImpl.java:194)
at s1.struts.component.ActionComponentServlet.processForward
(ActionComponentServlet.java:223)
at s1.struts.component.ActionComponentServlet.processActionForward
(ActionComponentServlet.java:99)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1584)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:490)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at org.apache.tomcat.core.ContextManager.internalService
(ContextManager.java:797)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection
(HttpConnectionHandler.java:210)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)

Thanks for your help!

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9386] - JSP Include ignoring parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9386

JSP Include ignoring parameter





--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 14:04 ---
*** Bug 9388 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9388] - JSP include ignores parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9388

JSP include ignores parameter

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 14:04 ---


*** This bug has been marked as a duplicate of 9386 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk

[GOMEZ Henri]

>I did that to get rid of the conditional compilation of files and 
>simplify the makefiles, all files must be compiled.
>
>Based on HAS_APR and HAVE_JNI some sections of code will not 
>be compiled.

Hum, what make me think that I could avoid to handle 
COMMON_OBJECTS and COMMON_APR_OBJECTS ?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9388] New: - JSP include ignores parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9388

JSP include ignores parameter

   Summary: JSP include ignores parameter
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In this example test.jsp includes header.jsp with a parameter.
But the parameter is missing in the request object in header.jsp.
Works with <% request.setAttribute( "testparam", "1" ); %> instead of param tag.

test.jsp:






header.jsp:
<%
java.util.Enumeration enum = request.getAttributeNames();
while( enum.hasMoreElements() ) 
{   out.println( enum.nextElement() );  }
%>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk

[costinm]

On Fri, 24 May 2002, jean-frederic clere wrote:

> >   ${JK}jk_channel_jni${OEXT}\
> 
> That would require to have J2SE to compile mod_jk2.

No, it has an 

#ifdef HAVE_JNI
  // jni-specific code

#else
 // empty factory
#endif

I did that to get rid of the conditional compilation of files and 
simplify the makefiles, all files must be compiled.

Based on HAS_APR and HAVE_JNI some sections of code will not 
be compiled.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9384] - Tomcat hangs after out of memory error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9384

Tomcat hangs after out of memory error

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 13:55 ---
There is known memory leaks in Tomcat 3.2.1, so you should really upgrade to 
Tomcat 3.3.1 or Tomcat 4.0.3

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9386] - JSP Include ignoring parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9386

JSP Include ignoring parameter





--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 13:55 ---
Shouldn't it be request.getParameterNames() and getParameter() 
instead of getAttributeNames() and getAttribute()

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5603] - ServletContext.getResourcePaths() returns extra slashes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5603

ServletContext.getResourcePaths() returns extra slashes





--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 13:50 ---
http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java?rev=1.33&content-type=text/vnd.viewcvs-markup

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9386] - JSP Include ignoring parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9386

JSP Include ignoring parameter





--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 13:49 ---
*** Bug 9387 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9387] - JSP Include ignoring parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9387

JSP Include ignoring parameter

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 13:49 ---


*** This bug has been marked as a duplicate of 9386 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] New Committer Dan Sandberg

[Sam Ruby]

Pier Fumagalli wrote:
>
> I hate to be the PITA, as always, and I don't have anything against Dan
or
> the patches he submitted to SSIServlet, but I believe that this group (as
> noted on the members meeting this Tuesday) is giving away committer
> privileges a little bit too easily...

Different Apache projects (and subprojects thereof) have different bars.  I
am actually quite at peace with this notion.

I got committer status to PHP years ago merely by sending an e-mail on an
idea I wanted to pursue.  At the time, I knew nothing about cvs.

Later I got committer status on Tomcat.  I distinctly recall this being on
the theory that any damage I might do could easily be undone.

My point isn't that Tomcat should have a lower bar, but that the Tomcat
committers should be free to determine their own bar.

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9386] - JSP Include ignoring parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9386

JSP Include ignoring parameter

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9387] New: - JSP Include ignoring parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9387

JSP Include ignoring parameter

   Summary: JSP Include ignoring parameter
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In this example header.jsp is included in test.jsp with a parameter.
But the parameter is missing in the request object in the included jsp.
Setting the parameter directly with 
<% request.setAttribute( "testparam", "1" ); %> works. 

test.jsp:

title







BODY





header.jsp:
<%
java.util.Enumeration enum = request.getAttributeNames();
while( enum.hasMoreElements() ) 
{
   out.println( enum.nextElement() );   
}
%>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9386] New: - JSP Include ignoring parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9386

JSP Include ignoring parameter

   Summary: JSP Include ignoring parameter
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


test.jsp:

title







BODY





header.jsp:
<%
java.util.Enumeration enum = request.getAttributeNames();
while( enum.hasMoreElements() ) 
{
out.println( enum.nextElement() );  
}
%>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9384] New: - Tomcat hangs after out of memory error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9384

Tomcat hangs after out of memory error

   Summary: Tomcat hangs after out of memory error
   Product: Tomcat 3
   Version: 3.2.1 Final
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

We are using FOP (version 0.20.3 from Apache) to generate reports (+/- 15 
pages) in our web application. Sometimes this results in an out of memory error 
when doing a 10 user stress test. Whenever this happens, tomcat seems to hang 
(no responses anymore to any of the 10 clients).

Is this a known problem that Tomcat stops responding after an out of memory? Is 
FOP or XSLT or the combination of both possibly causing the problem?

More detailed description of the situation:

I use Xalan (version 2.2.D14) to convert an XML file to FO (XSLT file is 
including some calls to java classes to generate gif files with charts). After 
generating the FO file and gif files, the FOP processor transforms it to PDF. 
Both XSLT and FOP are very memory consuming and after a few hours of stress 
testing (a few hundreds of generated reports) we get an out of memory error 
signaled in the tomcat box and tomcat stops responding to all 10 clients. The 
max. heap size of the Java VM (Sun JDK1.3) is set to 256Mb. We are working on 
Windows 2000 prof. 

Can anyone help me with this problem?

Regards,

Dominique De Ridder

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

jtc Build Fails

[Anthony W. Marino]

"j-t-c/ ant" against latest/previous cvs source has exhibited this:

BUILD FAILED
/usr/local/src/tc4conndir/jakarta-tomcat-connectors/build.xml:17: 
/usr/local/src/tc4conndir/jakarta-tomcat-connectors/jk/build/WEB-INF/classes 
not found.


I don't ever see anything in this directory, however, I've been adding a 
"mkdir" line to "j-t-c/jk/ build.xml" to add the above.

Thanks,
Anthony


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9382] New: - IOException: Cannot find message associated with key 'responseStream.suspended'

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9382

IOException: Cannot find message associated with key 'responseStream.suspended'

   Summary: IOException: Cannot find message associated with key
'responseStream.suspended'
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I recurrently get an IOException with the following stack trace.
This happens under heavy load on the the Tomcat server and while processing
requests with a large amount of data in the request body (>= 512KB):

java.io.IOException: Cannot find message associated with key 'responseStream.sus
pended'
at org.apache.catalina.connector.http.HttpResponseStream.close(HttpRespo
nseStream.java:202)
at com.ceyoniq.celink.httpcs.ContentServlet.service(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2343)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:180)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
468)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso
r.java:1012)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja
va:1107)
at java.lang.Thread.run(Thread.java:484)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer Dan Sandberg

[Pier Fumagalli]

"Bill Barker" <[EMAIL PROTECTED]> wrote:

> I'd like to propose Dan Sandberg (x at cs.stanford.edu) as a new Tomcat
> committer.  He has already put in a great deal of work in re-factoring the
> SSIServlet in Tomcat 4.x, and seems to be willing to further contribute to
> working on this.

-1 Sorry, but 7 messages posted to the -dev mailing list, and two
patches don't make him reach my bar...

I hate to be the PITA, as always, and I don't have anything against Dan or
the patches he submitted to SSIServlet, but I believe that this group (as
noted on the members meeting this Tuesday) is giving away committer
privileges a little bit too easily...

That's my $ 0.02 anyway...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 6621] - mod_webapp hangs when transmitting binary (eg. image) files

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6621

mod_webapp hangs when transmitting binary (eg. image) files





--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 10:41 ---
Pointless to reply on a bug marked duplicate of something else, which is 
clearly not going to be fixed anytime soon.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk

[GOMEZ Henri]

>>   ===
>>   ## Object needed for mod_jk for Apache
>>   COMMON_OBJECTS= \
>>   ${JK}jk_channel_jni${OEXT}\
>
>That would require to have J2SE to compile mod_jk2.
>

What do you means ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9375] New: - JSP class loading failure with derived tags

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9375

JSP class loading failure with derived tags

   Summary: JSP class loading failure with derived tags
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have created an own tag that is derived from the standard struts  
tag. If i use this tag on a JSP page, the generated servlet class sometimes 
will not be loaded because of a:
java.lang.VerifyError: (class: org/apache/jsp/flogon$jsp, method: _jspService 
signature: 
(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;
)V) Incompatible object argument for method call
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:254)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.load 
(JspServlet.java:139)
I tried to isolate the cause and after i added overrides for the used 
getXxx/setXxx functions of the tag (simply calling the superfunction), the 
verify passed and everything worked (so the classloader must have been always 
able to locate the used classes - in fact, if i used "simple" tags of the same 
packages, the problem never occured). Unfortunately the error does not appear 
always, so i am not sure that i found the cause or if it's some side effect 
workaround. What exactly is verified by which class loader on the load of a JSP 
servlet class?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2 buildconf.sh

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
> 
> hgomez  02/05/24 00:07:23
> 
>   Modified:jk/native2 buildconf.sh
>   Log:
>   Update buildconf.sh
>   Note that we use automake not to generate makefiles
>   but to copy install(s) stuff

Oops, I broke native too yesterday.

> 
>   Revision  ChangesPath
>   1.5   +4 -2  jakarta-tomcat-connectors/jk/native2/buildconf.sh
> 
>   Index: buildconf.sh
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/buildconf.sh,v
>   retrieving revision 1.4
>   retrieving revision 1.5
>   diff -u -r1.4 -r1.5
>   --- buildconf.sh  23 May 2002 09:00:45 -  1.4
>   +++ buildconf.sh  24 May 2002 07:07:23 -  1.5
>   @@ -1,7 +1,9 @@
>#!/bin/sh
> 
>   -echo "libtoolize --force --copy"
>   -libtoolize --force --copy
>   +echo "libtoolize --force --automake"
>   +libtoolize --force --automake
>   +echo "automake --copy --add-missing"
>   +automake --copy --add-missing
>echo "aclocal"
>aclocal
>echo "autoconf"
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
> 
> hgomez  02/05/24 00:18:31
> 
>   Added:   jk/native2/common list.mk
>   Log:
>   list.mk contains list of modules to be built,
>   COMMON_OBJECTS and COMMON_APR_OBJECTS.
>   Like this we could build jk2 for Apache 1.3 with/without APR
> 
>   Revision  ChangesPath
>   1.1  jakarta-tomcat-connectors/jk/native2/common/list.mk
> 
>   Index: list.mk
>   ===
>   ## Object needed for mod_jk for Apache
>   COMMON_OBJECTS= \
>   ${JK}jk_channel_jni${OEXT}\

That would require to have J2SE to compile mod_jk2.

>   ${JK}jk_channel_socket${OEXT}\
>   ${JK}jk_channel_un${OEXT}\
>   ${JK}jk_config${OEXT}\
>   ${JK}jk_endpoint${OEXT}\
>   ${JK}jk_env${OEXT}\
>   ${JK}jk_handler_logon${OEXT}\
>   ${JK}jk_handler_response${OEXT}\
>   ${JK}jk_logger_file${OEXT}\
>   ${JK}jk_map${OEXT}\
>   ${JK}jk_md5${OEXT}\
>   ${JK}jk_msg_ajp${OEXT}\
>   ${JK}jk_mutex${OEXT}\
>   ${JK}jk_nwmain${OEXT}\
>   ${JK}jk_objCache${OEXT}\
>   ${JK}jk_pool${OEXT}\
>   ${JK}jk_registry${OEXT}\
>   ${JK}jk_requtil${OEXT}\
>   ${JK}jk_shm${OEXT}\
>   ${JK}jk_uriEnv${OEXT}\
>   ${JK}jk_uriMap${OEXT}\
>   ${JK}jk_vm_default${OEXT}\
>   ${JK}jk_worker_ajp13${OEXT}\
>   ${JK}jk_workerEnv${OEXT}\
>   ${JK}jk_worker_jni${OEXT}\
>   ${JK}jk_worker_lb${OEXT}\
>   ${JK}jk_worker_run${OEXT}\
>   ${JK}jk_worker_status${OEXT}
> 
>   COMMON_APR_OBJECTS= \
>   ${JK}jk_channel_apr_socket${OEXT} \
>   ${JK}jk_pool_apr${OEXT}
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 Makefile.in

[GOMEZ Henri]

That's fixed problem with libtool.

Nota, I also used -L${APACHE2_LIBDIR} instead of 
-L${APACHE2_HOME}/lib

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 24, 2002 10:11 AM
>To: [EMAIL PROTECTED]
>Subject: cvs commit: 
>jakarta-tomcat-connectors/jk/native2/server/apache2
>Makefile.in
>
>
>hgomez  02/05/24 01:11:19
>
>  Modified:jk/native2/server/apache2 Makefile.in
>  Log:
>  Fixed the problem with libtool by just removing -lapr dep
>  in Apache 2.0, apr shared lib is allways present
>  
>  Revision  ChangesPath
>  1.5   +2 -1  
>jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.in
>  
>  Index: Makefile.in
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/M
>akefile.in,v
>  retrieving revision 1.4
>  retrieving revision 1.5
>  diff -u -r1.4 -r1.5
>  --- Makefile.in  24 May 2002 07:21:24 -  1.4
>  +++ Makefile.in  24 May 2002 08:11:19 -  1.5
>  @@ -5,6 +5,7 @@
>   OS=@OS@
>   JAVA_HOME=@JAVA_HOME@
>   APACHE2_INCL=@APACHE2_INCL@
>  +APACHE2_LIBDIR=@APACHE2_LIBDIR@
>   APR_INCL=@APR_CFLAGS@ 
>   EXTRA_CFLAGS=@APXS2_CFLAGS@
>   EXTRA_CPPFLAGS=@APXS2_CPPFLAGS@
>  @@ -31,7 +32,7 @@
> ${JAVA_INCL}
>   
>   JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAVE_JNI
>  -JK_LDFLAGS=-L${APACHE2_HOME}/lib -lapr -lcrypt
>  +JK_LDFLAGS=-L${APACHE2_LIBDIR} -lcrypt
>   
>   ## Based on rules.mk ##
>   ALL_CFLAGS   = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
>  
>  
>  
>
>--
>To unsubscribe, e-mail:   

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 Makefile.in

[hgomez]

hgomez  02/05/24 01:11:19

  Modified:jk/native2/server/apache2 Makefile.in
  Log:
  Fixed the problem with libtool by just removing -lapr dep
  in Apache 2.0, apr shared lib is allways present
  
  Revision  ChangesPath
  1.5   +2 -1  jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.in,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- Makefile.in   24 May 2002 07:21:24 -  1.4
  +++ Makefile.in   24 May 2002 08:11:19 -  1.5
  @@ -5,6 +5,7 @@
   OS=@OS@
   JAVA_HOME=@JAVA_HOME@
   APACHE2_INCL=@APACHE2_INCL@
  +APACHE2_LIBDIR=@APACHE2_LIBDIR@
   APR_INCL=@APR_CFLAGS@ 
   EXTRA_CFLAGS=@APXS2_CFLAGS@
   EXTRA_CPPFLAGS=@APXS2_CPPFLAGS@
  @@ -31,7 +32,7 @@
 ${JAVA_INCL}
   
   JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAVE_JNI
  -JK_LDFLAGS=-L${APACHE2_HOME}/lib -lapr -lcrypt
  +JK_LDFLAGS=-L${APACHE2_LIBDIR} -lcrypt
   
   ## Based on rules.mk ##
   ALL_CFLAGS   = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 6374] - class not find for:org/w3c/dom/range/Range

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6374

class not find for:org/w3c/dom/range/Range





--- Additional Comments From [EMAIL PROTECTED]  2002-05-24 07:48 ---
4.0.4b3 works ootb.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: autoconf support for native2

[GOMEZ Henri]

But module build via apxs works well

cd server/apache13
make -f Makefile.apxs

cd server/apache2 (without jni)
make -f Makefile.apxs

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

autoconf support for native2

[GOMEZ Henri]

Hi to all,

Just commited the updated works on autoconf for
native2.

1) I removed support for static build, since I'm
   still waiting for informations on how to do this.


usage :

cd jk/native2
./buildconf.sh

to build against apache 1.3 without apr
./configure --with-apxs=/sbin/apxs 
make

to build against apache 1.3 without apr 
and apache 2.0 (with apr it's included)
./configure --with-apxs=/sbin/apxs --with-apxs2=/sbin/apxs2
make

to build against apache 1.3 with static apr present 
somewhere 
./configure --with-apxs=/sbin/apxs --with-apr=somewhere
make

BTW: I still have a problem with apache 2.0 make which 
 fail when use libtool from apache2 built but works
 with system libtool.

+ add=
+ test no = yes
+ test no = yes
+ test unsupported = yes
+ add_dir=-L/usr/lib
+ add=-lapr
+ test prog = prog
+ test -n -L/usr/lib
+ finalize_deplibs=-L/usr/lib -L/usr/lib/apache2 
+ test -n -lapr
+ finalize_deplibs=-lapr -L/usr/lib -L/usr/lib/apache2 
+ test prog = lib
+ lib=
+ found=no
+ test no = yes
+ test -f 
+ echo libtool: link: cannot find the library `'
libtool: link: cannot find the library `'
+ exit 1
make: *** [../../../build/jk2/apache2/mod_jk2.so] Error 1

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 Makefile.apxs.in Makefile.in

[hgomez]

hgomez  02/05/24 00:21:24

  Modified:jk/native2/server/apache13 Makefile.apxs.in Makefile.in
   jk/native2/server/apache2 Makefile.apxs.in Makefile.in
  Log:
  Updated Makefiles
  Nota, that in Apache 1.3, we get list of common's files from common/list.mk
  
  Revision  ChangesPath
  1.4   +13 -7 
jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.apxs.in
  
  Index: Makefile.apxs.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.apxs.in,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Makefile.apxs.in  17 May 2002 00:31:54 -  1.3
  +++ Makefile.apxs.in  24 May 2002 07:21:24 -  1.4
  @@ -1,22 +1,28 @@
   ## configure should make the Makefile out of this file.
   
  +## include all files to be built in common, with or without apr's
  +## read the object (.c) from the list file.
  +include ../../common/list.mk
  +OEXT=.c
  +
   APXS=@APXS@
   OS=@OS@
  -APXSLDFLAGS=@APXSLDFLAGS@
  -APXSCFLAGS=@APXSCFLAGS@
  +APXS_LDFLAGS=@APXS_LDFLAGS@
  +APXS_CFLAGS=@APXS_CFLAGS@
  +JK_OBJECTS=${COMMON_OBJECTS} @COMMON_APR_OBJECTS@
  +APR_CFLAGS=@APR_CFLAGS@
  +APR_LDFLAGS=@APR_LDFLAGS@
   
   JK=../../common/
   JKINC=../../include/
   JK_INCL=-DUSE_APACHE_MD5 -I ${JK} -I ${JKINC} -DHAVE_MMAP
  -
  -## read the object (.c) from the list file.
  -OEXT=.c
  -include ../../common/list.mk
  +JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
  +JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
   
   all: mod_jk2.so
   
   mod_jk2.so: 
  - $(APXS) -c -o $@ -Wc,"${APXSCFLAGS} ${JK_INCL}" "${APXSLDFLAGS}" mod_jk2.c 
${APACHE_OBJECTS} 
  + $(APXS) -c -o $@ -Wc,"${JK_INCL} ${APR_CFLAGS} ${APR_LDFLAGS}" "${JAVA_INCL}" 
mod_jk2.c ${JK_OBJECTS} 
   
   clean:
rm -f *.o *.so
  
  
  
  1.4   +12 -8 jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Makefile.in   16 May 2002 23:50:12 -  1.3
  +++ Makefile.in   24 May 2002 07:21:24 -  1.4
  @@ -1,12 +1,16 @@
   # Gnu makefile and libtool are required
   # use -D options to overrides defaults
   
  +JK=../../common/
  +OEXT=.c
  +include ../../common/list.mk
  +
   APACHE_HOME=@APACHE_HOME@
   OS=@OS@
   APACHE_INCL=@APACHE_INCL@
  -APR_INCL=@APR_INCL@
  -EXTRA_CFLAGS=@EXTRA_CFLAGS@
  -EXTRA_CPPFLAGS=@EXTRA_CPPFLAGS@
  +EXTRA_CFLAGS=@APXS_CFLAGS@
  +EXTRA_CPPFLAGS=@APXS_CPPFLAGS@
  +JK_OBJECTS=${COMMON_OBJECTS} ${COMMON_APR_OBJECTS}
   
   JK_DIR := ../..
   BUILD_DIR = ${JK_DIR}/../build/jk2/apache13
  @@ -15,10 +19,9 @@
   
   # It doesn't hurt if we include all
   INCLUDES= -I${JK_DIR}/include \
  -  ${APACHE_INCL} \
  -  ${APR_INCL} 
  +  ${APACHE_INCL}
   
  -JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 @HAS_APR@ @APR_INCL@ -DHAVE_MMAP
  +JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 @APR_CFLAGS@ -DHAVE_MMAP
   JK_LDFLAGS=-L${APACHE_HOME}/lib -lcrypt @APR_LDFLAGS@
   
   ## Based on rules.mk ##
  @@ -40,7 +43,8 @@
   # Same behavior as ant - 'all files from a dir'. 
   # Excludes are not yet implemented.
   
  -COMMON_C_FILES := $(wildcard ${JK_DIR}/common/*.c )
  +#COMMON_C_FILES := $(wildcard ${JK_DIR}/common/*.c )
  +COMMON_C_FILES = ${JK_OBJECTS}
   A_C_FILES := $(wildcard ${JK_DIR}/server/apache13/*.c )
   H_FILES := $(wildcard ${JK_DIR}/include/*.h )
   
  @@ -72,7 +76,7 @@
   all: prepare ${BUILD_DIR}/mod_jk2.so 
   
   ${BUILD_DIR}/mod_jk2.so: ${COMMON_LO_FILES} ${A_LO_FILES}
  - ${MOD_LINK} -o $@ $^ @APR_LIB_STATIC@
  + ${MOD_LINK} -o $@ $^ @APR_LDFLAGS@
   
   ${COMMON_C_FILES} ${A_C_FILES}: ${H_FILES}
   
  
  
  
  1.4   +7 -5  
jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.apxs.in
  
  Index: Makefile.apxs.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/Makefile.apxs.in,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Makefile.apxs.in  17 May 2002 00:31:55 -  1.3
  +++ Makefile.apxs.in  24 May 2002 07:21:24 -  1.4
  @@ -1,27 +1,29 @@
   ## configure should make the Makefile out of this file.
   
  -APXS=@APXS@
  +APXS=@APXS2@
   OS=@OS@
   JAVA_HOME=@JAVA_HOME@
  -APXSLDFLAGS=@APXSLDFLAGS@
  -APXSCFLAGS=@APXSCFLAGS@
  +APXS_LDFLAGS=@APXS2_LDFLAGS@
  +APXS_CFLAGS=@APXS2_CFLAGS@
   
   JK=../../common/
   JKINC=../../include/
  -JK_INCL=-DUSE_APACHE_MD5 -I ${JK} -I ${JKINC} @HAS_APR@
  +JK_INCL=-DUSE_APACHE_MD5 -I ${JK} -I ${JKINC} -DHAS_APR
   JAVA_INCL=-I ${JAVA_H

cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk

[hgomez]

hgomez  02/05/24 00:18:31

  Added:   jk/native2/common list.mk
  Log:
  list.mk contains list of modules to be built,
  COMMON_OBJECTS and COMMON_APR_OBJECTS.
  Like this we could build jk2 for Apache 1.3 with/without APR
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/jk/native2/common/list.mk
  
  Index: list.mk
  ===
  ## Object needed for mod_jk for Apache
  COMMON_OBJECTS= \
  ${JK}jk_channel_jni${OEXT}\
  ${JK}jk_channel_socket${OEXT}\
  ${JK}jk_channel_un${OEXT}\
  ${JK}jk_config${OEXT}\
  ${JK}jk_endpoint${OEXT}\
  ${JK}jk_env${OEXT}\
  ${JK}jk_handler_logon${OEXT}\
  ${JK}jk_handler_response${OEXT}\
  ${JK}jk_logger_file${OEXT}\
  ${JK}jk_map${OEXT}\
  ${JK}jk_md5${OEXT}\
  ${JK}jk_msg_ajp${OEXT}\
  ${JK}jk_mutex${OEXT}\
  ${JK}jk_nwmain${OEXT}\
  ${JK}jk_objCache${OEXT}\
  ${JK}jk_pool${OEXT}\
  ${JK}jk_registry${OEXT}\
  ${JK}jk_requtil${OEXT}\
  ${JK}jk_shm${OEXT}\
  ${JK}jk_uriEnv${OEXT}\
  ${JK}jk_uriMap${OEXT}\
  ${JK}jk_vm_default${OEXT}\
  ${JK}jk_worker_ajp13${OEXT}\
  ${JK}jk_workerEnv${OEXT}\
  ${JK}jk_worker_jni${OEXT}\
  ${JK}jk_worker_lb${OEXT}\
  ${JK}jk_worker_run${OEXT}\
  ${JK}jk_worker_status${OEXT}
  
  COMMON_APR_OBJECTS= \
  ${JK}jk_channel_apr_socket${OEXT} \
  ${JK}jk_pool_apr${OEXT}
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: