svn commit: r730523 - in /tomcat/connectors/trunk/jni: java/org/apache/tomcat/jni/ native/src/
Author: rjung Date: Thu Jan 1 02:52:46 2009 New Revision: 730523 URL: http://svn.apache.org/viewvc?rev=730523&view=rev Log: Sync methods implemented natively with their Java references. Fixes BZ 46457 and several other inconsistencies: Changes to Java code: Buffer: rename alloc() to malloc() Buffer: change return type of size() from int to long File: add getStat() and getInfo() Registry: change val parameter in setValueJ() from int to long Socket: add acceptx() SSLContext: add setRandom() SSLContext: rename setShutdowType() to setShutdownType() Stdlib: change num parameter in calloc() from long to int Changes to native code: address.c:change return type of equal() from int to boolean file.c: change pool parameter in mktemp() from int to long lock.c: refer to Java method destroy instead of destoy in Global and Lock multicast.c: refer to Java class Multicast instead of Mulicast ssl.c:add randSet() in non-OpenSSL case sslcontext.c: whitespace Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Buffer.java tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/File.java tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Registry.java tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/SSLContext.java tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Socket.java tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Stdlib.java tomcat/connectors/trunk/jni/native/src/address.c tomcat/connectors/trunk/jni/native/src/file.c tomcat/connectors/trunk/jni/native/src/lock.c tomcat/connectors/trunk/jni/native/src/multicast.c tomcat/connectors/trunk/jni/native/src/ssl.c tomcat/connectors/trunk/jni/native/src/sslcontext.c Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Buffer.java URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Buffer.java?rev=730523&r1=730522&r2=730523&view=diff == --- tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Buffer.java (original) +++ tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Buffer.java Thu Jan 1 02:52:46 2009 @@ -32,7 +32,7 @@ * @param size The amount of memory to allocate * @return The ByteBuffer with allocated memory */ -public static native ByteBuffer alloc(int size); +public static native ByteBuffer malloc(int size); /** * Allocate a new ByteBuffer from memory and set all of the memory to 0 @@ -86,6 +86,6 @@ * Returns the allocated memory size of the ByteBuffer. * @param buf Previously allocated ByteBuffer. */ -public static native int size(ByteBuffer buf); +public static native long size(ByteBuffer buf); } Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/File.java URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/File.java?rev=730523&r1=730522&r2=730523&view=diff == --- tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/File.java (original) +++ tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/File.java Thu Jan 1 02:52:46 2009 @@ -693,6 +693,16 @@ public static native int stat(FileInfo finfo, String fname, int wanted, long pool); /** + * Get the specified file's stats. The file is specified by filename, + * instead of using a pre-opened file. + * @param fname The name of the file to stat. + * @param wanted The desired apr_finfo_t fields, as a bit flag of APR_FINFO_ values + * @param pool the pool to use to allocate the new file. + * @return FileInfo object. + */ +public static native FileInfo getStat(String fname, int wanted, long pool); + +/** * Get the specified file's stats. * @param finfo Where to store the information about the file. * @param wanted The desired apr_finfo_t fields, as a bit flag of APR_FINFO_ values @@ -700,4 +710,13 @@ */ public static native int infoGet(FileInfo finfo, int wanted, long thefile); + +/** + * Get the specified file's stats. + * @param wanted The desired apr_finfo_t fields, as a bit flag of APR_FINFO_ values + * @param thefile The file to get information about. + * @return FileInfo object. + */ +public static native FileInfo getInfo(int wanted, long thefile); + } Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Registry.java URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Registry.java?rev=730523&r1=730522&r2=730523&view=diff == --- tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Registry.java (original) +++ tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Registry.java Thu J
svn commit: r730528 - /tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/SSLContext.java
Author: rjung Date: Thu Jan 1 03:24:40 2009 New Revision: 730528 URL: http://svn.apache.org/viewvc?rev=730528&view=rev Log: Fix syntax error introduced in r730523. Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/SSLContext.java Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/SSLContext.java URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/SSLContext.java?rev=730528&r1=730527&r2=730528&view=diff == --- tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/SSLContext.java (original) +++ tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/SSLContext.java Thu Jan 1 03:24:40 2009 @@ -230,7 +230,7 @@ * @param ctx Server or Client context to use. * @param file random file. */ -public static native void setRandom(long ctx, String file) +public static native void setRandom(long ctx, String file); /** * Set SSL connection shutdown type - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r730523 - in /tomcat/connectors/trunk/jni: java/org/apache/tomcat/jni/ native/src/
On Thu, 2009-01-01 at 10:52 +, rj...@apache.org wrote: > Author: rjung > Date: Thu Jan 1 02:52:46 2009 > New Revision: 730523 > > URL: http://svn.apache.org/viewvc?rev=730523&view=rev > Log: > Sync methods implemented natively with their Java > references. > > Fixes BZ 46457 and several other inconsistencies: -1. This trunk is used for the stable tomcat-native, and it does change method signatures. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r730523 - in /tomcat/connectors/trunk/jni:java/org/apache/tomcat/jni/ native/src/
On 01.01.2009 12:44, Remy Maucherat wrote: On Thu, 2009-01-01 at 10:52 +, rj...@apache.org wrote: Author: rjung Date: Thu Jan 1 02:52:46 2009 New Revision: 730523 URL: http://svn.apache.org/viewvc?rev=730523&view=rev Log: Sync methods implemented natively with their Java references. Fixes BZ 46457 and several other inconsistencies: -1. This trunk is used for the stable tomcat-native, and it does change method signatures. Rémy, we do have a 1.1.x branch in tcnative which is supposed to be the stable brach. Nevertheless I just noticed the dependency between TC 5.5 and this trunk. I'll write a separate mail to discuss. If we don't find a better solution, I'll revert. Please check my separate message. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
JNI svn structure wierdness
Hi, I just fixed some glitches in tcnative. I noticed the following problem: We now have two branches for jni, 1.1.x and trunk, actually they are complete branches of the full connectors, so especially both contain the native and the java side of JNI. TC 5.5.x has an external reference to connectors trunk. I would expect, that we would like it to use connectors trunk in general, but branches/1.1.x for the jni related stuff (the Java side we bundle in tomcat-apr.jar). It looks like we need another external reference directly pointing to the jni branch and enhance build.xml to use the Java jni stuff from that one. Another option would be to split up connectors and move the parts independently versioned outside and into separate directories. Any better ideas? For TC6 and trunk I see no such problem, because they already have their private copy of connectors Java classes. For TC4.1 we don't bundle any of the JNI stuff except in the src distribution (more or less by accident). Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730538 - /tomcat/trunk/java/org/apache/tomcat/jni/OS.java
Author: rjung Date: Thu Jan 1 04:57:36 2009 New Revision: 730538 URL: http://svn.apache.org/viewvc?rev=730538&view=rev Log: Port r708867 from tcnative trunk to tc trunk. Modified: tomcat/trunk/java/org/apache/tomcat/jni/OS.java Modified: tomcat/trunk/java/org/apache/tomcat/jni/OS.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/jni/OS.java?rev=730538&r1=730537&r2=730538&view=diff == --- tomcat/trunk/java/org/apache/tomcat/jni/OS.java (original) +++ tomcat/trunk/java/org/apache/tomcat/jni/OS.java Thu Jan 1 04:57:36 2009 @@ -33,6 +33,7 @@ private static final int LINUX = 5; private static final int SOLARIS = 6; private static final int BSD = 7; +private static final int MACOSX= 8; public static final int LOG_EMERG = 1; public static final int LOG_ERROR = 2; @@ -54,6 +55,7 @@ public static final boolean IS_LINUX = is(LINUX); public static final boolean IS_SOLARIS = is(SOLARIS); public static final boolean IS_BSD = is(BSD); +public static final boolean IS_MACOSX = is(MACOSX); /** * Get the name of the system default characer set. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730542 - /tomcat/trunk/java/org/apache/tomcat/jni/Socket.java
Author: rjung Date: Thu Jan 1 05:11:25 2009 New Revision: 730542 URL: http://svn.apache.org/viewvc?rev=730542&view=rev Log: Port r706574 from tcnative trunk to tc trunk. "Fix API function name recvFrom -> recvfrom." Function is actually not used in TC trunk. Modified: tomcat/trunk/java/org/apache/tomcat/jni/Socket.java Modified: tomcat/trunk/java/org/apache/tomcat/jni/Socket.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/jni/Socket.java?rev=730542&r1=730541&r2=730542&view=diff == --- tomcat/trunk/java/org/apache/tomcat/jni/Socket.java (original) +++ tomcat/trunk/java/org/apache/tomcat/jni/Socket.java Thu Jan 1 05:11:25 2009 @@ -387,7 +387,7 @@ * @param nbytes The number of bytes to read (-1) for full array. * @return the number of bytes received. */ -public static native int recvFrom(long from, long sock, int flags, +public static native int recvfrom(long from, long sock, int flags, byte[] buf, int offset, int nbytes); /** - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 36911] Make fails while building jsvc on mac os x, multiple errors
https://issues.apache.org/bugzilla/show_bug.cgi?id=36911 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #5 from Mark Thomas 2009-01-01 05:18:35 PST --- jsvc is part of commons daemon so this really belongs in the commons daemon bug tracker. I've taken a quick look and there is already an issue for this along with some patches: https://issues.apache.org/jira/browse/DAEMON-98 There hasn't been much activity on commons daemon for a while - I'll ping the commons-dev list to see if I can stimulate some / get commit privs on daemon. I am marking this as INVALID for Tomcat which doesn't mean that this isn't an issue but that it is an issue with a non-Tomcat component and needs to be tracked on that component's bug tracker. -- 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
Re: svn commit: r730523 - in /tomcat/connectors/trunk/jni:java/org/apache/tomcat/jni/ native/src/
On Thu, 2009-01-01 at 13:23 +0100, Rainer Jung wrote: > Rémy, > > we do have a 1.1.x branch in tcnative which is supposed to be the stable > brach. Nevertheless I just noticed the dependency between TC 5.5 and > this trunk. I'll write a separate mail to discuss. If we don't find a > better solution, I'll revert. Please check my separate message. Ok. I thought this was still also used in 6.0. OTOH, the library should be renamed so that both v1.1 and this new incompatible one could be used at the same time, right ? Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730544 - in /tomcat/trunk/java/org/apache/tomcat/jni: Buffer.java File.java Registry.java SSL.java SSLContext.java Socket.java Stdlib.java Thread.java
Author: rjung
Date: Thu Jan 1 05:37:39 2009
New Revision: 730544
URL: http://svn.apache.org/viewvc?rev=730544&view=rev
Log:
Port r730523 from tcnative trunk to tc trunk.
Add Thread.java and Buffer.java.
Change SSL.randSet() javadoc to the tcnative one.
Add Socket.sendib() and Socket.sendibb from tcnative.
All renames methods and method signature changes
are compatible, because those methods are not used
by Tomcat.
Changes of return types are compatible, because
the return values have not been used.
Added:
tomcat/trunk/java/org/apache/tomcat/jni/Buffer.java (with props)
tomcat/trunk/java/org/apache/tomcat/jni/Thread.java (with props)
Modified:
tomcat/trunk/java/org/apache/tomcat/jni/File.java
tomcat/trunk/java/org/apache/tomcat/jni/Registry.java
tomcat/trunk/java/org/apache/tomcat/jni/SSL.java
tomcat/trunk/java/org/apache/tomcat/jni/SSLContext.java
tomcat/trunk/java/org/apache/tomcat/jni/Socket.java
tomcat/trunk/java/org/apache/tomcat/jni/Stdlib.java
Added: tomcat/trunk/java/org/apache/tomcat/jni/Buffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/jni/Buffer.java?rev=730544&view=auto
==
--- tomcat/trunk/java/org/apache/tomcat/jni/Buffer.java (added)
+++ tomcat/trunk/java/org/apache/tomcat/jni/Buffer.java Thu Jan 1 05:37:39 2009
@@ -0,0 +1,91 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.tomcat.jni;
+
+import java.nio.ByteBuffer;
+
+/** Buffer
+ *
+ * @author Mladen Turk
+ * @version $Revision$, $Date$
+ */
+
+public class Buffer {
+
+/**
+ * Allocate a new ByteBuffer from memory
+ * @param size The amount of memory to allocate
+ * @return The ByteBuffer with allocated memory
+ */
+public static native ByteBuffer malloc(int size);
+
+/**
+ * Allocate a new ByteBuffer from memory and set all of the memory to 0
+ * @param num Number of elements.
+ * @param size Length in bytes of each element.
+ * @return The ByteBuffer with allocated memory
+ */
+public static native ByteBuffer calloc(int num, int size);
+
+/**
+ * Allocate a new ByteBuffer from a pool
+ * @param p The pool to allocate from
+ * @param size The amount of memory to allocate
+ * @return The ByteBuffer with allocated memory
+ */
+public static native ByteBuffer palloc(long p, int size);
+
+/**
+ * Allocate a new ByteBuffer from a pool and set all of the memory to 0
+ * @param p The pool to allocate from
+ * @param size The amount of memory to allocate
+ * @return The ByteBuffer with allocated memory
+ */
+public static native ByteBuffer pcalloc(long p, int size);
+
+/**
+ * Allocate a new ByteBuffer from already allocated memory.
+ * Allocated memory must be provided from call to the
+ * Stdlib.alloc or Stdlib.calloc methods.
+ * @param mem The memory to use
+ * @param size The amount of memory to use
+ * @return The ByteBuffer with attached memory
+ */
+public static native ByteBuffer create(long mem, int size);
+
+/**
+ * Deallocates or frees a memory block used by ByteBuffer
+ * Warning : Call this method only on ByteBuffers
+ * that were created by calling Buffer.alloc or Buffer.calloc.
+ * @param buf Previously allocated ByteBuffer to be freed.
+ */
+public static native void free(ByteBuffer buf);
+
+/**
+ * Returns the memory address of the ByteBuffer.
+ * @param buf Previously allocated ByteBuffer.
+ */
+public static native long address(ByteBuffer buf);
+
+/**
+ * Returns the allocated memory size of the ByteBuffer.
+ * @param buf Previously allocated ByteBuffer.
+ */
+public static native long size(ByteBuffer buf);
+
+}
Propchange: tomcat/trunk/java/org/apache/tomcat/jni/Buffer.java
--
svn:eol-style = native
Propchange: tomcat/trunk/java/org/apache/tomcat/jni/Buffer.java
--
svn:keywords = Author Date Id Revision
Modified: tomcat/
tcnative API stability/compatibility
Hi, we now have tcnative 1.1.x and trunk. What's our goal w.r.t. API stability? Citing from an earlier thread: > we do have a 1.1.x branch in tcnative which is supposed to be the stable > brach. Ok. I thought this was still also used in 6.0. OTOH, the library should be renamed so that both v1.1 and this new incompatible one could be used at the same time, right ? Rémy We have native and Java code in tcnative. I guess we are talking here mainly about the Java side, i.e. the native one is the implementation, which is only exposed via the Java code and the Java code represents the API we do make public. I expect we want the following situation: - new methods can be added to tcnative trunk - old methods are not allowed to be removed either from trunk or from 1.1.x Trunk will most likely result in 1.2.x versions, and code using tcnative should be able to update from 1.1 to 1.2 without incompatibilities. Otherwise we would already now decide, that trunk will become a 2.x. Methods could get deprecated in trunk though. Exception: There are some methods which wouldn't have worked any time in the past, because they refer to native functions that don't exist. I think it is a good cleanup to remove/rename them now in trunk and 1.1.x. Anyone fine with that? Concerning the native side. What is the compatibility goal between the Java code and the native lib? Do we want to urge each using software to use a) exactly the same version of native, than the version of the Java code b) the same minor version, but patch version greater or equal to the Java side c) the same major version and any minor/patch greater or equal ... I guess we want a) or b), I think it's to early for c). If we go for b) and trunk is for a 1.2.x version, we don't need to support loading multiple copies of the native library. So I guess, b) is what we should do? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Logging in tcnative
Hi, during syncing tcnative trunk with tc trunk I noticed the following change to jni/Library.java: http://svn.eu.apache.org/viewvc/tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Library.java?r1=466585&r2=671153&diff_format=h It includes a call to Throwable.printStackTrace() to ease error diagnosis. So if we want to keep tcnative trunk and tc trunk in sync, then we'll write to STDERR without using proper logging. This special case is only during startup but it shows a general question: do we want to establish correct logging in tcnative, and if so, which framework/dependency do we want to use, juli (good for the use in Tomcat, bad for others who would need a new dependency), commons-logging or log4j, or ... Of course we could do it in some clever way like using juli if available and no log framework or java.util.logging otherwise. Any ideas? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730550 - /tomcat/trunk/java/org/apache/tomcat/jni/SSLContext.java
Author: rjung Date: Thu Jan 1 06:16:14 2009 New Revision: 730550 URL: http://svn.apache.org/viewvc?rev=730550&view=rev Log: Every fault needs to be done at least twice. Modified: tomcat/trunk/java/org/apache/tomcat/jni/SSLContext.java Modified: tomcat/trunk/java/org/apache/tomcat/jni/SSLContext.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/jni/SSLContext.java?rev=730550&r1=730549&r2=730550&view=diff == --- tomcat/trunk/java/org/apache/tomcat/jni/SSLContext.java (original) +++ tomcat/trunk/java/org/apache/tomcat/jni/SSLContext.java Thu Jan 1 06:16:14 2009 @@ -230,7 +230,7 @@ * @param ctx Server or Client context to use. * @param file random file. */ -public static native void setRandom(long ctx, String file) +public static native void setRandom(long ctx, String file); /** * Set SSL connection shutdown type - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Missing tcnative function implementations
When checking the consistency between the native and the Java code of tcnative I found the following differences, which are still open: General differences === Methods implemented in pool.c but not available in Pool.java (jlong, Pool, palloc)(TCN_STDARGS, jlong pool, jint size) (jlong, Pool, pcalloc)(TCN_STDARGS, jlong pool, jint size) I'm not sure, whether we want to make them available or drop them completely. All other allocation methods in pool.c use DirectByteBuffers, those two do not. Are they intended to be made part of the public API? Platform specific differences = Missing implementation on netware - (all avaliable via OS.java) public static native String expand(String str); public static native void sysloginit(String domain); public static native void syslog(int level, String message); (all available via Local.java): public static native long create(String path, long cont) public static native int bind(long sock, long sa); public static native int listen(long sock, int backlog); public static native int connect(long sock, long sa); Missing on Unix and Netware --- (but also not published in the Java API) system.c: (jstring, OS, syserror)(TCN_STDARGS, jint err) Only existing for Windows - (but all published via Registry.java) public static native long create(int root, String name, int sam, long pool) public static native long open(int root, String name, int sam, long pool) public static native int getType(long key, String name); public static native int getValueI(long key, String name) public static native long getValueJ(long key, String name) public static native int getSize(long key, String name); public static native String getValueS(long key, String name) public static native String[] getValueA(long key, String name) public static native byte[] getValueB(long key, String name) public static native int setValueI(long key, String name, int val); public static native int setValueJ(long key, String name, long val); public static native int setValueS(long key, String name, String val); public static native int setValueE(long key, String name, String val); public static native int setValueA(long key, String name, String[] val); public static native int setValueB(long key, String name, byte[] val); public static native int deleteValue(long key, String name); public static native int deleteKey(int root, String name, Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730554 - /tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt
Author: rjung Date: Thu Jan 1 07:15:07 2009 New Revision: 730554 URL: http://svn.apache.org/viewvc?rev=730554&view=rev Log: Add Status file for tcnative 1.1.x branch and start with a first backport proposal. Added: tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt (with props) Added: tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt?rev=730554&view=auto == --- tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt (added) +++ tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt Thu Jan 1 07:15:07 2009 @@ -0,0 +1,40 @@ + + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + + +$Revision$ $Date$ + + + Apache Tomcat Native 1.1 Patch Proposals + + + +RELEASE SHOWSTOPPERS: + + +PATCHES ACCEPTED TO BACKPORT: + [ start all new proposals below, under PATCHES PROPOSED. ] + +PATCHES PROPOSED TO BACKPORT: + [ New proposals should be added at the end of the list ] + +* Sync native and Java methods. Patch available at + http://people.apache.org/~rjung/patches/tcnative-sync.patch + Partial backport of + http://svn.apache.org/viewvc?view=rev&revision=730523 + +1: rjung + 0: + -1: Propchange: tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt -- svn:eol-style = native Propchange: tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt -- svn:keywords = Author Date Id Revision - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46457] Typos in multicast.c
https://issues.apache.org/bugzilla/show_bug.cgi?id=46457 --- Comment #1 from Rainer Jung 2009-01-01 07:19:32 PST --- This and a couple of additional inconsistencies between native and Java has been fixed in tcnative trunk in r730523 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=730523 )and proposed for backport to 1.1.x. -- 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 46461] New: fail graceful on dns changes for connectors/hosts in server.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=46461 Summary: fail graceful on dns changes for connectors/hosts in server.xml Product: Tomcat 6 Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: hau...@acm.org in a server.xml, there are n > 4 connectors declared on a physical machine with multiple ip addresses. Due to a dns change, connector 2 and connector 3 end up with the same ip address. This rightfully causes connector 3 not to get up and running with ERROR [main] (Catalina.java:553) - Catalina.start: LifecycleException: service.getName(): "HTTPSmyApp3"; Protocol handler start failed: java.net.BindException: Address already in use:8443 at org.apache.catalina.connector.Connector.start(Connector.java:1096) at org.apache.catalina.core.StandardService.start(StandardService.java:459) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) 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:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) However, all subsequent connectors 4..n will not start either - isn't a dns-misconfiguration having too big effect on a mostly correct server.xml config? -- 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
Re: tcnative API stability/compatibility
Rainer Jung wrote: > Hi, > > we now have tcnative 1.1.x and trunk. What's our goal w.r.t. API stability? My understanding was that trunk was created to introduce APR 1.3 and that the result would be tcnative 1.2.x. > Citing from an earlier thread: >>> > we do have a 1.1.x branch in tcnative which is supposed to be the >>> stable >>> > brach. >> >> Ok. I thought this was still also used in 6.0. OTOH, the library should >> be renamed so that both v1.1 and this new incompatible one could be used >> at the same time, right ? >> >> Rémy > > We have native and Java code in tcnative. I guess we are talking here > mainly about the Java side, i.e. the native one is the implementation, > which is only exposed via the Java code and the Java code represents the > API we do make public. > > I expect we want the following situation: > - new methods can be added to tcnative trunk +1 > - old methods are not allowed to be removed either from trunk or from 1.1.x +1 (unless they are deprecated in 1.1.x - then they can go in 1.2.x) > Trunk will most likely result in 1.2.x versions, and code using > tcnative should be able to update from 1.1 to 1.2 without > incompatibilities. +1 Otherwise we would already now decide, that trunk > will become a 2.x. > Methods could get deprecated in trunk though. > Exception: There are some methods which wouldn't have worked any time > in the past, because they refer to native functions that don't exist. I > think it is a good cleanup to remove/rename them now in trunk and 1.1.x. +1 (providing they truly never worked) > Concerning the native side. What is the compatibility goal between the > Java code and the native lib? Do we want to urge each using software to use > > a) exactly the same version of native, than the version of the Java code > b) the same minor version, but patch version greater or equal to the > Java side > c) the same major version and any minor/patch greater or equal ... > > I guess we want a) or b), I think it's to early for c). > > If we go for b) and trunk is for a 1.2.x version, we don't need to > support loading multiple copies of the native library. So I guess, b) is > what we should do? b) seems like a sensible target given I don't know how much work c) would be. Now is probably a good time to extract the native library into a separate component (ie move tomcat/connectors/trunk/jni/native/ to tomcat/native etc) and treat it as an external library rather than using svn externals. ie add tcnative to the list of libs downloaded as part of the build process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tcnative API stability/compatibility
On 01.01.2009 18:15, Mark Thomas wrote: Rainer Jung wrote: Concerning the native side. What is the compatibility goal between the Java code and the native lib? Do we want to urge each using software to use a) exactly the same version of native, than the version of the Java code b) the same minor version, but patch version greater or equal to the Java side c) the same major version and any minor/patch greater or equal ... I guess we want a) or b), I think it's to early for c). If we go for b) and trunk is for a 1.2.x version, we don't need to support loading multiple copies of the native library. So I guess, b) is what we should do? b) seems like a sensible target given I don't know how much work c) would be. Now is probably a good time to extract the native library into a separate component (ie move tomcat/connectors/trunk/jni/native/ to tomcat/native etc) and treat it as an external library rather than using svn externals. ie add tcnative to the list of libs downloaded as part of the build process. We need to have a better idea on the future relation between the Java code in jni and the native code. Is our goal providing jni native function implementations (with stability docs etc.) or is the goal more providing a Java API which is backed by the native implementation. Until now I think tcnative inside Tomcat is only used via the Java API in org/apache/tomcat/jni. If this API is our primary target, then we should think about moving the native and the Java part of tcnative and releasing them together. Do we think that we will loose flexibility on the Tomcat side by this? At the monent we have copies of the Java classes in TC trunk and TC 6, but it looks like we didn't yet use those copies for quicker fixes, instead the copies missed fixes we applied to tcnative directly. What's the feeling: a) bundling native and org/apache/tomcat/jni code in one place in svn and releasing together or b) separating only the native implementation In case of a): Do we want to delete the copies of org/apache/tomcat/jni in TC trunk and 6.0.x and use instead ones downloaded from a tcnative release or an svn external to the new tcnative svn location? I tend to suggest a) and also getting rid of the redundant copies of the classes in TC trunk and 6, but I'm not sure if I noticed all implications. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730579 - /tomcat/current-svn15/tc5.5.x/
Author: markt Date: Thu Jan 1 10:29:51 2009 New Revision: 730579 URL: http://svn.apache.org/viewvc?rev=730579&view=rev Log: Update the ignore list Modified: tomcat/current-svn15/tc5.5.x/ (props changed) Propchange: tomcat/current-svn15/tc5.5.x/ -- --- svn:ignore (original) +++ svn:ignore Thu Jan 1 10:29:51 2009 @@ -1,3 +1,4 @@ bin .classpath .project +.settings - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730590 - /tomcat/trunk/java/org/apache/jasper/compiler/Parser.java
Author: markt
Date: Thu Jan 1 11:02:21 2009
New Revision: 730590
URL: http://svn.apache.org/viewvc?rev=730590&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=36923
If EL is disabled, treat it as template text.
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Parser.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Parser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Parser.java?rev=730590&r1=730589&r2=730590&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Parser.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Parser.java Thu Jan 1
11:02:21 2009
@@ -1315,7 +1315,7 @@
if (ch == '<') {
reader.pushChar();
break;
-} else if (ch == '$' || ch == '#') {
+} else if ((ch == '$' || ch == '#') && !pageInfo.isELIgnored()) {
if (!reader.hasMoreInput()) {
ttext.write(ch);
break;
@@ -1455,9 +1455,9 @@
parseXMLScriptlet(parent);
} else if (reader.matches("
svn commit: r730591 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Thu Jan 1 11:03:27 2009 New Revision: 730591 URL: http://svn.apache.org/viewvc?rev=730591&view=rev Log: Propose fix for 36923 Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=730591&r1=730590&r2=730591&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jan 1 11:03:27 2009 @@ -249,4 +249,9 @@ http://svn.apache.org/viewvc?rev=730178&view=rev +1: fhanik -1: - + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=36923 + If EL is disabled, treat it as template text + http://svn.apache.org/viewvc?rev=730590&view=rev + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 36923] Deactivated EL expressions are not parsed for jsp expressions/scriptlets/etc
https://issues.apache.org/bugzilla/show_bug.cgi?id=36923 --- Comment #1 from Mark Thomas 2009-01-01 11:09:09 PST --- This bug has been fixed in trunk and proposed for 6.0.x Fixing it in Tomcat 5 will require the back-porting of the isELIgnored work form Tomcat 6. I've started on that and will proposed a combined patch once I have completed my testing. -- 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
May Chun Chew/FEA/PEC is out of the office.
I will be out of the office starting 01/02/2009 and will not return until 01/08/2009. I am Contactable at (65)97876648. For any urgent matters, pls contact my colleagues, Richard Seng(richard.s...@appliedbiosystems.com at 63629293) and YY Wong at email: yoke.yuen.w...@appliedbiosystems.com. at 63629428. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730601 - /tomcat/current/tc5.5.x/STATUS.txt
Author: markt
Date: Thu Jan 1 12:37:20 2009
New Revision: 730601
URL: http://svn.apache.org/viewvc?rev=730601&view=rev
Log:
Propose a fix for 36923
Modified:
tomcat/current/tc5.5.x/STATUS.txt
Modified: tomcat/current/tc5.5.x/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=730601&r1=730600&r2=730601&view=diff
==
--- tomcat/current/tc5.5.x/STATUS.txt (original)
+++ tomcat/current/tc5.5.x/STATUS.txt Thu Jan 1 12:37:20 2009
@@ -147,3 +147,11 @@
http://svn.apache.org/viewvc?rev=728032&view=rev
+1: markt
-1:
+
+* Fix https://issues.apache.org/bugzilla/process_bug.cgi
+ If EL is disabled, treat ${ as template text
+ This patch includes a port of the work from TC6 that rmeoved the need for the
+ text replacement hack as part of the EL processing.
+ http://people.apache.org/~markt/patches/2009-01-01-bug36923.patch
+ +1: markt
+ -1:
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 36923] Deactivated EL expressions are not parsed for jsp expressions/scriptlets/etc
https://issues.apache.org/bugzilla/show_bug.cgi?id=36923 --- Comment #2 from Mark Thomas 2009-01-01 12:38:11 PST --- I have proposed a port of the fix (with the parsing changes) to 5.5.x -- 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 37084] JspC from ant fails on JSPs that use custom taglib
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Comment #7 from Mark Thomas 2009-01-01 13:00:31 PST --- I have just tested this again and I still can't reproduce the issue you are reporting. If you still see this issue with 5.5.27 then, as previously requested, please provide the simplest possible test case that demonstrates the issue. -- 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 37458] Datarace on org.apache.catalina.loader.WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 Mark Thomas changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #8 from Mark Thomas 2009-01-01 16:25:06 PST --- I've looked at the WebappClassLoader source and I can't see how one thread could set entry.codeBase to null whilst another thread calls Package.isSealed since both calls are inside the sync block. The only way I could see entry.codeBase being null was if getCanonicalFile() throws an IOE (line 2230 in the latest 5.5.x code). I notice you are using RMI. I wonder if this is a factor since there does not appear to be any other reports of this issue. I have a vague recollection of issues with RMI and Tomcat installed in a path with spaces. Might this be affecting you? How repeatable is this? A simple test case that demonstrates the issue would help significantly. Finally, where does JOnAS fit in to all of this. Given the lack of duplicate reports, I wonder if this might be an integration issue of some sort? -- 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 37458] Datarace on org.apache.catalina.loader.WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 --- Comment #9 from Konstantin Kolinko 2009-01-01 18:44:06 PST --- Created an attachment (id=23066) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23066) patch for WebappClassLoader class of tc6.0.x I think the issue is caused by missing (entry.loadedClass == null) inside the synchronized block. (Remember the double-checked locking pattern?) I also wonder if there is a cause for (entry.loadedClass == null) check later in the synchronized block (line 1845, i.e. before calling defineClass()) other than this very bug. Thus the patch. It is against tc6.0.x I do not remember whether pointer assignments are atomic in current Java, and thus whether it is safe to test for (entry.loadedClass) elsewhere in the code. -- 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 37458] Datarace on org.apache.catalina.loader.WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 Konstantin Kolinko changed: What|Removed |Added Status|NEEDINFO|ASSIGNED -- 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 46462] New: JSPWiki JSP compilation prevented by org.apache.jasper.Constants.JSP_PACKAGE_NAME
https://issues.apache.org/bugzilla/show_bug.cgi?id=46462
Summary: JSPWiki JSP compilation prevented by
org.apache.jasper.Constants.JSP_PACKAGE_NAME
Product: Tomcat 6
Version: 6.0.18
Platform: Macintosh
URL: https://issues.apache.org/jira/browse/JSPWIKI-464
OS/Version: Mac OS X 10.4
Status: NEW
Severity: major
Priority: P2
Component: Jasper
AssignedTo: dev@tomcat.apache.org
ReportedBy: ajaqu...@apache.org
Hi,
JSPWiki is currently an Incubator project at Apache. We intend to use the
package name org.apache.jspwiki. However, any classes in this package tree fail
to load when imported into a JSP page, specifically during Jasper's attempt to
compile it.
For example,
<%@ page import="org.apache.jspwiki.WikiPage" %>
does not compile. My colleague Harry Metske traced the cause to this line in
org.apache.jasper.servlet.JasperLoader:
if( !name.startsWith(Constants.JSP_PACKAGE_NAME) ) {
// Class is not in org.apache.jsp, therefore, have our
// parent load it
clazz = parent.loadClass(name);
if( resolve )
resolveClass(clazz);
return clazz;
}
The recommended bug fix would be to append a period (".") to the expression
passed into name.startsWith(), which in this case would then evaluate to
"org.apache.jsp.", and allow JSPWiki classes to load and compile.
This issue is important for us as we emerge from incubation. Lack of a fix
means that JSPWiki cannot release under the desired package name
"org.apache.jspwiki."
See additional commentary in the Apache JIRA database here:
https://issues.apache.org/jira/browse/JSPWIKI-464
--
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 37458] Datarace on org.apache.catalina.loader.WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 --- Comment #10 from Konstantin Kolinko 2009-01-01 21:17:04 PST --- Huh, I now have a TestCase that reproduces the issue. I see the same exception as in comment #4. No wonder, that it is rare. To encounter this the following conditions must be met: 1. A SecurityManager should be present 2. The class that you are loading has to be in a sealed package. 3. It is a race condition. Several iterations in the TestCase are required. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37458] Datarace on org.apache.catalina.loader.WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 --- Comment #11 from Konstantin Kolinko 2009-01-01 21:59:39 PST --- Created an attachment (id=23067) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23067) Test case file 1: TestWebappClassLoader class. -- 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 37458] Datarace on org.apache.catalina.loader.WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 --- Comment #12 from Konstantin Kolinko 2009-01-01 22:00:16 PST --- Created an attachment (id=23068) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23068) Test case file 2: sealed.jar resource file. -- 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 37458] Datarace on org.apache.catalina.loader.WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 --- Comment #13 from Konstantin Kolinko 2009-01-01 22:07:01 PST --- To reproduce: 1. Place TestWebappClassLoader.java and sealed.jar into package org.apache.catalina.loader of TC 6.0 test sources. 2. Use JUnit to run the test case. 3. The following exception is observed: ... Caused by: java.lang.NullPointerException at java.lang.Package.isSealed(Package.java:181) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1832) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:890) at org.apache.catalina.loader.TestWebappClassLoader$FindClassThread.run(TestWebappClassLoader.java:48) -- 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
Re: tcnative API stability/compatibility
Rainer Jung wrote: a) bundling native and org/apache/tomcat/jni code in one place in svn and releasing together or b) separating only the native implementation Option a) was used cause we didn't have separate tcnative release when it was introduced. Since this is now a separate downloadable bundle we should use the option b) and populate Java classes during download task when building Tomcat. Do we want to delete the copies of org/apache/tomcat/jni in TC trunk and 6.0.x and use instead ones downloaded from a tcnative release or an svn external to the new tcnative svn location? I tend to suggest a) and also getting rid of the redundant copies of the classes in TC trunk and 6, but I'm not sure if I noticed all implications. We cannot use that option because of separate release cycles. I was trying to keep them together, but other folks didn't agree with that, so now we'll have to choose the option b), which is fine as well. It needs some build process changes, but that shouldn't be a problem. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r730678 - /tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt
Author: mturk Date: Thu Jan 1 23:36:30 2009 New Revision: 730678 URL: http://svn.apache.org/viewvc?rev=730678&view=rev Log: Cast my vote to typo patches Modified: tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt Modified: tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt?rev=730678&r1=730677&r2=730678&view=diff == --- tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt (original) +++ tomcat/connectors/branches/native/1.1.x/jni/STATUS.txt Thu Jan 1 23:36:30 2009 @@ -35,6 +35,6 @@ http://people.apache.org/~rjung/patches/tcnative-sync.patch Partial backport of http://svn.apache.org/viewvc?view=rev&revision=730523 - +1: rjung + +1: rjung, mturk 0: -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
