Let me see if I understand correctly:
In my web.xml I would put:
<web-app>
<servlet id="foo">
...
</servlet>
</web-app>
In my web containers proprietary descriptor file I would put:
<servlet id="foo">
<!-- extra non-standard servlet parameters -->
...
</servlet>
So when I deploy, the container will match up the extra description
information in my proprietary descriptor with the element in the web.xml
based on the id?
Thanks,
-Phil
Jules Gosnell <[EMAIL PROTECTED]>
Sent by: To: [EMAIL
PROTECTED]
[EMAIL PROTECTED] cc:
ceforge.net Subject: Re:
[JBoss-dev] Servlet Spec Question
05/28/03 05:53 AM
Please respond to
jboss-development
I've seen what I think was this at work in a WebSphere descriptor...
The idea is that you can unambigously identify any element in the
standard dd, by adding an 'ID="xxx"' attribute, then in your proprietary
dd you can add further information about that element and use the ID to
unify the two descriptions.
Some things in the standard dd already have unique names (servlets
etc..), some things may not and thus the vendor might need recourse to
this mechanism.
Jetty, AFAIK, does not make use of this,
Jules
[EMAIL PROTECTED] wrote:
>I am working on a deployment plugin for JBoss IDE and had a question about
>the servlet spec (I was reading 2.3). On pages 112-116 it describes an ID
>mechanism so that tools can provide additional deployment information. I
>don't really understand what it is talking about. Does anyone have an
>example of how these are used? Do Jetty and Tomcat have different
>non-standard depoyment information?
>
>Thanks,
>-Phil
>
>Here is a portion of the spec I was referencing. It is several pages so I
>have just reprinted the beginning:
>
><!--
>The ID mechanism is to allow tools that produce additional
deployment
>information (i.e., information beyond the standard deployment
>descriptor information) to store the non-standard information in a
>separate file, and easily refer from these tool-specific files to the
>information in the standard deployment descriptor.
>Tools are not allowed to add the non-standard information into the
>standard deployment descriptor.
>-->
>
><!ATTLIST auth-constraint id ID #IMPLIED>
><!ATTLIST auth-method id ID #IMPLIED>
><!ATTLIST context-param id ID #IMPLIED>
><!ATTLIST description id ID #IMPLIED>
>
>[snip]
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Jboss-development mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
