Re: [JBoss-dev] Servlet Spec Question

2003-05-29 Thread philipborlin

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.netSubject: 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


Re: [JBoss-dev] Servlet Spec Question

2003-05-29 Thread Brian Repko
Not so much for deployment, but for development tools.

If the user, through some tool, deletes the servlet in the
main dd, then that tool can delete information related to
that servlet in the app-server-specific dd.  Again, servlets
have names so this might not be the best example.
The id mechanism, IMHO, is used to establish relationships
that tools need to have to be user friendly and to offer
something like foreign key constraints in a database (if that
analogy makes sense).
Brian

Original Message Follows
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Servlet Spec Question
Date: Wed, 28 May 2003 09:25:46 -0600
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
_



---
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


Re: [JBoss-dev] Servlet Spec Question

2003-05-29 Thread Scott M Stark
The containers do not care about the ids. Some third party tool that is
generating an app server specific descriptor like jboss-web.xml could be
using the id as an index into the tool database when generating the
jboss-web.xml descriptor.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 8:25 AM
Subject: Re: [JBoss-dev] Servlet Spec Question


 
 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



---
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


Re: [JBoss-dev] Servlet Spec Question

2003-05-28 Thread Jules Gosnell
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


RE: [JBoss-dev] Servlet Spec Question

2003-05-28 Thread Rupp,Heiko
 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 

I think this is a good idea.
This makes it easier e.g. to apply filters to certain servlets
and not to others or to even reverse the filter order in 
servlet B from the one of servlet A .

 Heiko
-- 
Bancotec GmbH  EMail: [EMAIL PROTECTED]
Calwer Str. 33 Telefon: +49 711 222 992 900
D-70173 Stuttgart  Telefax: +49 711 222 992 999
Ein Unternehmen der Cellent AG http://www.cellent.de/


---
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