Mark,
(Sorry for the belated post- I only read this list in bulk every
couple of weeks..)
The introduction of ID attributes is welcome, and I understand how to
use them in a NAS specific DD. However...
On Fri, Aug 06, 1999 at 05:25:42PM -0700, MARK HAPNER wrote:
> You just produce a NAS specific DD which is added to the same directory
> in the jar as the standard DD.
Would the NAS specific DD need to be in the jar itself? Surely the
location of vendor-specific configuration is itself vendor-specific.
For example, configuration for application X may be held in LDAP, database, or
elsewhere. There may be many configurations for a single application
unit, depending not just on vendor, but on qualities of service, stage
of development, version, etc..
The jar/ear file could get pretty polluted with lots of
vendor-specific stuff. An alternative would be to keep the application
unit free from the details of the target operating environment, or
J2EE platform. IMO: Give the J2EE platform vendor the unique name of
the application unit, and let *it* decide where the extra
configuration details are to be found.
>
> This informal mechanism is all that's needed.
>
I'm not for or against your suggestion of placing information in the
jar or ear files, but would like the mechanism to stay "formally
informal" as in your remark.
Malcolm
PS. BTW, what does NAS stand for?
> -- Mark
>
>
>
> Milton Soong wrote:
> >
> > I am staring at the EJB1.1 Public draft 3, and on page 259 the spec mentioned that:
> >
> > "The ID mechanism is to allow tools that produce additional deployment information
>(i.e information beyond the stardard EJB deployment descriptor information) to store
>the non-standard
> > information in a separate file, and easily refer from these tools-specific files
>to the information in the standard deployment descriptor."
> >
> > Can someone give me more details on how this "...easily refer from these
>tools-specific files" is done? A quick look through a few XML books are all vague on
>this. The formal XML way to
> > refer to an unparsed entity (or a parsed entity for that matter if these tool
>specific files are also in XML format) requires more tags than just a simple ID.
> >
> > Milton Soong
> > Sun-Netscape Alliance
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
