cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources web_23.dtd
pierred 00/10/30 06:35:52 Modified:jasper/src/share/org/apache/jasper/resources web_23.dtd Log: Latest web.dtd in sync with catalina. Revision ChangesPath 1.2 +83 -25 jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/web_23.dtd Index: web_23.dtd === RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/web_23.dtd,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- web_23.dtd2000/10/04 05:10:58 1.1 +++ web_23.dtd2000/10/30 14:35:51 1.2 @@ -11,8 +11,8 @@ context-param*, filter*, filter-mapping*, listener*, servlet*, servlet-mapping*, session-config?, mime-mapping*, welcome-file-list?, error-page*, taglib*, -resource-ref*, security-constraint*, login-config?, security-role*, -env-entry*, ejb-ref*) +resource-env-ref*, resource-ref*, security-constraint*, +login-config?, security-role*, env-entry*, ejb-ref*) !-- Declares a filter in the web application deployment descriptor. The filter is mapped to either a servlet or a URL pattern in the @@ -33,7 +33,7 @@ !ELEMENT filter-class (#PCDATA) !-- Declaration of the filter mappings in this web application. -The conatiner used the filter-mapping declarations to decide which +The conatiner uses the filter-mapping declarations to decide which filters to apply to a request, and in what order. The container matches the request URI to a Servlet in the normal way. To determine which filters to apply it matches filter-mapping declarations either @@ -109,7 +109,8 @@ servlet. If a jsp-file is specified and the load-on-startup element is present, then the JSP should be precompiled and loaded. -- -!ELEMENT servlet (icon?, servlet-name, display-name?, description?, (servlet-class|jsp-file), init-param*, load-on-startup?, security-role-ref*) +!ELEMENT servlet (icon?, servlet-name, display-name?, description?, +(servlet-class|jsp-file), init-param*, load-on-startup?, security-role-ref*) !-- The servlet-name element contains the canonical name of the servlet. -- @@ -122,7 +123,7 @@ !ELEMENT servlet-class (#PCDATA) !-- The jsp-file element contains the full path to a JSP file within -the web application. -- +the web application beginning with a '/'. -- !ELEMENT jsp-file (#PCDATA) @@ -147,7 +148,7 @@ !ELEMENT servlet-mapping (servlet-name, url-pattern) !-- The url-pattern element contains the url pattern of the -mapping. Must follow the rules specified in Section 10 of the Servlet +mapping. Must follow the rules specified in Section 11.2 of the Servlet API Specification. -- !ELEMENT url-pattern (#PCDATA) @@ -169,12 +170,12 @@ !ELEMENT mime-mapping (extension, mime-type) !-- The extension element contains a string describing an -extension. example: txt -- +extension. example: "txt" -- !ELEMENT extension (#PCDATA) !-- The mime-type element contains a defined mime type. example: -text/plain -- +"text/plain" -- !ELEMENT mime-type (#PCDATA) @@ -223,10 +224,37 @@ !ELEMENT location (#PCDATA) +!-- The resource-env-ref element contains a declaration of a component's +reference to an administered object associated with a resource in the +component's environment. It consists of an optional description, the +resource environment reference name, and an indication of the resource +environment reference type expected by the component's code. Examples: + resource-env-ref +resource-env-ref-namejms/StockQueue/resource-env-ref-name +resource-env-ref-typejavax.jms.Queue/resource-env-ref-type + /resource-env-ref +-- + +!ELEMENT resource-env-ref (description?, resource-env-ref-name, +resource-env-ref-type) + +!-- The resource-env-ref-name element specifies the name of a +resource environment reference; its value is the environment entry +name used in code. -- + +!ELEMENT resource-env-ref-name (#PCDATA) + +!-- The resource-env-ref-type element specifies the type of a +resource environment reference. Web containers in J2EE are requird +to support javax.jms.Topic and javax.jms.Queue. -- + +!ELEMENT resource-env-ref-type (#PCDATA) + !-- The resource-ref element contains a declaration of a Web Application's reference to an external resource. -- -!ELEMENT resource-ref (description?, res-ref-name, res-type, res-auth) +!ELEMENT resource-ref (description?, res-ref-name, res-type, res-auth, +res-sharing-scope?) !-- The res-ref-name element specifies the name of the resource factory reference name. -- @@ -241,14 +269,27 @@ !-- The res-auth element indicates whether the application component code performs resource signon programmatically or whether the container signs onto the resource based on the principle mapping
Re: Tomcat 3.2 release (again) ?
On Mon, 30 Oct 2000, Petr Jiricka wrote: Hi, I'd like to ask where the Tomcat 3.2 final release discussions are right now. It seemed that the last outstanding issue was the compilation under JDK 1.1, but that should be fixed now. So is there still something that needs to be fixed ? I would really appreciate if the release could happen within the next few days. Thanks Petr session/cookie and other patches (date spinlock and one more i think) have not been integrated...can someone dump em in and release b7 or final ? -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/threads Reaper.java
Larry,
What bug or bug report is associated with this? Can you give me some clues
if you don't know?
On Mon, 30 Oct 2000, Larry Isaacs wrote:
Arion Yu should get credit for finding this first.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 26, 2000 10:45 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/util/threads Reaper.java
larryi 00/10/26 19:44:58
Modified:src/share/org/apache/tomcat/util/threads Reaper.java
Log:
Add synchronized so the notify() call won't throw an exception and prevent
Tomcat from shutting down.
Revision ChangesPath
1.3 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/util/threads/Reaper.java
Index: Reaper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/threads/Reaper.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Reaper.java 2000/09/24 23:03:14 1.2
+++ Reaper.java 2000/10/27 02:44:58 1.3
@@ -120,7 +120,7 @@
this.start();
}
-public void stopReaper() {
+public synchronized void stopReaper() {
running=false;
this.notify();
}
-
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]
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jboss on tomcat update
For what it's worth... -- Forwarded message -- Date: Mon, 30 Oct 2000 19:03:39 -0500 From: Free Software Foundation [EMAIL PROTECTED] To: Aaron Mulder [EMAIL PROTECTED] Subject: Re: Java, GPL, APL Aaron Mulder wrote: Okay, I've heard too many opinions on the GPL, so I'm taking it to the source. I will discuss this in general terms if it's OK with you. There exist two open-source products. One uses an Apache license. One uses a GPL license. They are complimentary products - the capabilites of both together are greater than that of either alone. They can be run totally independently, communicating over the network, but the performance is not great. They can also be run together, in the same Java VM, and the performance is much better. The GPL product has included some code that configures and launches the APL product. It directly references Java classes (such as the startup class) that are part of the APL product. This is what allows you to run them together within one VM. The APL product does not ever reference the GPL code directly - only through the standard interfaces defined by Sun in one of the javax.* packages. After the startup sequence, the GPL product never refers to the APL code directly at all (essentially, the APL product is a client of the GPL product). So the questions are: 1) Is it legal for the APL product to work with the GPL product through the standard interfaces defined by Sun in the javax.* packages? We suspect yes, since this is a standard and the APL program never reaches "through" those standard interfaces to deal directly with the GPL code. It appears that you combine the APL'ed software with the GPL'ed software to form a larger program. This is not permitted, since the APL is incompatible with the GPL. 2) Is it legal for the GPL product to directly reference APL classes to configure and start the APL product? No, that is not legal, because you are combining the two programs to form a larger program. 2b) If there is a problem with this, is there any way to configure and start the two products in the same VM? Not if they make calls to each other. You'll need to get the license of one or the other changed to a dual license---the disjunction of the GPL and the APL. 3) Would it be appropriate to package the GPL product and "glue code" (startup and configuration for APL product) together, and leave the APL product separate? We believe this is legally the same as distributing them together, and thus, is not permitted. 4) Would it be legal to package everything together, and create one combined download that "out-of-the-box" runs both products together? This is the subject of much debate. That is not permitted since the APL is incompatible with the GPL. So it's not clear whether the phrase "contains or is derived from" would apply to this single unified package. We argue that it definitely does, when you combine them together to form a larger program. -- Bradley M. Kuhn Free Software Foundation | Phone: +1-617-542-5942 59 Temple Place, Suite 330 | Fax: +1-617-542-2652 Boston, MA 02111-1307 USA | Web: http://www.gnu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jBoss-Dev] Re: jboss on tomcat update
no be careful 2b is about containment, containment is the STRONGEST, definition of the work is "CMD'ed work" and that is the MBeans in our case (they are GPL). I need to go back to work / marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Öberg |Sent: Sunday, October 29, 2000 11:42 PM |To: jBoss Developer |Cc: tomcat-dev; Java Apache Framework |Subject: Re: [jBoss-Dev] Re: jboss on tomcat update | | |Dear all, | |I've read through the GPL license, and I'm not a legal expert but from |what I can see paragraph 2b is a killer. For example, I cannot see how |XO3 can redistribute jBoss with Tomcat and reasonably call it "mere |aggregation" (i.e. our JMX integration is not "mere aggregation", it is |much more than that), thus OpenJoda needs to "be licensed as a whole at |no charge to all third parties under the terms of this License." Which |breaks Tomcat's license, so it's out of the question. | |After listening to Marc's and all others arguments back and forth I have |the following thoughts (right or wrong, here they are): |* GPL paragraph 2b is a killer, and I cannot see how we can |bundle/integrate Tomcat without having to apply GPL to the whole |shebang. Sorry Marc, I just don't see it. The clause does not say "mere |aggregation in a Program" (which is what we do). It says "mere |aggregation of another work not based on the Program with the Program |(or with a work based on the Program) on a volume of a storage or |distribution medium", which is a completely different thing, closer to |Oles reference to RedHat CD's (BTW, yes I know I'm violating GPL |copyright by quoting it. So sue me) |* *Regardless* of whether we can do this or not, we can't "win". I don't |really care how *we* interpret GPL, and from what it seems our |interpretation is the loosest ever. It will do two things: |1) GPL hardcores will, pretty much, hate jBoss. Slashdot, here we come.. |2) "Suits" will stay away from jBoss ANYWAY, because it uses GPL. "So, |we can use it? Nah, my left foot says no, so that's it. I'm going with |OpenEJB. BSD gives me a fuzzy feeling". I don't care if it's rational or |not; there you have it. | |To me the solution seems clear. IMHO jBoss is not a "baby" anymore. We |do not have anything to gain by doing a crusade with GPL. We may not be |exactly where we want just yet (i.e. Project Game Over is not done), but |we sure are "enough" along the way to getting there. I may be wrong, but |that's my gut feeling anyway :-) | |So, for it to grow to the heights we want it if changing the license to |APL or MPL or BSD, or whatever makes sense (just not GPL), is what it |takes, then that's the way to go. IMHO of course. | |regards, | Rickard | |ps. Just to make it super-clear: These are the opinions of Rickard |Öberg, and are not necessarily representative of those of his employer. | |-- |Rickard Öberg | |Email: [EMAIL PROTECTED] |http://www.telkel.com |http://www.jboss.org |http://www.dreambean.com | | |
RE: [jBoss-Dev] Re: jboss on tomcat update
(EVERYONE: Please, PLEASE, leave the threats at the door. Honestly, raising the general level of antagonism is not getting us anywhere!) On Mon, 30 Oct 2000, marc fleury wrote: Aaron the bundling of APIs (JSP, EJB) that don't work together (JSP doesnt rely on EJB, and EJB doesnt rely on JSP) is PURE aggregation. It is useful for the beans. There is never CMD in the aggregate work. I am sorry but the line in the license is extremelly clear (yes specially 2b rickard). Marc, nothing in this entire discussion has convinced me that the GPL is "extremely clear" on anything - in fact, I find that quite the opposite to be true. No matter how many times you state "that is not true" or "the text is clear" it does not convince anyone else of anything. Perhaps you could substantiate your arguments slightly more? You seem to think that containment should be strictly interpreted as "a line of code from program X is placed in program Y". However, that is not clarified anywhere in the GPL. There is nothing in the wording of the license that leads me to believe that "containment" refers to "lines of source code" as opposed to "entire products". What leads you to this conclusion? And once again, the deciding factor is not what Marc Fleury thinks, or even what the jBoss Board thinks, it is what the users, observers, and lawyers think - what the "community" thinks. After all, nowhere in the license does it state that the composition of and/or opinions of the board will never change. Don't you find it just a little bit worrisome that no one who has spoken up from any of the Apache projects believes that jBoss can be legally integrated with Tomcat or Avalon? Even if every single one of them is wrong, don't you think this unanimous opposition from the groups we are trying to work with is going to cause problems with the adoption of the integrated work? Aaron In other words a J2EE server is pure "API together bundled" but I don't see the other API from my code, and I never have to add anything to anyone of them. All CMD work is GPL'ed (MBeans). Same mistake with JMX, it is VERY ignorant to claim linking - GPL. so GPL work does run on windows, because windows is not CMD work of GPL... this is getting tiring... JMX is not CMD work of jboss... marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder |Sent: Monday, October 30, 2000 6:49 AM |To: jBoss Developer |Subject: Re: [jBoss-Dev] Re: jboss on tomcat update | | |On Mon, 30 Oct 2000, Ole Husgaard wrote: | Before we go to such drastic steps as changing the license, | we should find out exactly what is the problem with the | license we have now. I've seen many flames and much hearsay, | and a lot of crying from both sides, but from facts and | valid arguments I have only been able to identify three | "problems": | | 1) jBoss cannot include the Tomcat code and distribute |the combination without breaking the APL license of |Tomcat. | 2) Tomcat cannot include the jBoss code and distribute |the combination without breaking the GPL license of |jBoss. | 3) Someone (forgot who) refuses to add the jBoss code |to their tree because they have a problem with the |GPL license. | | I think we need to add | | 4) It has been debated whether it is legal for jBoss to include | packages such as JMX which are neither GPL nor "safe" | operating system code | | In all three cases my opinion is "So what?". | | We're all entitled to an opinion. | | In the two first cases: These two programs can | easily be distributed seperately. | | I think the usefulness of a J2EE server is dramatically |higher than the usefulness of an EJB server. Thus I think it's |safe to say that it's a "good thing" to be able to integrate |jBoss and Tomcat. If you insist on keeping them separate, you |sacrifice performance (I don't think you could rationally claim |they're totally separate product when you distribute same-VM |integration code that deals with both directly - unless that's |yet another package), distribution (2 packages? How silly is |that?), and market (Let's see, I could have one integrated and |fully-tested product [Weblogic], or two completely separate |products that not even that authors believe can be safely run |together...) | | In the last case: Don't we already have our own | fine CVS tree? | | However, I say again that one of the fundamentals of open source |is that we should be able to share code. When someone puts together a |*really good* package Foo, everyone in the community who could benefit |from Foo should be able to use it and improve it. Isn't that what this is |all about? It does't make any sense to say "You are welcome to improve my |code, but you can't use it." I know that's not we *intend* to say, but |it's the effect of our license WRT projects
