Re: Mavenized tomcat build
I think there are few separate issues: 1, If there is a patch that needs to be applied by geronimo to use tomcat or they are blocked by missing something from a release - we should review this again. I think we can do a tomcat-geronimo release specifically for them as worse case ( well, we did it for j2ee ref impl in the old days - all we need is a branch ), or make sure it gets in the next release, 2. For Maven support - if maven can support building tomcat, I don't see any problem. But moving the code around and changing code just so we can be built by maven - I don't like that. The current patch is even worse - it seems to create 2 different source trees for tomat, and since maven can also checkout the source and people may use the maven-source... 3. For having maven-like 'modules' with strict build and runtime dependencies - been there. There are plenty of large projects using tomcat approach - i.e. allow circular dependencies between packages and build either one big jar or few jars. I think the benefits of more reuse and code sharing are bigger than the problems - i.e. mostly not able to break into many directories and build with maven, and arcane ways to break circular dependencies. Costin On Fri, Jul 10, 2009 at 11:43 PM, Mladen Turk wrote: > Filip Hanik - Dev Lists wrote: >> >> If Geronimo needs a better way to download and integrate Tomcat's JAR's >> lets focus on that, and not make this into another Maven vs ANT topic, cause >> I don't think that was the intention. >> > > Agreed. > However we should really find a way to deal with eclipse > repository since they tend to change the download system > quite often (only external dependency). > Since we cannot copy that to the ASF due to license issue > we could reuse the backup system on tomcat.heanet.ie (like we did > for Tomcat Native until ASF resolved the crypto software issues) > to allow the historic builds. > I somehow doubt Maven can solve this problem anyhow, and > downloading a repo with 10+ eclipse JDT's would be insane > just to build eg. 6.0.20 in 5 years from now. > Other things is trivial, just testing the dist.apache.org > with archive.apache.org as fallback for the remaining > dependencies. > > > Regards > -- > ^(TM) > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
One way to maintain a tomcat fork built with maven (was: Mavenized tomcat build)
I'd like to apologize for the miscommunication engendered by this thread. It's very clear to me that what I thought I was communicating did not get through. This attempt to clarify will probably not fare any better :-( I don't expect tomcat to consider changing its build system and certainly don't want to participate in any discussion of the tomcat build system. I don't expect tomcat to release anything from trunk or any branch in particular. I do suspect that there are projects that, like geronimo, use maven and are faced with maintaining a tomcat fork. For such projects, (NOT TOMCAT ITSELF) the tools we developed at geronimo might be useful. Once again, this is NOT a proposal for tomcat to use maven. If you guys happen to decide you want to I'd be happy to give advice, but I'm not proposing it and don't want to talk about whether it would be a good idea. On Jul 11, 2009, at 8:38 AM, Costin Manolache wrote: I think there are few separate issues: 1, If there is a patch that needs to be applied by geronimo to use tomcat or they are blocked by missing something from a release - we should review this again. I think we can do a tomcat-geronimo release specifically for them as worse case ( well, we did it for j2ee ref impl in the old days - all we need is a branch ), or make sure it gets in the next release, Personally, since geronimo now has a working method of maintaining a fork of the 6.0 branch including the needed patches from trunk, I would prefer to see any development effort expended on servlet 3.0 features. If tomcat 7 supports servlet 3.0 and is based on trunk geronimo won't need a fork any more. 2. For Maven support - if maven can support building tomcat, I don't see any problem. But moving the code around and changing code just so we can be built by maven - I don't like that. The current patch is even worse - it seems to create 2 different source trees for tomat, and since maven can also checkout the source and people may use the maven-source... Once again, this was never intended to be about the tomcat build system. 3. For having maven-like 'modules' with strict build and runtime dependencies - been there. There are plenty of large projects using tomcat approach - i.e. allow circular dependencies between packages and build either one big jar or few jars. I think the benefits of more reuse and code sharing are bigger than the problems - i.e. mostly not able to break into many directories and build with maven, and arcane ways to break circular dependencies. I'm still mystified by this. I have no problems with circular package dependencies within a single jar but I really don't understand why you'd have 2 jars neither of which can be used without the other. Wouldn't it be simpler for everyone to just have one jar? Costin On Fri, Jul 10, 2009 at 11:43 PM, Mladen Turk wrote: Filip Hanik - Dev Lists wrote: If Geronimo needs a better way to download and integrate Tomcat's JAR's lets focus on that, and not make this into another Maven vs ANT topic, cause I don't think that was the intention. Agreed. However we should really find a way to deal with eclipse repository since they tend to change the download system quite often (only external dependency). Since we cannot copy that to the ASF due to license issue we could reuse the backup system on tomcat.heanet.ie (like we did for Tomcat Native until ASF resolved the crypto software issues) to allow the historic builds. I somehow doubt Maven can solve this problem anyhow, and downloading a repo with 10+ eclipse JDT's would be insane just to build eg. 6.0.20 in 5 years from now. ? maven only downloads the dependencies you require, not entire repos. Probably I don't understand what you are saying. Other things is trivial, just testing the dist.apache.org with archive.apache.org as fallback for the remaining dependencies. I didn't mention this before either but I don't understand why tomcat is rebuilding the eclipse code. The released eclipse jdt jar available from maven central seems to work fine. thanks david jencks Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
tomcat patch question
Hi, There is a bug in catalina about load balancer. I have a fix locally and like to submit a patch but I don't know how. Does anyone know? Thanks, Giac. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat patch question
Submit a bug, attach the patch https://issues.apache.org/bugzilla/ On 07/11/2009 12:46 PM, Jack Vu wrote: Hi, There is a bug in catalina about load balancer. I have a fix locally and like to submit a patch but I don't know how. Does anyone know? Thanks, Giac. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47510] New: sessionId is not generated when switch between clusters
https://issues.apache.org/bugzilla/show_bug.cgi?id=47510 Summary: sessionId is not generated when switch between clusters Product: Tomcat 6 Version: 6.0.18 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: vuj...@yahoo.com Currently, tomcat only generates a new sessionid if it's not NULL and tries to reuse the existing one. However, in the case of tomcat configured with load balancer using jvmRoute and user switch between clusters on the same browser session, tomcat see jsession cookie(with old jvmroute value from another cluster) and reuse it and it's not correct. The fix is to check jvmRoute value and it's note the same, generate new sessionId. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47510] sessionId is not generated when switch between clusters
https://issues.apache.org/bugzilla/show_bug.cgi?id=47510 --- Comment #1 from Giac Vu 2009-07-11 13:13:11 PST --- Created an attachment (id=23959) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23959) BaseManager.java with a fix -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47512] New: Binding java.lang.reflect.Proxy to JNDI directory raises java.lang.ClassCastException
https://issues.apache.org/bugzilla/show_bug.cgi?id=47512
Summary: Binding java.lang.reflect.Proxy to JNDI directory
raises java.lang.ClassCastException
Product: Tomcat 6
Version: 6.0.18
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: mrr...@gmail.com
I've created a custom javax.naming.spi.ObjectFactory that is able to bind
javax.naming.Reference(s) into the global JNDI naming directory during startup
time using a org.apache.catalina.LifecycleListener.
I want two separate web contexts invoke the custom
ObjectFactory#getObjectInstance method indirectly, getting through the local to
the global JNDI context with a ResourceLink by invoking the local
InitialContext#lookup method. Since both contexts have different classloaders
my intention is to create a java.lang.reflect.Proxy given the current thread
classloader.
For the first web context, everything goes Ok. The thread reaches the
ObjectFactory, the object factory peeks the current thread classloader (always
a webapp classloader), peeks the name of the interface to use for
Proxy#newProxyInstance method, and the object to proxify for an internal
collection and returns the proxy.
The problem arises for the second web context. The InitialContext#lookup method
resolves the name and, although the thread never reaches the ObjectFactory, the
object is resolved. Surprisingly, the returned object is the proxy created for
the first web context. This proxy implements an interface available in the
first web context's classloader. This interface is present in the second
context classpath, but is loaded by a different webapp classloader. Thus, a
java.lang.ClassCastException is raised.
Digging into the tomcat codebase, I found in org.apache.naming.NamingContext
that once a reference is resolved, the resolved object is sort of rebound to
the original name. Thus, when the second lookup invocation arrives, the name is
associated to an object (not a reference) and the ObjectFactory is never
invoked.
Here's the org.apache.naming.NamingContext code, lines 791 to 799:
} else if (entry.type == NamingEntry.REFERENCE) {
try {
Object obj = NamingManager.getObjectInstance(entry.value, name, this,
env);
if (obj != null) {
entry.value = obj;
entry.type = NamingEntry.ENTRY;
}
return obj;
When a NamingEntry.REFERENCE arrive, the reference is resolved with the help of
a javax.naming.spi.NamingManager. If the resolved object is null, the entry is
converted to a NamingEntry.ENTRY instead of leaving it as a
NamingEntry.REFERENCE.
In my opinion, the entry should be left as a REFERENCE, so the next invocation
to the method, no matter who is the invoker nor its classloader, resolves the
reference again with the javax.naming.spi.NamingManager's help. This "cache"
policy of references should be left to the ObjectFactory itself, which will
have all the necessary information to apply such a policy.
The code change would only imply the removal of the if I've shown above.
Regards,
Martin.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47512] Binding java.lang.reflect.Proxy to JNDI directory raises java.lang.ClassCastException
https://issues.apache.org/bugzilla/show_bug.cgi?id=47512 --- Comment #1 from MartinS 2009-07-11 23:26:20 PST --- errata: in "If the resolved object is null, the entry is converted to a NamingEntry.ENTRY instead of leaving it as a NamingEntry.REFERENCE." I meant "if the resolved object is not null". -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
