JK 1.2.26 ?

[Henri Gomez]

Hi to all,

When should jk 1.2.26 should be released ?

Did there is still showstoppers ?

Regards

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

Tomcat and SessionHandling

[Preuss, Jacqueline - ENCOWAY]

Hi, I'm new here!

 

Generally, I'm new in the topic servlets etc. so I hope I can explain my 
problem well.

 

In our company we work with some web applications running in Internet Explorer. 
We want to use Tomcat as servlet engine / webserver. The problem is the session 
handling of Tomcat. For the application the user authenticates with username, 
password and domain (i.e. windows authentication). The user can select 
different items in the application e.g. quotes. Every quote is opened in a new 
browser window. If we use Tomcat, all quotes of the user are saved under the 
same session, i.e. the session id is always the same. That's a problem for us, 
because we need a new session for every single quote. So, is there a 
possibility to implement our own session handling for Tomcat. If yes, how? What 
would you suggest? Can we use a filter for tomcat the renew or clear the 
session?

 

I hope this is the right place to post. Thanks for help.

 

Regards,

Jacqueline Preuß.

 

Re: [VOTE] Make released versions RTC

[Jim Jagielski]

On Sep 10, 2007, at 8:00 PM, Mark Thomas wrote:


Jim Jagielski wrote:

How about:

   o CTR on trunk

   o Various release branches are made (ala httpd, apr, etc...).
 These include a STATUS file.

   o All code applied to the release branch is under
 lazy consensus but *must* be specified in STATUS.
 (eg: "I plan on applying rev786987 in 3 days under
 lazy consensus").

Not as stringent as RTC, but also provides a good level
of oversight with a minimum of overhead... RTC can be
maintained for older, stable releases.


Still -1.

It provides no more oversight than RTC


I have no idea how you could possibly justify that statement.
With RTC one *requires* 3 +1 votes. The above does not.

And STATUS is there to indicate what *will* be done, not
what *has* been done.

It's usually a good idea to actually read and understand
posts before automatically disagreeing with them :)

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

Re: [VOTE] Make released versions RTC

[Jim Jagielski]

On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:



The main idea is that since there's only one trunk branch, there  
should be agreement on APIs and important topics to proceed




++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed from here? Or, in other words, how do achieve
agreement on APIs?

Shame that you think that various "useless rules" are those rules that
have been used by the ASF and numerous ASF projects for years and
years... that these "useless rules" are those which Incubator
podlings must understand and utilize in order to become a "real"
ASF project...

In any case, your point about needing agreement is spot on.
If there was such agreement, which development methodology used
would be moot. As a talking point, what about the concept of a
6.0 and 6.5 running in parallel?

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

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Jim Jagielski wrote:

I have no idea how you could possibly justify that statement.
With RTC one *requires* 3 +1 votes. The above does not.

And STATUS is there to indicate what *will* be done, not
what *has* been done.

It's usually a good idea to actually read and understand
posts before automatically disagreeing with them :)


Right, but this still strikes me as too little review for important 
patches, and too much chore for trivial bugfixing.


However, I agree that different rules could be put in place for 
different branches depending on their level of maturity (the STATUS at 
the root of the branch could indicate the current commit procedure that 
is in place).


As far as I am concerned, the goal is to avoid chaotic development and 
the unavoidable nagging conflicts that go along with it. By itself, I 
don't see any problem having a slightly slower pace of development, since:
- conflicts result in months of wasted time at the ASF since there's no 
central authority
- some feature work is sometimes neglected, and (unfortunately) causes a 
much longer delay that any commit procedure ever could (ex: JSP 2.1)


Rémy

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

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Jim Jagielski wrote:

On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:

The main idea is that since there's only one trunk branch, there 
should be agreement on APIs and important topics to proceed


++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed from here? Or, in other words, how do achieve
agreement on APIs?


Actually, there's no need for a full agreement for a reviewed patch 
(from what I've written about a limited CTR mechanism): it's a need to 
pass the vote with a +3 margin. This means most people care and agree 
with you, but this does not mean it's a unanimous vote either.


If the community is evenly split and nothing moves, then there is never 
going to be a solution at Apache except eventually agree to fork the 
project.


If people don't care enough to vote (as long as the review mechanism is 
infrequent enough and not too inconvenient), then I think there's a 
problem with the patch or the way it was presented.



Shame that you think that various "useless rules" are those rules that
have been used by the ASF and numerous ASF projects for years and
years... that these "useless rules" are those which Incubator
podlings must understand and utilize in order to become a "real"
ASF project...


This statement is a bit too aggressive, since it seems obvious that if 
there's a disagreement, you cannot keep on developing in an official 
branch like trunk, but that a proper proposal should be used instead.


CTR for API changing patches (and for patches for which committers think 
is needed) works pretty much like the usual proposal mechanism. However, 
it puts down the rules in black and white about what sort of commit is 
concerned by them and how it happens.


Rémy

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

Re: JK 1.2.26 ?

[Rainer Jung]

Hi Henri,

1.2.25 is still pretty young :)

There are 2 new bugs for 1.2.25 that I'm aware of:

- BZ 43287 (already fixed)
- BZ 43229 (still needs to be fixed, should be fixed in next release)

Version 1.2.25 is now 1 month old. So a reasonable target release date 
would be in about 10 weeks?


Do you have anything special in mind or the need for earlier fixes?

Regards,

Rainer

Henri Gomez wrote:

Hi to all,

When should jk 1.2.26 should be released ?

Did there is still showstoppers ?

Regards


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

Re: Tomcat and SessionHandling

[Pid]

Preuss, Jacqueline - ENCOWAY wrote:
> Hi, I'm new here!
> 
>  
> 
> Generally, I'm new in the topic servlets etc. so I hope I can explain my 
> problem well.
> 
>  
> 
> In our company we work with some web applications running in Internet 
> Explorer. We want to use Tomcat as servlet engine / webserver. The problem is 
> the session handling of Tomcat. For the application the user authenticates 
> with username, password and domain (i.e. windows authentication). The user 
> can select different items in the application e.g. quotes. Every quote is 
> opened in a new browser window. If we use Tomcat, all quotes of the user are 
> saved under the same session, i.e. the session id is always the same. That's 
> a problem for us, because we need a new session for every single quote. So, 
> is there a possibility to implement our own session handling for Tomcat. If 
> yes, how? What would you suggest? Can we use a filter for tomcat the renew or 
> clear the session?
> 
>  
> 
> I hope this is the right place to post. Thanks for help.

Nope, sorry.
Try the tomcat-users list.


To start a new topic, e-mail: [EMAIL PROTECTED]
To subscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

p




> Regards,
> 
> Jacqueline Preuß.
> 
>  
> 
> 


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

Re: JK 1.2.26 ?

[Henri Gomez]

2007/9/11, Rainer Jung <[EMAIL PROTECTED]>:
> Hi Henri,
>
> 1.2.25 is still pretty young :)

Yes

> There are 2 new bugs for 1.2.25 that I'm aware of:
>
> - BZ 43287 (already fixed)
> - BZ 43229 (still needs to be fixed, should be fixed in next release)
>
> Version 1.2.25 is now 1 month old. So a reasonable target release date
> would be in about 10 weeks?
>
> Do you have anything special in mind or the need for earlier fixes?

Get an up to date release for i5/OS build check :)

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

Re: JK 1.2.26 ?

[Rainer Jung]

Henri Gomez wrote:

2007/9/11, Rainer Jung <[EMAIL PROTECTED]>:

Hi Henri,

1.2.25 is still pretty young :)


Yes


There are 2 new bugs for 1.2.25 that I'm aware of:

- BZ 43287 (already fixed)
- BZ 43229 (still needs to be fixed, should be fixed in next release)

Version 1.2.25 is now 1 month old. So a reasonable target release date
would be in about 10 weeks?

Do you have anything special in mind or the need for earlier fixes?


Get an up to date release for i5/OS build check :)


Like

http://people.apache.org/~rjung/mod_jk-dev/tomcat-connectors-1.2.26-dev-574630-src.tar.gz

(not a release, but up to date and release like, so should be OK for a 
build check).


Regards,

Rainer

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

Re: JK 1.2.26 ?

[Henri Gomez]

Thanks a lot :)

2007/9/11, Rainer Jung <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
> > 2007/9/11, Rainer Jung <[EMAIL PROTECTED]>:
> >> Hi Henri,
> >>
> >> 1.2.25 is still pretty young :)
> >
> > Yes
> >
> >> There are 2 new bugs for 1.2.25 that I'm aware of:
> >>
> >> - BZ 43287 (already fixed)
> >> - BZ 43229 (still needs to be fixed, should be fixed in next release)
> >>
> >> Version 1.2.25 is now 1 month old. So a reasonable target release date
> >> would be in about 10 weeks?
> >>
> >> Do you have anything special in mind or the need for earlier fixes?
> >
> > Get an up to date release for i5/OS build check :)
>
> Like
>
> http://people.apache.org/~rjung/mod_jk-dev/tomcat-connectors-1.2.26-dev-574630-src.tar.gz
>
> (not a release, but up to date and release like, so should be OK for a
> build check).
>
> Regards,
>
> Rainer
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

DO NOT REPLY [Bug 43356] New: - keystoreFile parameter, when specified as relative, is not treated relative to $CATALINA_BASE or catalina.base property for NioEndPoint

[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://issues.apache.org/bugzilla/show_bug.cgi?id=43356

   Summary: keystoreFile parameter, when specified as relative, is
not treated relative to $CATALINA_BASE or catalina.base
property for NioEndPoint
   Product: Tomcat 6
   Version: 6.0.9
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This issue is virtually the same symptoms as http://issues.apache.org/bugzilla/
show_bug.cgi?id=27050 except that it is with 
org.apache.tomcat.util.net.NioEndpoint.java instead of JSSESocketFactory


The docs state "keystoreFile - Add this attribute if the keystore file you 
created is not in the default place that Tomcat expects (a file named .keystore 
in the user home directory under which Tomcat is running). You can specify an 
absolute pathname, or a relative pathname that is resolved against the 
$CATALINA_BASE environment variable."

Relative paths don't work though with NioConnector. Here is the problem code in 
NioEndPoint starting line 744:

// Initialize SSL if needed
if (isSSLEnabled()) {
// Initialize SSL
char[] passphrase = getKeystorePass().toCharArray();

KeyStore ks = KeyStore.getInstance(getKeystoreType());
ks.load(new FileInputStream(getKeystoreFile()), passphrase);
KeyStore ts = KeyStore.getInstance(getKeystoreType());
ts.load(new FileInputStream(getKeystoreFile()), passphrase);


As you can see $CATALINA_BASE is not taken into account at all and therefore we 
get something like this on startup:

[] 2007-09-11 14:38:20,828 ERROR 
org.apache.coyote.http11.Http11NioProtocol.start(168) | Error starting endpoint
java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind(Native Method)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:731)
at org.apache.tomcat.util.net.NioEndpoint.start(NioEndpoint.java:779)
at 
org.apache.coyote.http11.Http11NioProtocol.start(Http11NioProtocol.java:166)
at org.apache.catalina.connector.Connector.start(Connector.java:1132)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:531)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)


Also I am curious why the keystoreFile is being used as the truststoreFile?

Also found this against version 6.0.13, not 6.0.9 ( although it may be in 6.0.9 
too).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 42983] - Creating a custom tag with an attribute named "class" causes exception

[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://issues.apache.org/bugzilla/show_bug.cgi?id=42983


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||asf-
   ||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 43356] - keystoreFile parameter, when specified as relative, is not treated relative to $CATALINA_BASE or catalina.base property for NioEndPoint

[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://issues.apache.org/bugzilla/show_bug.cgi?id=43356





--- Additional Comments From [EMAIL PROTECTED]  2007-09-11 20:42 ---
Oops pasted wrong exception. Here is the correct one:

-
[] 2007-09-11 14:38:19,406 ERROR 
org.apache.catalina.startup.Catalina.load(520) | Catalina.start
LifecycleException:  Protocol handler initialization failed: 
java.io.FileNotFoundException: conf\dev.keystore (The system cannot find the 
path specified)
at 
org.apache.catalina.connector.Connector.initialize(Connector.java:1061)
at 
org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
at 
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:792)
at org.apache.catalina.startup.Catalina.load(Catalina.java:518)
at org.apache.catalina.startup.Catalina.load(Catalina.java:538)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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