-----Ursprungliche Nachricht----- Von: Berin Loritsch [mailto:[EMAIL PROTECTED] Gesendet: Montag, 2. Juni 2003 14:56 An: Avalon framework users Betreff: Re: AW: AW: EJB-Spec and Fortress
Geiger, Marco (FF) wrote: > Hi Berin, > > an Info : > the using of the Reflection-API in Fortress > isn?t generally denied. The EJB-Spec does only not allow to access > information > about security, but normal Reflection for Classes is therefore allowed. > (the classloading-mechanism is the bigger problem, and knock-down-criteria > for me) Ok, so the klass.newInstance() and method.invoke(...) _are_ allowed? How about Proxy or Byte Code generation? Proxy is part of the package REFLECTION. So using is not prohibited... ( EJB-Spec says : 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. ) ... and about ByteCode-Generation is said nothing in Spec. So, forbidden ?! (do not think so...) Fortress uses whatever classloader is given to it, or the Thread.currentThread().getContextClassLoader() if it is not explicitly given. The major problem I have run into is that there is no _real_ standard on what the ClassLoader allows. For instance IBM WebSphere (last I used it was 3.5) did not allow you to get resources from the classloader. .. is not a problem in WebSphere 4.0 .. we do this permanently in our project.. ( just have to be carefully with the classloader-settings in AppServer) However, in the future, we may try to gather the meta information from the classes themselves--which would definitely require a special classloader. ..This would be very nice :-) > Binding Fortress to JNDI does not solve the problem. > (that?s what I understand without any problems). > Because one thing that is missing the Spec is the > "fortress-lookup"-Method inside an EJB, although I > get the reference to fortress by JNDI. I was talking about either binding the components Fortress manages to JNDI or binding the ServiceManager to JNDI. Not Fortress itself. > > But, how would you bind the services to JNDI that an EJB can use it without > missing > the Spec ? > That seems not clear to me. > > Any hints to me ? You can get better information from the Cocoon team on this, because they are using ECM in J2EE environments, and have cross this bridge before. However, the basic idea is that you bind the ServiceManager to JNDI in the Servlet space where it can do all it needs to do, and access it from EJB space. .. right, but looking over the project says me, they?re using it in a servlet-container :-) You may have to use something other than the "java://" base lookup protocol because that is reserved for J2EE. Summary : ========= BUT, talked about the classloader-section with other develepers in our team, and they said to me, that the are using the classloading- mechanism at several other spots,too. So, I can use it, too. ( e.g. TopLink, an OR-Mapper, does it in the same way ! ) The using of Fortress/Avalon is possible inside an EJB only by breaking the law of the classloading-mechanism. As I mentioned : not a problem in WebSphere ! And we use Websphere in a Cluster, so it is really good tested out (without any problems). Furthermore, Berin and others, many thanks for supporting in this problem !!! ( hope I can give my experiences sometimes back to you... :-) ) And if you decide to develep a "Meta"-Classloader (quite difficult), please let me know. Thanks a lot ! Regards, Marco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
