Indeed, reading the restriction as pertaining only private fields is entirely reasonable. Now, does reflection allow the access of private fields? I don't think so.
Furthermore, if you read two pages ahead in the EJB 2.0 spec, Table 19 explicitly states that the application server should deny java.lang.reflect.ReflectPermission to EJBs. Here is snip from the javadocs: ReflectPermission ================= The Permission class for reflective operations. A ReflectPermission is a named permission and has no actions. The only name currently defined is suppressAccessChecks, which allows suppressing the standard Java language access checks -- for public, default (package) access, protected, and private members -- performed by reflected objects at their point of use. The following table provides a summary description of what the permission allows, and discusses the risks of granting code the permission. What the Permission Allows: Ability to access fields and invoke methods in a class. Note that this includes not only public, but protected and private fields and methods as well. Risks of Allowing this Permission This is dangerous in that information (possibly confidential) and methods normally unavailable would be accessible to malicious code. Rereading the above more carefully, it seems that granting the ReflectPermission allows the user to access private fields. So your comments were entirely appropriate. I was misreading the spec. Thanks for the correction. At 17:38 21.03.2002 -0500, you wrote: >I'm not sure there is a restriction on using reflection in EJB. On page >495 of the EJB 2.0 spec, in section 24.1.2, Programming Restrictions: > >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. > >Maybe I'm reading too literally, but the restriction is on using >reflection to circumvent standard Java security. I don't think log4j >use of reflection is breaking this rule; e.g., you're not manipulating >private fields or calling private methods, are you? > >I'm also making use of reflection for some startup code (which populates >the JNDI tree based on configuration files and databases) and would be >quite dismayed if a container should choose to disallow it. > >Rich > > -----Original Message----- >From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, March 20, 2002 7:38 PM >To: Log4J Users List >Subject: Re: Using log4j with EJB > > >XYZConfigurator.configureAndWatch is known to work (in single server >mode) with WebSphere 4, Weblogic 6.1, Orion and JBoss. This particular >method call violates the EJB spec on three accounts. 1) It uses >reflection. 2) It accesses a file. 3) It spawns a thread. > >I find the restriction on reflection particularly unacceptable because >a lot of interesting stuff can only be done using reflection. In any >case, the section entitled "Programming Restrictions" has a lot of >impact on user code but it is particularly unclear. > > >At 17:56 20.03.2002 -0600, Bobby Nations wrote: > >Scot, > > > >We're using WebLogic 6.1 and having no trouble with the >configureAndWatch( > >"log4j.properties" ) methods. We placed the directory holding the > >properties file into the server's classpath, and it finds it no >problem. > > > >Yeah, I know, this violates the EJB spec, but hey, it works for us and >we > >have no plans of switching app servers any time soon. Of course, BEA > >could always take it away from us at some point, but we'll cross that > >bridge when we get to it. > > > >Your mileage may vary, > > > >Bobby > > > > > >Bellamy, Scot wrote: > > > >>In our environment we are using J2EE, including EJB. We would like to > >>employ Log4J as our logging utility for new projects. This isn't a > >>problem with the exception of EJB. We have identified a way to write > >>log messages utilizing JMS to send to a separate running process. > >>However, we haven't found a good way to utilize the Log4J >configuration > >>files in EJB, since EJB code cannot utilize the java.io package. Has > >>anyone discovered a way to accomplish this? > >> > >> > >>Thanks, > >> > >>Scot. > >> > >> > > > >-- > >Sr. Programmer / Analyst > >FedEx Services > >20 FedEx Parkway > >Collierville, TN 38017 > >(901) 263-6517 > > > > > > > > > >-- > >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > >-- >Ceki > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
