logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: Using log4j with EJB
Date Thu, 21 Mar 2002 23:03:55 GMT

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:


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

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.
>  -----Original Message-----
>From:   Ceki Gülcü [mailto:ceki@qos.ch]
>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
> >"log4j.properties" ) methods.  We placed the directory holding the
> >properties file into the server's classpath, and it finds it no
> >
> >Yeah, I know, this violates the EJB spec, but hey, it works for us and
> >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
> >>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:
> >For additional commands, e-mail:
> >
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>


To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

View raw message