Malcolm Sparks wrote:
>
> 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 vendor specific DD could be anywhere.
It would likely be typical for it to be in the same jar directory as the
standard DD for convenience in bundling it with the app and locating it
in the jar.
> 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".
