Your question, or at least a good part of your question, is addressed by the J2EE
platform. The J2EE platform defines the concept of an .ear file (ear stands for
Enterprise
Application Archive) as the standard file format for delivery of an application that
consists
of multiple parts. An ear file can contain multiple ejb-jar files, web applications,
and
various "library" jar files that the ejb-jars may depend on. As far permissions are
concerned,
everything in the .ear file is considered as "application code" and is subject to the
permission
sets defined in the EJB and J2EE spec.
Vlada
----- Original Message -----
From: Eric Williams <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 06, 2000 3:24 PM
Subject: Clarification of bean restrictions for 3rd party software
> In researching an EJB server portability issue for a 3rd party tool we
> are using, I found the following nugget in the EJB-INTEREST archives:
>
>
> >Date: Sun, 19 Sep 1999 22:02:25 -0700
> >From: Vlada Matena <[EMAIL PROTECTED]>
> >Subject: Re: Clarification needed on Thread and non-final static
> > restrictionsfor EJB
> >
> >The restrictions apply to the classes that are delivered as part of the
> >enterprise bean code (i.e. to the classes in the ejb-jar file).
> >
> >The restrictions do not apply to the container implementation classes.
> >The JDK classes are considered to be part of the container.
> >
> >Vlada
>
>
> This response leaves some issues ambiguous:
>
> 1. It does not specify whether 3rd party software, not delivered as
> part of the ejb-jar file, must follow the EJB programming
> restrictions.
>
> 2. It does not specify whether EJB containers must be able to load 3rd
> party software separately from the ejb-jar file. Some containers are
> executed in a vanilla JVM, and you can put anything you want in the
> CLASSPATH. But some containers use highly-specialized JVMs and may
> wish
> to prohibit 3rd party code from being loaded as if it were "system"
> code.
> Does the container have to support loading 3rd party software as if
> it
> were "part of the container"? Section 18.2 of EJB 1.1 documents the
> required APIs, but does not answer the question of whether the
> container
> must be able to load other APIs from 3rd party vendors.
>
>
>
> I am looking at a 3rd party product that keeps a shared object cache in
> memory. The cache is read and updated by many beans concurrently.
>
> I am trying to find out whether this is "portable" or not. From my
> understanding of the EJB 1.1 specification, this is not guaranteed to be
> portable between EJB servers. The vendor thinks that it is portable
> because their code is not part of the bean. But I remain unconvinced
> that
> the EJB restrictions do not apply to their code as well.
>
> If anyone can provide clarification on this issue, it would be
> appreciated.
>
>
> Thanks,
>
> -eric
>
> ===========================================================================
> 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".
