• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Programming restrictions of Bean Provider

 
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
www.ejbcertificate.com

Identify correct programming restrictions that a Bean provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container. [Check all correct answers]

1. An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.
2. An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
3. An enterprise bean must not use the JMS API.
4. An enterprise bean must not use the java.util.zip package for reading and writing the standard ZIP.
5. An enterprise bean must not attempt to create a class loader.



I answered : 1 2 5
Correct answer is : 1 2 4 5

Where - in the specs - can I find more about answer 4 : "java.util.zip"?

[ August 01, 2004: Message edited by: Karin Paola Illuminate ]
[ August 01, 2004: Message edited by: Karin Paola Illuminate ]
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Karin Paola Illuminate:
www.ejbcertificate.com

Identify correct programming restrictions that a Bean provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container. [Check all correct answers]

1. An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.
2. An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
3. An enterprise bean must not use the JMS API.
4. An enterprise bean must not use the java.util.zip package for reading and writing the standard ZIP.
5. An enterprise bean must not attempt to create a class loader.



I answered : 1 2 5
Correct answer is : 1 2 4 5

Where - in the specs - can I find more about answer 4 : "java.util.zip"?

[ August 01, 2004: Message edited by: Karin Paola Illuminate ]



You can definitely post a bug (the same I posted on the same question:




25.1.2 Programming Restrictions
This section describes the programming restrictions that a Bean Provider must follow to ensure that the
enterprise bean is portable and can be deployed in any compliant EJB 2.1 container. The restrictions
apply to the implementation of the business methods. Section 25.2, which describes the container�s
view of these restrictions, defines the programming environment that all EJB containers must provide.
� An enterprise bean must not use read/write static fields. Using read-only static fields is
allowed. Therefore, it is recommended that all static fields in the enterprise bean class be
declared as final.
This rule is required to ensure consistent runtime semantics because while some EJB containers may
use a single JVM to execute all enterprise bean�s instances, others may distribute the instances across
multiple JVMs.
� An enterprise bean must not use thread synchronization primitives to synchronize execution of
multiple instances.
This is for the same reason as above. Synchronization would not work if the EJB container distributed
enterprise bean�s instances across multiple JVMs.
[57] See [9] for restrictions.
Bean Provider�s Responsibilities Enterprise JavaBeans 2.1, Final Release Runtime Environment
563 11/12/03
Sun Microsystems, Inc.
� An enterprise bean must not use the AWT functionality to attempt to output information to a
display, or to input information from a keyboard.
Most servers do not allow direct interaction between an application program and a keyboard/display
attached to the server system.
� An enterprise bean must not use the java.io package to attempt to access files and directories
in the file system.
The file system APIs are not well-suited for business components to access data. Business components
should use a resource manager API, such as JDBC, to store data.
� An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or
use a socket for multicast.
The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not
allow it to be a network server. Allowing the instance to become a network server would conflict with
the basic function of the enterprise bean-- to serve the EJB clients.
� The enterprise bean must not attempt to query a class to obtain information about the declared
members that are not otherwise accessible to the enterprise bean because of the security rules
of the Java language. The enterprise bean must not attempt to use the Reflection API to access
information that the security rules of the Java programming language make unavailable.
Allowing the enterprise bean to access information about other classes and to access the classes in a
manner that is normally disallowed by the Java programming language could compromise security.
� The enterprise bean must not attempt to create a class loader; obtain the current class loader;
set the context class loader; set security manager; create a new security manager; stop the
JVM; or change the input, output, and error streams.
These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions
could compromise security and decrease the container�s ability to properly manage the runtime environment.
� The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or
the stream handler factory used by URL.
These networking functions are reserved for the EJB container. Allowing the enterprise bean to use
these functions could compromise security and decrease the container�s ability to properly manage the
runtime environment.
� The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
to start, stop, suspend, or resume a thread, or to change a thread�s priority or name. The enterprise
bean must not attempt to manage thread groups.
These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads
would decrease the container�s ability to properly manage the runtime environment.
� The enterprise bean must not attempt to directly read or write a file descriptor.
Runtime Environment Enterprise JavaBeans 2.1, Final Release Bean Provider�s Responsibilities
11/12/03 564
Sun Microsystems, Inc.
Allowing the enterprise bean to read and write file descriptors directly could compromise security.
� The enterprise bean must not attempt to obtain the security policy information for a particular
code source.
Allowing the enterprise bean to access the security policy information would create a security hole.
� The enterprise bean must not attempt to load a native library.
This function is reserved for the EJB container. Allowing the enterprise bean to load native code would
create a security hole.
� The enterprise bean must not attempt to gain access to packages and classes that the usual rules
of the Java programming language make unavailable to the enterprise bean.
This function is reserved for the EJB container. Allowing the enterprise bean to perform this function
would create a security hole.
� The enterprise bean must not attempt to define a class in a package.
This function is reserved for the EJB container. Allowing the enterprise bean to perform this function
would create a security hole.
� The enterprise bean must not attempt to access or modify the security configuration objects
(Policy, Security, Provider, Signer, and Identity).
These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions
could compromise security.
� The enterprise bean must not attempt to use the subclass and object substitution features of the
Java Serialization Protocol.
Allowing the enterprise bean to use these functions could compromise security.
� The enterprise bean must not attempt to pass this as an argument or method result. The
enterprise bean must pass the result of SessionContext.getEJBObject, Session-
Context.getEJBLocalObject, EntityContext.getEJBObject, or Entity-
Context.getEJBLocalObject instead.
To guarantee portability of the enterprise bean�s implementation across all compliant EJB 2.1 containers,
the Bean Provider should test the enterprise bean using a container with the security settings defined
in Table 23. The tables define the minimal functionality that a compliant EJB container must provide to
the enterprise bean instances at runtime.



Although the above quote is about EJB 2.1, I just downloaded the specification for EJB 2.0 (which is what we are supposed to study) and there is no mention of the java.util.zip package amongts programming restrinctions.

HTH,

Marco
[ August 01, 2004: Message edited by: Marco Tedone ]

 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can I make a suggestion ... check out the java.util.zip API doc and see which package is used for reading and writing.
 
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can definitely post a bug
I agree with Roger, this is not a bug... Look more carefully.
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Roger Chung-Wee:
Can I make a suggestion ... check out the java.util.zip API doc and see which package is used for reading and writing.


"An enterprise bean must not use the java.io package to attempt to access files and directories in the file system."
Here I think the spec emphasize on file system not the java.io package. For example, it's ok to use the java.net.Socket in EJB where definitely we can use the java.io.InputStream and java.io.OutputStream.
And java.util.zip API is based on java.io.In/OutputStream, so my understanding is it's Ok to use java.util.zip package in EJB.
Did I miss sth here? Please correct me.
 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i've also missed this question on their site. i've seen reference that even java.util.Date uses actual file io (java.io.*) on some operating systems to get a date.

this is definately an area where the spec itself is vague. it is basically telling the bd not to rely on the presence of a file system at all. me thinks that using java.util.zip if it can zip up perhaps a string/stringbuffer for inserting zipped data into the database would be fine according to the spec. a developer can't know all the api's in the jdk and the entire dependancy tree when using classes in their application (does java.util.Vector access the java.io package or not? and if it does, does that use attempt to acces files and directories on the file system?)

what if you have a .zip file packaged inside your ejb-jar file, can't you use getResourceAsStream() to read in the contents and then unzip the stream. note, i'm not familiar with the java.util.zip package to know what it can/can't handle.
 
reply
    Bookmark Topic Watch Topic
  • New Topic