[GUMP] Build Failure - jakarta-tomcat-5

2003-03-02 Thread bobh

This email is autogenerated from the output from:



Buildfile: build.xml

prepare-release:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/bin
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/src

init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib

deploy-static:

deploy:
 [echo] Target: Servlet API - Dist ...

prepare:

static:

compile:

examples:

javadoc:

jar:
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-servletapi-5/jsr154/build

dist:
 [echo] Target: JSP API - Dist ...

prepare:

static:

compile:

examples:

javadoc:

jar:
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-servletapi-5/jsr152/build

dist:
 [echo] Target: Modeler - Dist ...

BUILD FAILED
file:///home/rubys/jakarta/jakarta-tomcat-5/build.xml:577: Basedir 
/usr/local/commons-modeler-1.1dev does not exist

Total time: 7 seconds

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



cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java

2003-03-02 Thread remm
remm2003/03/02 08:11:58

  Modified:coyote/src/java/org/apache/coyote/tomcat5
MapperListener.java
  Log:
  - Log register/unregister contexts and wrappers as debug.
  
  Revision  ChangesPath
  1.6   +7 -6  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/MapperListener.java
  
  Index: MapperListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/MapperListener.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- MapperListener.java   17 Feb 2003 05:13:14 -  1.5
  +++ MapperListener.java   2 Mar 2003 16:11:57 -   1.6
  @@ -287,8 +287,8 @@
   contextName = "";
   }
   
  -log.info(sm.getString
  - ("mapperListener.registerContext", contextName));
  +log.debug(sm.getString
  +  ("mapperListener.registerContext", contextName));
   
   Object context = 
   mBeanServer.getAttribute(objectName, "mappingObject");
  @@ -328,8 +328,8 @@
   contextName = "";
   }
   
  -log.info(sm.getString
  - ("mapperListener.unregisterContext", contextName));
  +log.debug(sm.getString
  +  ("mapperListener.unregisterContext", contextName));
   
   mapper.removeContext(hostName, contextName);
   
  @@ -362,8 +362,9 @@
   contextName = "";
   }
   
  -log.info(sm.getString
  - ("mapperListener.registerWrapper", wrapperName, contextName));
  +log.debug(sm.getString
  +  ("mapperListener.registerWrapper", 
  +   wrapperName, contextName));
   
   String[] mappings = (String[])
   mBeanServer.invoke(objectName, "findMappings", null, null);
  
  
  

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



cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java

2003-03-02 Thread remm
remm2003/03/02 08:16:47

  Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
  Log:
  - Properly restore path after failing to map welcome files.
  
  Revision  ChangesPath
  1.7   +7 -2  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java
  
  Index: Mapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Mapper.java   17 Feb 2003 16:31:44 -  1.6
  +++ Mapper.java   2 Mar 2003 16:16:47 -   1.7
  @@ -525,7 +525,7 @@
   } catch(NamingException nex) {
   // Swallow not found, since this is normal
   }
  -if(file != null && !(file instanceof DirContext) ) {
  +if (file != null && !(file instanceof DirContext) ) {
   if(logger.isTraceEnabled())
   logger.trace("Found welcome-file: " + path);
   internalMapExtensionWrapper(extensionWrappers,
  @@ -538,7 +538,12 @@
   (path.getBuffer(), path.getStart(), 
path.getLength());
   }
   }
  -}   
  +}
  +if (mappingData.wrapper == null) {
  +// Restore the path if no welcome files was found
  +path.setOffset(pathOffset);
  +path.setEnd(pathEnd);
  +}
   }
   }
   
  
  
  

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



Re: [4.1.21] Stability rating

2003-03-02 Thread Hans Bergsten
Remy Maucherat wrote:
Costin Manolache wrote:

Remy Maucherat wrote:



[ ] Alpha
[ ] Beta
[X] Stable (GA)

Please vote (after testing the release, if possible ;).


It works for me. It would be nice to fix the jspc bugs tough.
I fixed a small regression in modeler(HEAD) so it can be used as drop-in
replacement ( if you have non-supported components - like other 
connectors -
to avoid the exceptions )


Good. For JspC, I think there are more urgent problems than the tag 
related problem, such as the mangling issues which just got fixed in 
Tomcat 5. That's why I didn't bother trying to apply whatever patch was 
needed for tags, knowing it would still be broken.
Well, if you apply the patch that fixes the "NPE when packaged tag
libraries are used" proble, it would be _less_ broken ;-) Seriously,
this patch has been submitted by at least two people, has been available
for months, and does not cause any regression. Why not just apply it
and move on?
The "mangling problem" (I assume you refer to problems with filepath
names containing dots) is far less common, and if it's hard to fix (I
haven't looked at it), it could wait. But if the TC 5 patch can easily
be ported to 4.1, why not do it? Even if you refer to some problem I'm
not aware of, fixing the NPE problem can hardly be a bad idea since
it affects _everyone_ who tries to use JSPC with packaged tag libraries
(the majority case in the real world).
> [...]

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


cvs commit: jakarta-tomcat-5 build.properties.default

2003-03-02 Thread remm
remm2003/03/02 10:49:33

  Modified:.build.properties.default
  Log:
  - Update to digester 1.4.1.
  
  Revision  ChangesPath
  1.72  +3 -3  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.71
  retrieving revision 1.72
  diff -u -r1.71 -r1.72
  --- build.properties.default  1 Mar 2003 17:34:04 -   1.71
  +++ build.properties.default  2 Mar 2003 18:49:33 -   1.72
  @@ -79,10 +79,10 @@
   
   
   # - Commons Digester, version 1.4 or later -
  -commons-digester.home=${base.path}/commons-digester-1.4
  +commons-digester.home=${base.path}/commons-digester-1.4.1
   commons-digester.lib=${commons-digester.home}
   commons-digester.jar=${commons-digester.lib}/commons-digester.jar
  
-commons-digester.loc=http://www.apache.org/dist/jakarta/commons/digester/binaries/commons-digester-1.4.tar.gz
  
+commons-digester.loc=http://www.apache.org/dist/jakarta/commons/digester/binaries/commons-digester-1.4.1.tar.gz
   
   
   # - Commons Expression Language (EL) -
  
  
  

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



DO NOT REPLY [Bug 17572] New: - Tomcat manager Ant tasks should support "failonerror" attribute

2003-03-02 Thread 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=17572

Tomcat manager Ant tasks should support "failonerror" attribute

   Summary: Tomcat manager Ant tasks should support "failonerror"
attribute
   Product: Tomcat 4
   Version: 4.1.18
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat manager Ant tasks should support "failonerror" attribute. For example if 
I want to restart context by using "stop" and "start" and if the context has 
not been started it'll fail on stop and will never get to start. (I know there 
is restart task but ...)

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



Re: [4.1.21] Stability rating

2003-03-02 Thread Costin Manolache
Hans Bergsten wrote:

>> Good. For JspC, I think there are more urgent problems than the tag
>> related problem, such as the mangling issues which just got fixed in
>> Tomcat 5. That's why I didn't bother trying to apply whatever patch was
>> needed for tags, knowing it would still be broken.
> 
> Well, if you apply the patch that fixes the "NPE when packaged tag
> libraries are used" proble, it would be _less_ broken ;-) Seriously,
> this patch has been submitted by at least two people, has been available
> for months, and does not cause any regression. Why not just apply it
> and move on?


You are a tomcat committer just like Remy or everyone else. Commit 
the fix - and if someone has a problem with it he can -1 and
propose a better solution. 


> The "mangling problem" (I assume you refer to problems with filepath
> names containing dots) is far less common, and if it's hard to fix (I
> haven't looked at it), it could wait. But if the TC 5 patch can easily
> be ported to 4.1, why not do it? Even if you refer to some problem I'm
> not aware of, fixing the NPE problem can hardly be a bad idea since
> it affects _everyone_ who tries to use JSPC with packaged tag libraries
> (the majority case in the real world).


Good question. Why not do it ? 

Thanks for volunteering ! 


Costin



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



cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_config_file.c

2003-03-02 Thread costin
costin  2003/03/02 12:46:33

  Modified:jk/native2/common jk_config_file.c
  Log:
  Save to the same file
  
  Revision  ChangesPath
  1.9   +1 -1  jakarta-tomcat-connectors/jk/native2/common/jk_config_file.c
  
  Index: jk_config_file.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_config_file.c,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- jk_config_file.c  28 Feb 2003 05:05:03 -  1.8
  +++ jk_config_file.c  2 Mar 2003 20:46:33 -   1.9
  @@ -374,7 +374,7 @@
   } else if( strcmp( name, "debugEnv" )==0 ) {
   env->debug=atoi( value );
   } else if( strcmp( name, "save" )==0 ) {
  -return jk2_config_file_saveConfig(env, cfg, value);
  +return jk2_config_file_saveConfig(env, cfg, cfg->file);
   } else {
   return JK_ERR;
   }
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c

2003-03-02 Thread costin
costin  2003/03/02 12:48:56

  Modified:jk/native2/common jk_worker_status.c
  Log:
  The entries in the scoreboard will be presented as beans. A bit hacky, but
  works without too much overhead.
  
  Revision  ChangesPath
  1.38  +156 -4jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c
  
  Index: jk_worker_status.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- jk_worker_status.c1 Mar 2003 05:49:58 -   1.37
  +++ jk_worker_status.c2 Mar 2003 20:48:56 -   1.38
  @@ -77,6 +77,8 @@
   
   #define JK_CHECK_NULL( str ) ( ((str)==NULL) ? "null" : (str) )
   
  +/** Display info for one endpoint
  + */
   static void jk2_worker_status_displayStat(jk_env_t *env, jk_ws_service_t *s,
 jk_stat_t *stat,
 int *totalReqP, int *totalErrP,
  @@ -127,6 +129,8 @@
   *totalErrP=totalErr;
   }
   
  +/** Displays the totals
  + */
   static void jk2_worker_status_displayAggregate(jk_env_t *env, jk_ws_service_t *s,
  int totalReq, int totalErr,
  unsigned long totalTime, unsigned 
long maxTime )
  @@ -150,6 +154,11 @@
   s->jkprintf(env, s, "\n");
   }
   
  +/** Information for the internal endpoints ( in this process ).
  +Duplicates info from the scoreboard. This is used for debugging and for
  +cases where scoreboard is not available. No longer included in the
  +normal display to avoid confusion.
  + */
   static void jk2_worker_status_displayEndpointInfo(jk_env_t *env, jk_ws_service_t *s,
 jk_workerEnv_t *wenv)
   {
  @@ -193,6 +202,10 @@
   totalReq, totalErr, totalTime, maxTime);
   }
   
  +/** Special case for endpoints - the info is stored in a shm segment, to be able
  + *   to access info from all other processes in a multi-process server.
  + *  For single process servers - the scoreboard is just a local char*.
  + */
   static void jk2_worker_status_displayScoreboardInfo(jk_env_t *env, jk_ws_service_t 
*s,
   jk_workerEnv_t *wenv)
   {
  @@ -416,6 +429,119 @@
   s->jkprintf( env,s , "\n" );
   }
   
  +/** List metadata for endpoints ( from scoreboard ) using the remote-jmx style
  +  */
  +static void jk2_worker_status_lstEndpoints(jk_env_t *env, jk_ws_service_t *s,
  +   jk_workerEnv_t *wenv)
  +{
  +jk_map_t *map=wenv->initData;
  +int i;
  +int j;
  +int totalReq=0;
  +int totalErr=0;
  +unsigned long totalTime=0;
  +unsigned long maxTime=0;
  +int needHeader=JK_TRUE;
  +
  +if( wenv->shm==NULL || wenv->shm->head==NULL) {
  +return;
  +}
  +
  +for( i=1; i < wenv->shm->head->lastSlot; i++ ) {
  +jk_shm_slot_t *slot= wenv->shm->getSlot( env, wenv->shm, i );
  +
  +if( slot==NULL ) continue;
  +
  +if( strncmp( slot->name, "epStat", 6 ) == 0 ) {
  +/* This is an endpoint slot */
  +void *data=slot->data;
  +char *name=JK_CHECK_NULL(slot->name);
  +
  +for( j=0; jstructCnt ; j++ ) {
  +jk_stat_t *statArray=(jk_stat_t *)data;
  +jk_stat_t *stat=statArray + j;
  +
  +s->jkprintf(env, s, "N|endpoint|endpoint:%s%d\n", name, j );
  +
  +s->jkprintf(env, s, "G|endpoint:%s%d|id\n", name, j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|requests\n", name, j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|errors\n", name, j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|lastRequest\n", name, j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|lastConnectionTime\n", name, 
j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|totalTime\n", name, j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|maxTime\n", name, j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|requestStart\n", name, j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|jkTime\n", name, j); 
  +s->jkprintf(env, s, "G|endpoint:%s%d|requestEnd\n", name, j);
  +}
  +}
  +}
  +}
  +
  +
  +/** List values for endpoints ( from scoreboard ) using the remote-jmx style
  +  */
  +static void jk2_worker_status_dmpEndpoints(jk_env_t *env, jk_ws_service_t *s,
  +   jk_workerEnv_t *wenv)
  +{
  +jk_map_t *map=wenv->initData;
  +int i;
  +int j;
  +int totalReq=0;
  +int totalErr=0;
  +unsigned long totalTime=0;
  +unsigned long maxTime=0;
  +   

Re: [4.1.21] Stability rating

2003-03-02 Thread Hans Bergsten
Costin Manolache wrote:
Hans Bergsten wrote:


Good. For JspC, I think there are more urgent problems than the tag
related problem, such as the mangling issues which just got fixed in
Tomcat 5. That's why I didn't bother trying to apply whatever patch was
needed for tags, knowing it would still be broken.
Well, if you apply the patch that fixes the "NPE when packaged tag
libraries are used" proble, it would be _less_ broken ;-) Seriously,
this patch has been submitted by at least two people, has been available
for months, and does not cause any regression. Why not just apply it
and move on?


You are a tomcat committer just like Remy or everyone else. Commit 
the fix - and if someone has a problem with it he can -1 and
propose a better solution. 
Yes, I am, but it's been years since I committed anything and my
environment is not set up for it. I simply don't have the time right
now to fix my environment (figure out how to set up ssh, find out
if I have submitted a signature to ASF and if so, where it is, find out
what my CVS password is, etc. etc.), so my contributions to this
project will be in the form of patches in Bugzilla. And yes, some
nagging now and then when the patches are not applied ;-)
I know I can not demand that someone else commits the patches, and
in a prefect world I would find the time to do it myself. But I find
it quite annoying that the JSPC bugs are allowed to remain from
release to release when there are tested patches available in
Bugzilla.
Anyway, since committing the patches myself is not an option at this
time (but may be in the future), my only alternatives are to continue
to submit patches and nag, or to stop contributing altogether. Hey, I
can patch my own copy to fix the problems I find. Believe it or not,
I'm actually trying to help out by submitting patches and reminding
you of them. But if you want me to shut up, I'll do that. Even
submitting patches takes time and if you're just going to ignore them,
that's time I can use for other things ...
Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [4.1.21] Stability rating

2003-03-02 Thread Costin Manolache
Hans Bergsten wrote:

>> You are a tomcat committer just like Remy or everyone else. Commit
>> the fix - and if someone has a problem with it he can -1 and
>> propose a better solution.
> 
> Yes, I am, but it's been years since I committed anything and my
> environment is not set up for it. I simply don't have the time right
> now to fix my environment (figure out how to set up ssh, find out
> if I have submitted a signature to ASF and if so, where it is, find out
> what my CVS password is, etc. etc.), so my contributions to this
> project will be in the form of patches in Bugzilla. And yes, some
> nagging now and then when the patches are not applied ;-)

Just send a mail to root with the public ssh key. Setting up ssh 
shouldn't take more than 10 minutes after the key is set. I would 
be happy to help - send me a private email if you run into any
problem.
If you are on windows - install cygwin and you'll get both ssh 
and cvs, it's the easiest way around.

All you need is to install ssh, generate a key pair and send the public
key to root ( he'll know how to put it in authorized_keys ). 


> I know I can not demand that someone else commits the patches, and
> in a prefect world I would find the time to do it myself. But I find
> it quite annoying that the JSPC bugs are allowed to remain from
> release to release when there are tested patches available in
> Bugzilla.

Well - one reason for that is that committers who have expertise in JSP and
could apply the patches don't find the time to set up their CVS :-)
Yes, it is quite annoying. 


> Anyway, since committing the patches myself is not an option at this
> time (but may be in the future), my only alternatives are to continue
> to submit patches and nag, or to stop contributing altogether. Hey, I
> can patch my own copy to fix the problems I find. Believe it or not,
> I'm actually trying to help out by submitting patches and reminding
> you of them. But if you want me to shut up, I'll do that. Even
> submitting patches takes time and if you're just going to ignore them,
> that's time I can use for other things ...

I am going to ignore them for now - but I would be happy to help you 
get the CVS setup. Just send me a mail with your environment ( win, unix,
etc), I'm pretty familiar with ssh and cvs.


Costin


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



DO NOT REPLY [Bug 17578] New: - Jasper2 can't change browser's charset

2003-03-02 Thread 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=17578

Jasper2 can't change browser's charset 

   Summary: Jasper2 can't change browser's charset
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In a common JSP, if I set the charset by using HTML form, it will automatically 
change the charset in the browser.

For example:
<%@ page language="java" contentType="text/html" %>


 


   Hello World! Testing...




In the above JSP file, if I load it in Tomcat 4.1.8, It can automatically 
change the charset to UTF-8 in the browser. But after I use Jasper2 to convert 
the JSP to Java source file and compiled it. It can't, and always set the 
charset to ISO-8859-1.

If I add the charset in the JSP as

<%@ page language="java" contentType="text/html; charset=UTF-8" %>

I can't display any Far East fonts, such as Chinese. I think Jasper should 
detect if JSP is setting to use Text/Html, it should detect if there any META 
data to set the Charset, if there is, following the HTML charset, otherwise set 
to the default charset ISO-8859-1.

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



[PATCH] jakarta-servletapi-5: Latest JSP 2.0 updates

2003-03-02 Thread Mark Roth
/jsr152/src/share/javax/servlet/jsp/JspContext.java:
- Added throws clause for NullPointerException for null
  name parameter to the following methods:
  findAttribute( name )
  removeAttribute( name )
  removeAttribute( name, scope )
  getAttributesScope( name )
/jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java
- We now allow null to be passed for defaultPrefix for cases where
  a function must have a prefix.
/jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd:
/jsr154/src/share/dtd/web-jsptaglibrary_2_0.xsd:
- Updated part of the description of the taglib element
  Before:
The taglib element contains tag elements.
  After:
The taglib element contains, among other
things, tag and tag-file elements.
- Removed tag-file-name-uniqueness constraint
- Upgraded tag-name-uniqueness constraint to check
  uniqueness across both tag and tag-file elements.
  (Xerces has a bug that causes this not to work, yet
  but this should work, according to Kohsuke and
  Norm)
- langage --> language
- Removed uppercase versions of body-content types,
  TAGDEPENDENT, EMPTY, and SCRIPTLESS
- Renamed j2ee:tag-extensionType to
  j2ee:tld-extensionType
- Removed references to old mustUnderstand attribute
- Added function-extension element for extension of
  function elements in addition to taglib and tag
  elements.
---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
Index: jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd
===
RCS file: 
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd,v
retrieving revision 1.9
diff -u -r1.9 web-jsptaglibrary_2_0.xsd
--- jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd  14 Feb 2003 19:34:43 - 
 1.9
+++ jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd  3 Mar 2003 02:24:02 -
@@ -10,7 +10,7 @@
 
   
 
-  @(#)web-jsptaglibrary_2_0.xsds   1.31 02/11/03
+  @(#)web-jsptaglibrary_2_0.xsds   1.32 03/02/03
 
   
   
@@ -99,25 +99,13 @@
   

 
- The taglib element contains tag elements.
+ The taglib element contains, among other things, tag and
+ tag-file elements.
  The name subelements of these elements must each be unique.
 

   
-  
-  
-
-
-
-  
-   
-
- The taglib element contains tag-file elements.
- The name subelements of these elements must each be unique.
-
-   
-  
-  
+  
   
 
 
@@ -150,7 +138,7 @@
 
tagdependentThe body of the tag is interpreted by the tag
implementation itself, and is most likely
-   in a different "langage", e.g embedded SQL
+   in a different "language", e.g embedded SQL
statements.
 
JSP The body of the tag contains nested JSP
@@ -168,12 +156,9 @@
 
   

-   


-   

-   
   
 
   
@@ -227,6 +212,10 @@
example Optional informal description of an
example of a use of this function
 
+   function-extension  Zero or more extensions that provide extra
+   information about this function, for tool
+   consumption
+
   
 
 
@@ -308,6 +297,19 @@

 
   
+  
+   
+ 
+
+   Function extensions are for tool use only and must not affect
+   the behavior of a container.
+
+ 
+   
+  
 
 
   
@@ -344,41 +346,6 @@
 
 
 
-  
-
-  
-
-   The tag-extensionType is used to indicate
-   extensions to the specific TLD element.
-
-   It is used by elements to designate an extension block
-   that is targeted to a specific extension designated by
-   a set of extension elements that are declared by a
-   namespace. The namespace identifies the extension to
-   the tool that processes the extension.
-
-   The type of the extension-element is abstract. Therefore,
-   a concrete type must be specified by the TLD using
-   xsi:type attribute for each extension-element.
-
-  
-
-
-
-  
-
-
-
-
-
-  
-
-
-
   
 
   
@@ -436,18 +403,14 @@
 
   
   

  
 
Tag extensions are for tool use only and must not affect
-   the behavior of a container.  The TLD extension mechanism
-   only allows ignorable extensions (i.e. those without a
-   mustUnderstand attribute).  A Tag Library is considered
-   invalid if it requires an extension that must be
-   understood by setting mustUnderstand="true".
+   the behavior of a container.
 
  

@@ -572,18 +535,14 @@
 
 

DO NOT REPLY [Bug 17579] New: - "port" in "jk_channel_socket_private" should be "int" instead of "short"

2003-03-02 Thread 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=17579

"port" in "jk_channel_socket_private" should be "int" instead of "short"

   Summary: "port" in "jk_channel_socket_private" should be "int"
instead of "short"
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


For JK2 connector's native part, in "jk_channel_socket.c", type of 
member "port" in structure "jk_channel_socket_private" should be "int" instead 
of "short", otherwise, if a socket channel's port will be reset to default
(8009) if it larger than 32767 while port larger than 32767 is usable.

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



cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java

2003-03-02 Thread amyroh
amyroh  2003/03/02 23:51:18

  Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch TagLibraryInfoImpl.java
  Log:
  Apply a patch for bugzilla 14302.
  This "fixes a bug in TagLibraryInfoImpl that currently makes JspC totally
  useless when the application contains tag libraries packaged as JAR files."
  Submitted by Hans Bergsten <[EMAIL PROTECTED]>.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.2.1   +142 -146  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  --- TagLibraryInfoImpl.java   16 May 2002 20:59:21 -  1.2
  +++ TagLibraryInfoImpl.java   3 Mar 2003 07:51:18 -   1.2.2.1
  @@ -138,93 +138,89 @@
   }
   
   public TagLibraryInfoImpl(JspCompilationContext ctxt, String prefix, 
  -   String uriIn, String[] location,
  -   ErrorDispatcher err) 
  +  String uriIn, String[] location,
  +  ErrorDispatcher err) 
   throws JasperException {
   
   super(prefix, uriIn);
   
  - this.ctxt = ctxt;
  - this.err = err;
  +this.ctxt = ctxt;
  +this.err = err;
   ZipInputStream zin;
   InputStream in = null;
   URL url = null;
   boolean relativeURL = false;
   
  - if (location == null) {
  - // The URI points to the TLD itself or to a jar
  - // file where the TLD is located
  - int uriType = TldLocationsCache.uriType(uri);
  - if (uriType == TldLocationsCache.ABS_URI) {
  - err.jspError("jsp.error.taglibDirective.absUriCannotBeResolved",
  -  uri);
  - } else if (uriType == 
  -TldLocationsCache.NOROOT_REL_URI) {
  - uri = ctxt.resolveRelativeUri(uri);
  - }
  - location = new String[2];
  - location[0] = uri;
  - if (uri.endsWith("jar")) {
  - location[1] = "META-INF/taglib.tld";
  - }
  - }
  +if (location == null) {
  +// The URI points to the TLD itself or to a jar
  +// file where the TLD is located
  +int uriType = TldLocationsCache.uriType(uri);
  +if (uriType == TldLocationsCache.ABS_URI) {
  +err.jspError("jsp.error.taglibDirective.absUriCannotBeResolved",
  +uri);
  +} else if (uriType == 
  +TldLocationsCache.NOROOT_REL_URI) {
  +uri = ctxt.resolveRelativeUri(uri);
  +}
  +location = new String[2];
  +location[0] = uri;
  +if (uri.endsWith("jar")) {
  +location[1] = "META-INF/taglib.tld";
  +}
  +}
   
   if (!location[0].endsWith("jar")) {
  - // Location points to TLD file
  - try {
  - in = getResourceAsStream(location[0]);
  - if (in == null) {
  - throw new FileNotFoundException(location[0]);
  - }
  - } catch (FileNotFoundException ex) {
  - err.jspError("jsp.error.file.not.found", location[0]);
  - }
  - // Now parse the tld.
  - parseTLD(ctxt, location[0], in);
  - } else {
  - // Location points to a jar file
  - // tag library in jar file
  - JarFile jarFile = null;
  - ZipEntry jarEntry = null;
  - InputStream stream = null;
  - try {
  +// Location points to TLD file
  +try {
  +in = getResourceAsStream(location[0]);
  +if (in == null) {
  +throw new FileNotFoundException(location[0]);
  +}
  +} catch (FileNotFoundException ex) {
  +err.jspError("jsp.error.file.not.found", location[0]);
  +}
  +// Now parse the tld.
  +parseTLD(ctxt, location[0], in);
  +} else {
  +// Location points to a jar file
  +// tag library in jar file
  +JarFile jarFile = null;
  +ZipEntry jarEntry = null;
  +InputStream stream = null;
  +try {
   String path = location[0] ;
  -if(ctxt.getClassLoader() != null &&
  -   URLClassLoader.class.equals(ctxt.getClassLoader().getClass())
  -   && path.startsWith("/"))
  -   path = path.substring(1,path.length()) ;
   url = ctxt.getResource

Re: [4.1.21] Stability rating

2003-03-02 Thread Amy Roh
Hans Bergsten wrote:
Remy Maucherat wrote:


[X] Alpha
[ ] Beta
[ ] Stable (GA)



The TagLibraryInfoImpl patch attached to bug 14302 is still not
applied, so JSPC fails with an NPE for any web app that contains
a tag library packaged as a JAR file (with the TLD in the JAR file).
I just applied the patch.

Amy

Other than that, all my tests works okay.

Hans




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


Re: [4.1.21] Stability rating

2003-03-02 Thread Amy Roh
Remy Maucherat wrote:

[ ] Alpha
[ ] Beta
[X] Stable (GA)

Amy

Please vote (after testing the release, if possible ;).

Thanks,
Remy
-
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]