|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 85
Messages: 85
Messages: 85
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Does Spring violate JEE spec?
[Editor: This was originally posted in a TSS discussion forum. I'm moving it to the home page because I think it's an interesting issue for discussion.]
First of all: I'm not against Spring. I've used it for several projects and I think it is a great framework.
What I'd like to do is to start a discussion on some practical and also maybe more "academic" questions related to the combination Spring+JEE. These questions occured to me when I looked at the JEE specification for the first time. I always thought that would be boring ;-) but I found it pretty interesting. I already knew that you should not write directly to the filesystem. But what I did not know was that you must not use Class.forName() and similar methods in EJBs (EJB 3.0 Spec 21.1.2):
"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."
So here's the first violation: When I get a Spring Bean then this bean is instanciated dynamically with something like Class.forName(). Depending on the method I use this will implicitly or explicitly get a class loader. I think that it makes sense to not allow dynamic instanciation because the application server wants full control in order to optimize resource usage etc. What do you think? I'm really interested in other opinions. Maybe I got the spec wrong?
A second violation I found by using the AbstractStatelessSessionBean in J2EE applications. The spec says that a Stateless Session Bean is not allowed to be a subclass of anything. Well I agree: This might be very academic but still I somehow believe that there was a reason for that.
I'm also aware that I don't have to use Spring with JEE.
I'm also aware of some Spring Integration Modules for different application servers that might be a better solution than using Spring "directly" (by loading e.g. Spring Context in EJB). What is your experience with such AppServer/Spring integration modules? And do you think it solves the "problems" I mentioned above.
Regards
Oliver
|
|
|
Message #267447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does spring violate JEE spec?
Ah, TSS. My favorite blog aggregator. It's much more convenient that javablogs.com or, god forbid, manually scouring the intarweb for such silly questions. You know what else violates the JEE spec? ASP.net. I know, I know, they're completely separate technologies but ASP.Net has the gumption to completely ignore such things as JSP and JSF in favor of its own approaches. Shameful, really.
|
|
|
Message #267448
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Session Beans
The spec says that a Stateless Session Bean is not allowed to be a subclass of anything.
Just to clarify what the specs says:
The session bean class may have superclasses and/or superinterfaces ...... A session bean class must not have a superclass that is itself a session bean class.
Thanks,
-Mag
|
|
|
Message #267450
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Session Beans
The spec says that a Stateless Session Bean is not allowed to be a subclass of anything.
Just to clarify what the specs says:
The session bean class may have superclasses and/or superinterfaces ...... A session bean class must not have a superclass that is itself a session bean class.
Thanks,
-Mag
|
|
|
Message #267451
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EJB3 Session Beans
The spec says that a Stateless Session Bean is not allowed to be a subclass of anything.
Just to clarify what the specs says:
The session bean class may have superclasses and/or superinterfaces ...... A session bean class must not have a superclass that is itself a session bean class.
Thanks,
-Mag
Thanks for the clarification, but things are still a bit unclear. Could you repeat that for me? :P
|
|
|
Message #267452
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EJB3 Session Beans
Sorry for the repetition, it was the TSS that was misbehaving ad forced me to re-post it more than once.
|
|
|
Message #267453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does spring violate JEE spec?
To be more precise, Justin, it was in one of the TSS discussion forums. I've changed my ed note to better reflect that.
|
|
|
Message #267457
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does spring violate JEE spec?
You know what else violates the JEE spec? ASP.net. I know, I know, they're completely separate technologies but ASP.Net has the gumption to completely ignore such things as JSP and JSF in favor of its own approaches. Shameful, really.
Are people running ASP.Net on JEE application servers? If so that might be a problem.
That aside, I think it's pretty common to violate the JEE spec in JEE applications. The limitations in the spec are stifling. It would interesting to find out if using Spring on any given JEE app-server actually results in any real problems.
P.S. I attended a talk at JavaOne where a speaker warned against using Class.forName() because it had a bug or some sort of design issue. I can't remember if it was only a problem within the context of OSGi or in general. Does anyone happen to know anything about this?
|
|
|
Message #267458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does spring violate JEE spec?
Are people running ASP.Net on JEE application servers? If so that might be a problem.
I think it would be kind of a perverse accomplishment.
|
|
|
Message #267459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does spring violate JEE spec?
It was simply a joke to point out the silliness of pointing how unrelated technologies violate the tenets of other approaches. The whole question just seems mindnumbingly pointless.
|
|
|
Message #267461
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does spring violate JEE spec?
It was simply a joke to point out the silliness of pointing how unrelated technologies violate the tenets of other approaches. The whole question just seems mindnumbingly pointless.
Isn't the point that people are using Spring inside JEE containers? Am I wrong? If so, I'm completely confused by this sentence: "I'm also aware that I don't have to use Spring with JEE."
Of course there's no reason to follow the JEE spec outside of JEE containers. But if you are using Spring in a JEE container, why wouldn't the JEE spec be relevant to Spring in that context?
|
|
|
Message #267462
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does spring violate JEE spec?
Are people running ASP.Net on JEE application servers? If so that might be a problem.
http://www.theserverside.com/news/thread.tss?thread_id=50450
I was going to mention that too. I would imagine that you should, in theory, follow the spec even with something like that.
All the JEE stuff I ever worked with violated the spec and the sky never came crashing down. I suppose we might have hosed the server's ability to manage it's own resources or whatever but we did these things because the app-server was dog-slow to begin with.
|
|
|
Message #267463
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB, not Java EE
Spring does violate EJB programming restrictions. So does Hibernate, and probably any framework/library that tries to be useful (and are used from inside EJBs).
Many restrictions imposed by the EJB model are there for security reasons. Security agains... application developers! External 'hackers' (crackers?) won't be able to inject bytecode into the EJB container anyway (Java doesn't have buffer overflow issues C/C++ had). So, either you are in a company so big that you can't trust your own employees (how do you run a business like that?), or these restrictions are pretty useless.
There are restrictions that matter, of course. Synchronization, resource access, and thread creation restrictions, all may make your applications just stop working (mostly in distributed environments). But I don't think Spring, Hibernate or any of the mainstream-enterprise-class frameworks violate them.
|
|
|
Message #267464
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
In my opinion, no. While you correctly quote the EJB spec, nowhere in the J2EE spec is it mandated that you *have* to use EJB's. There's a book on my shelf that I bought in anticipation of working on a future Spring project called "J2EE(TM) Development without EJB(TM)" by Rod Johnson, the father of Spring, so that seems to be the major focus.
What you omitted from the EJB spec is the rationale for your restriction:
"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."
Since Spring is a container in its own right it's up to Spring to worry about these management issues.
Just my $0.02.
Thanks,
Thomas
|
|
|
Message #267466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
In my opinion, no. While you correctly quote the EJB spec, nowhere in the J2EE spec is it mandated that you *have* to use EJB's.
Assuming you are correct, this doesn't completely resolve the question. As I understand it the author had a specific use of Spring with EJBs that would appear to violate the spec. I think the focus on whether Spring as a whole is in violation of the JEE spec is obscuring the actual question at hand.
|
|
|
Message #267468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Class.forName()?
I don't understand the Class.forName() issue. How are these really different?
Class clazz = Class.forName("java.lang.Object");
Object o = clazz.newInstance();
---
Object o = new Object();
Surely they both use a classloader to load the bytecode?
Is there something I am missing?
|
|
|
Message #267471
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
I already knew that you should not write directly to the filesystem.
does that mean i should not use logging framework which writes to file .
|
|
|
Message #267472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Using Class.forName() - did you mean Class.newInstance?
P.S. I attended a talk at JavaOne where a speaker warned against using Class.forName() because it had a bug or some sort of design issue. I can't remember if it was only a problem within the context of OSGi or in general. Does anyone happen to know anything about this?
I Googled "class.forname bug" and looked around a little and didn't see outstanding bugs or issues. You may be thinking of the Class.newInstance() method, which creates a new instance of a class represented by a Class object by calling its default constructor. The problem with using the newInstance() method is that a class may not have an accessible default constructor, or it may not even exist. Josh Bloch describes more of its issues at the end of Item #2 of the second edition of "Effective Java"
Hope this helps. :-)
Cheers,
Jim
|
|
|
Message #267473
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
By using the Reflection API, you can access classes and members (attributes, methods) that wouldn't be accessible otherwise (private visibility, for example). This would be a security issue, according to the spec.
|
|
|
Message #267476
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
I don't understand the Class.forName() issue. How are these really different?
Class clazz = Class.forName("java.lang.Object");
Object o = clazz.newInstance();
---
Object o = new Object();
Surely they both use a classloader to load the bytecode?
Is there something I am missing?
I think the issue might be what classloader is used by Class.forName(String). Come to think of it, that might be the issue I mentioned above that I'm trying to recall.
I wonder if it's OK to use:
forName(String name, boolean initialize, ClassLoader loader)
With the appropriate classloader.
|
|
|
Message #267478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
By using the Reflection API, you can access classes and members (attributes, methods) that wouldn't be accessible otherwise (private visibility, for example). This would be a security issue, according to the spec.
You don't need to use Class.forName to do that. getClass() can be called on any Object.
|
|
|
Message #267477
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does spring violate JEE spec?
P.S. I attended a talk at JavaOne where a speaker warned against using Class.forName() because it had a bug or some sort of design issue. I can't remember if it was only a problem within the context of OSGi or in general. Does anyone happen to know anything about this?
Class.forName() may not work as you expected depending on the classloading architecture you use. In OSGi/EJB environments, containers create a somewhat complex classloader hierarchy, and not all classes are visible among modules. And this is not detailed specified by the spec. So, relying on some specific classloading strategy could hurt portability between containers.
|
|
|
Message #267479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
By using the Reflection API, you can access classes and members (attributes, methods) that wouldn't be accessible otherwise (private visibility, for example). This would be a security issue, according to the spec.
You don't need to use Class.forName to do that. getClass() can be called on any Object.
The Reflection API is not just Class.forName(). All classes from java.lang.reflect (Class, Method, Field, Array, etc.) are part of it. The restriction in the EJB spec is on the Reflection API, not just Class.forName().
|
|
|
Message #267480
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Using Class.forName() - did you mean Class.newInstance?
P.S. I attended a talk at JavaOne where a speaker warned against using Class.forName() because it had a bug or some sort of design issue. I can't remember if it was only a problem within the context of OSGi or in general. Does anyone happen to know anything about this?
I Googled "class.forname bug" and looked around a little and didn't see outstanding bugs or issues. You may be thinking of the Class.newInstance() method, which creates a new instance of a class represented by a Class object by calling its default constructor. The problem with using the newInstance() method is that a class may not have an accessible default constructor, or it may not even exist. Josh Bloch describes more of its issues at the end of Item #2 of the second edition of "Effective Java"
Hope this helps. :-)
Cheers,
Jim
I'm 100% sure it was about Class.forName() and now I am about 85% sure it was about classloaders. It was an OSGi talk and OSGi containers are heavily involved with classloaders. I think the point was about how to move to OSGi and his advice was to eliminate all calls to Class.forName(). I just can't remember what he suggested changing it to. Maybe it was:
this.getClass().getClassLoader().loadClass() or the other version of Class.forName() I mentioned above.
|
|
|
Message #267482
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
By using the Reflection API, you can access classes and members (attributes, methods) that wouldn't be accessible otherwise (private visibility, for example). This would be a security issue, according to the spec.
You don't need to use Class.forName to do that. getClass() can be called on any Object.
The Reflection API is not just Class.forName(). All classes from java.lang.reflect (Class, Method, Field, Array, etc.) are part of it. The restriction in the EJB spec is on the Reflection API, not just Class.forName().
Yeah but the spec just says don't call Class.forName() right? And Like I said, you can get a reference to a Class object without call Class.forName().
|
|
|
Message #267483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
Yeah but the spec just says don't call Class.forName() right? And Like I said, you can get a reference to a Class object without call Class.forName().
Or more correctly, it says basically not to mess with ClassLoaders.
|
|
|
Message #267484
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
Yeah but the spec just says don't call Class.forName() right? And Like I said, you can get a reference to a Class object without call Class.forName().
From the spec:
"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."
|
|
|
Message #267485
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
I wonder if it's OK to use:
forName(String name, boolean initialize, ClassLoader loader)
With the appropriate classloader.
I think I answered my own question and the answer is no.
|
|
|
Message #267486
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
As I understand it the author had a specific use of Spring with EJBs that would appear to violate the spec.
I'll try again, quoting RJ: "Spring also provides *support for implementing EJBs*, in the form of convenience superclasses for EJB implementation classses, which load a Spring lightweight container based on an environment variable specified in the ejb-jar.xml deployment descriptor."
So let's see what this violates:
create a class loader: no
obtain the current class loader: no, not the current classloader for the EJB at least
set the context class loader: no either
I don't think we're in violation.
Thanks,
Thomas
|
|
|
Message #267487
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
Oh, and there is no mention of Class.forName() in the text of the spec.
|
|
|
Message #267488
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
Yeah but the spec just says don't call Class.forName() right? And Like I said, you can get a reference to a Class object without call Class.forName().
From the spec:
"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."
That's all well and good but that's not the only reason the spec says not to use Class.forName() or similar features. Like you already pointed out yourself, there are two distinct issues at hand. Complex classloader implementations and security.
|
|
|
Message #267489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
obtain the current class loader: no, not the current classloader for the EJB at least
Class.forName() calls ClassLoader.getCallerClassLoader() which gets the current class loader, does it not?
|
|
|
Message #267492
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
obtain the current class loader: no, not the current classloader for the EJB at least
Class.forName() calls ClassLoader.getCallerClassLoader() which gets the current class loader, does it not?
We know that because we have the source code to Class.forName(). However, I haven't looked at what "new" does, but I have to imagine that it too gets the caller class loader to find the appropriate Class instance. I guess this was the point of my previous post - how can you possibly avoid using code that somewhere along the way (from the original post) "obtain[s] the current class loader"?
Anyway, my feeling is that using Class.forName(String) does not violate the EJB 3.0 spec, although using Class.forName(String, boolean, ClassLoader) could violate the spec depending upon which class loader you pass in. I base my reasoning on the italicized paragraph in the EJB spec:
"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."
I don't see that Class.forName(String) is any more dangerous for the container than "new".
|
|
|
Message #267491
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
obtain the current class loader: no, not the current classloader for the EJB at least
Class.forName() calls ClassLoader.getCallerClassLoader() which gets the current class loader, does it not?
I think this depends on how you deploy. It can be ok for Spring to get the current class loader, but not for the EJB directly, if the class loaders are different. When I have time I'll read this: http://www.objectsource.com/j2eechapters/Ch21-ClassLoaders_and_J2EE.htm, which seems to address the issue.
|
|
|
Message #267494
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
obtain the current class loader: no, not the current classloader for the EJB at least
Class.forName() calls ClassLoader.getCallerClassLoader() which gets the current class loader, does it not?
I think this depends on how you deploy. It can be ok for Spring to get the current class loader, but not for the EJB directly, if the class loaders are different. When I have time I'll read this: http://www.objectsource.com/j2eechapters/Ch21-ClassLoaders_and_J2EE.htm, which seems to address the issue.
Just to be clear, I'm not convinced that it's really a problem if using Spring to for EJB violates the JEE spec. These kinds of restrictions are a big part of what I dislike about JEE. If Spring or anyone else can violate them and get away with it, more power to them, I say.
|
|
|
Message #267496
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EJB, not Java EE
Synchronization, resource access, and thread creation restrictions, all may make your applications just stop working (mostly in distributed environments). But I don't think Spring, Hibernate or any of the mainstream-enterprise-class frameworks violate them.
To be specific: Quartz will not work properly when deployed on OC4J, so I suppose the Quartz based "Spring Scheduler" would run into the same issues. The problem is, that the Quartz worker threads are not managed by the J2EE container and the Oracle app server is using its own Thread subclass with an overridden implementation of getContextClassLoader to obtain the current class loader. So, if you initialize Quartz from a web application and make a local call to an EJB from a Quartz job, the app server does not try to switch the classloader, but executes (or tries to execute) the EJB method with the web app's classloader.
This behaviour is J2EE conform, as the servlet container must only allow JNDI lookups and invokation of EJBs from threads managed by the servlet container (SRV.9.11 in the 2.4 version of the servlet spec).
|
|
|
Message #267498
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
obtain the current class loader: no, not the current classloader for the EJB at least
Class.forName() calls ClassLoader.getCallerClassLoader() which gets the current class loader, does it not?
We know that because we have the source code to Class.forName(). However, I haven't looked at what "new" does, but I have to imagine that it too gets the caller class loader to find the appropriate Class instance. I guess this was the point of my previous post - how can you possibly avoid using code that somewhere along the way (from the original post) "obtain[s] the current class loader"?
Anyway, my feeling is that using Class.forName(String) does not violate the EJB 3.0 spec, although using Class.forName(String, boolean, ClassLoader) could violate the spec depending upon which class loader you pass in. I base my reasoning on the italicized paragraph in the EJB spec:
"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."
I don't see that Class.forName(String) is any more dangerous for the container than "new".
It's an interesting point you make and I don't have a authoritative answer either way.
But I think it's probably the case that the semantics of new and the semantics of Class.forName are not necessarily equivalent and that's the reason for the restriction.
|
|
|
Message #267499
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
Just to be clear, I'm not convinced that it's really a problem if using Spring to for EJB violates the JEE spec. These kinds of restrictions are a big part of what I dislike about JEE. If Spring or anyone else can violate them and get away with it, more power to them, I say.
As if Spring doesn't have a bunch of restrictions itself? The main difference IMHO is that the J2EE restrictions are documented (if the developers would bother to read the documentation and learn the tools they are working with), whereas the Spring restrictions is something you more or less randomly run into, and have to spend hours with the debugger to find out why something is not working as you expected. Mixing J2EE and Spring turned out in my last project not to be the "combination of all the advantages" but a pain in the ass, having to cope with two different sets of don'ts.
|
|
|
Message #267500
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
Class.forName() would use the thread's context classloader which would have been set by the container. If you set the context classloader yourself (provided your security manager allows this) to do something special and then forget it to reset it to the original context classloader on the thread then you might shoot yourself in the foot. The whole point of these restrictions is if you want to play with them you better know what you're doing and I'd expect the Spring guys to know what they're doing.
|
|
|
Message #267502
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
Class.forName() would use the thread's context classloader which would have been set by the container.
No, it would not, at least not if the implementation complies with the API docs. Class.forName(String) uses the current class' classloader, so if used from a non-static context, the following two statements are identical:
Class.forName(className);
Class.forName(className, true, getClass().getClassLoader());
According to "The Java Virtual Machine Specification", chapter 5.3, the Java VM should use the same behaviour when loading classes, so if I'm not missing something important, "Class.forName("A").newInstance()" and "new A()" should always be equivalent, also in a J2EE environment.
|
|
|
Message #267503
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
Just to be clear, I'm not convinced that it's really a problem if using Spring to for EJB violates the JEE spec. These kinds of restrictions are a big part of what I dislike about JEE. If Spring or anyone else can violate them and get away with it, more power to them, I say.
As if Spring doesn't have a bunch of restrictions itself?
Frankly, I wouldn't know. I've been meaning to evaluate Spring for a while but it just isn't a priority for me.
The main difference IMHO is that the J2EE restrictions are documented (if the developers would bother to read the documentation and learn the tools they are working with), whereas the Spring restrictions is something you more or less randomly run into, and have to spend hours with the debugger to find out why something is not working as you expected. Mixing J2EE and Spring turned out in my last project not to be the "combination of all the advantages" but a pain in the ass, having to cope with two different sets of don'ts.
A container should minimize the constraints on the developer, IMO. Some may be necessary but JEE's are too burdensome. Again, I don't have enough knowledge of Spring to say whether it has too many restrictions for my needs.
I absolutely agree that any restrictions should be well documented.
|
|
|
Message #267504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I don't know that I care.
Prior to Spring, to get pluggable component flexibility in my apps, I would frequently create a factory class that would dynamically load beans (using class.forName read from a properties file). Did that violate the spec - probably ... but flexibility (and refactorability) is more important to me than adherence to the spec.
Also comparing Spring to EJB is an apples to oranges comparison to some degree b/c Spring offers a good bit more than just an app context (e.g. MVC, and so many integration points w/ other technologies). I know EJB development has gotten a lot better but from an efficiency perspective, I doubt seriously they are easier than POJO based beans and they simply add a layer of complexity for the sake of scalability, which can be achieved by other less complex means.
... FWIW
:-)
|
|
|
Message #267506
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EJB, not Java EE
To be specific: Quartz will not work properly when deployed on OC4J, so I suppose the Quartz based "Spring Scheduler" would run into the same issues. The problem is, that the Quartz worker threads are not managed by the J2EE container and the Oracle app server is using its own Thread subclass with an overridden implementation of getContextClassLoader to obtain the current class loader. So, if you initialize Quartz from a web application and make a local call to an EJB from a Quartz job, the app server does not try to switch the classloader, but executes (or tries to execute) the EJB method with the web app's classloader.
This behaviour is J2EE conform, as the servlet container must only allow JNDI lookups and invokation of EJBs from threads managed by the servlet container (SRV.9.11 in the 2.4 version of the servlet spec).
I didn't mention Quartz because I thought that it wasn't usual to use it from EJBs. If it is, it would violate the EJB spec in a much more dangerous (unpredictable) way.
But yes, if you create Quartz in the web container, and call EJBs from there, it will work as expected, since they'll be acquired by JNDI lookups, just like it would, if called from a Servlet, Struts Action or external client.
|
|
|
Message #267507
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
That's all well and good but that's not the only reason the spec says not to use Class.forName() or similar features. Like you already pointed out yourself, there are two distinct issues at hand. Complex classloader implementations and security.
Yes, both are issues, but security is not a really valid one in most cases (UMHO), and classloader visibility is a consideration you have to make when developing/packaging your app, but not really an impediment, as messing with Threads is. But still a violation, of course.
|
|
|
Message #267508
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EJB, not Java EE
<blockquoteBut yes, if you create Quartz in the web container, and call EJBs from there, it will work as expected, since they'll be acquired by JNDI lookups, just like it would, if called from a Servlet, Struts Action or external client.>
As I tried to explain, it will not, or at least it does not have to. The servlet container does not have to support JNDI lookups or EJB invokations from threads not managed by the servlet container itself. OC4J must be started with a "-userThreads" argument to allow JNDI looups from non-managed threads, but the actual EJB invokation may still fail, depending on the classloader hierarchy of the deployed applications.
|
|
|
Message #267509
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Class.forName() caching
The problem with Class.forName() is that it has the side effect of caching the results. In some environments, the same classname may exist multiple times, such as in an OSGi environment.
This means that your second call to Class.forName could actually return a Class that is not visible to the classloader doing the call.
Instead, you should load classes using classloader.loadClass() .
|
|
|
Message #267510
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
I never said they'd be different - yes, Class.forName("A").newInstance() and new A() should be equivalent because, by default, the thread that calls them would use the same context classloader, unless you've mucked around with the thread's context classloader yourself. When your app is running in an app server env, the threads that get handed out of the pool would have their context classloaders set appropriately so that the container and the application code can load appropriate classes. You are treading the edge if you change that context classloader - not necessarily the wrong thing to do but you gotta know what you're doing.
|
|
|
Message #267511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
I never said they'd be different - yes, Class.forName("A").newInstance() and new A() should be equivalent because, by default, the thread that calls them would use the same context classloader, unless you've mucked around with the thread's context classloader yourself. When your app is running in an app server env, the threads that get handed out of the pool would have their context classloaders set appropriately so that the container and the application code can load appropriate classes. You are treading the edge if you change that context classloader - not necessarily the wrong thing to do but you gotta know what you're doing.
Isn't this at least part of the point of the restriction? In a app server environment you'd also need to know what the container is doing, right?
|
|
|
Message #267512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
I never said they'd be different - yes, Class.forName("A").newInstance() and new A() should be equivalent because, by default, the thread that calls them would use the same context classloader, unless you've mucked around with the thread's context classloader yourself.
But as I wrote, according to the API and VM specification, neither would use the threads context classloader. They are using the classloader used to previously load the class, from which the method/constructor is invoked.
|
|
|
Message #267513
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
They are using the classloader used to previously load the class, from which the method/constructor is invoked.
Unless I'm misunderstanding, that's completely different from what "new A()" does.
|
|
|
Message #267514
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName() caching
The problem with Class.forName() is that it has the side effect of caching the results. In some environments, the same classname may exist multiple times, such as in an OSGi environment.
This means that your second call to Class.forName could actually return a Class that is not visible to the classloader doing the call.
Instead, you should load classes using classloader.loadClass() .
Can you point me to something that I could read for a more in-depth understanding of this?
Thanks.
|
|
|
Message #267515
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
They are using the classloader used to previously load the class, from which the method/constructor is invoked.
Unless I'm misunderstanding, that's completely different from what "new A()" does.
What do you think "new A()" does and why? It is specified in "The Java Virtual Machine Specification", chapter 5.3. If a class or interface D references a class or interface C with the name N and N is is not an array, then:
"If D was defined by the bootstrap class loader, then the bootstrap class loader initiates loading of C (§5.3.1).
If D was defined by a user-defined class loader, then that same user-defined class loader initiates loading of C (§5.3.2)."
|
|
|
Message #267517
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
They are using the classloader used to previously load the class, from which the method/constructor is invoked.
Unless I'm misunderstanding, that's completely different from what "new A()" does.
What do you think "new A()" does and why?
new A() doesn't necessarily load from the same class loader that was previously used for that class. For example, if you have sibling classloaders where their parent doesn't provide the class or if you've turned off the inverted class loading in one of your web apps. I know this because I've spent many an hour dealing with issues in app servers resulting from this behavior.
It's possible I might just be misunderstanding what you wrote or that you glossed over the details.
|
|
|
Message #267520
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
new A() doesn't necessarily load from the same class loader that was previously used for that class.
Depending on what you mean with "that" class, it does, if your VM complies to the specification.
But I can always try to explain it even more detailed. Let's assume we have something like this:
public class A {
public A() {
new B();
}
}
As soon as you somehow load class A (you don't have to instantiate it), the VM will also load class B, since it is referred by class A. To load class B, the VM will ask the classloader which defines class A to also load class B. If class A is defined by a classloader with parents or siblings, depending on the implementation, A's classloader may of course ask its parents and/or siblings to resolve class B, so that B later is not necessarily defined by the same classload as A (using the meaning of "load" and "define" as explained in the VM spec).
Let's assume that I change the implementation of A to:
public class A {
public A() {
Class.forName("B");
}
}
Now, the VM is not trying to load class B, until I create an instance of A, but the Class.forName method should use exactly the same strategy as in the previous example to load class B.
If you still think I'm wrong, I would be very happy if you would point to a legitimate source for your claim.
|
|
|
Message #267521
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
If class A is defined by a classloader with parents or siblings, depending on the implementation, A's classloader may of course ask its parents and/or siblings to resolve class B, so that B later is not necessarily defined by the same classload as A
I'm not sure why you are involving two classes in this and classloaders don't (normally) load classes from siblings. They load classes from their parents in standard approach.
What I am really unsure of is whether you are claiming that once a class A is loaded anywhere in the JVM, new A() will always resolve to that same class.
|
|
|
Message #267523
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
Sorry, you're right - wrote too quickly without thinking. Class.forName() will always use the classloader that loaded the caller class which may or may not be the same as the calling thread's context classloader. So, if for some weird reason, you've gone from your EJB/servlet code to a class on the system classpath and then do a class.forName() to load a class in the jar/war it'd fail, unless you use the thread's ctx classloader to load that class.
|
|
|
Message #267524
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
What I am really unsure of is whether you are claiming that once a class A is loaded anywhere in the JVM, new A() will always resolve to that same class.
Is it really so difficult to understand what I'm writing? I must have written at least three times, that when the VM loads a class D, because it is referenced by a class C (e.g. with "new D()"), the VM uses the classloader, which defines C to load D. Isn't it then obvious, that if class B is defined by a different classloader than C and you try a "new D()" from B as well, that the D instance in B may be (but does not have to be) of a different type than the D instance in C?
If you e.g. deploy classes (A and D), (B and D) and (C and D) as three independent J2EE apps, none of the classes are provided by the app server through a parent classloader and the appserver complies to the J2EE classloader spec, you will see D defined by three different classloaders in A, B and C. If D is provided from the app server classloader, e.g. as part of a common library and not deployed as part of the J2EE apps, A, B and C will (most likely) see the same type of D. If you use Class.forName("D") from A, B and C to load D, you will see exactly the same behaviour.
|
|
|
Message #267525
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
What I am really unsure of is whether you are claiming that once a class A is loaded anywhere in the JVM, new A() will always resolve to that same class.
Is it really so difficult to understand what I'm writing? I must have written at least three times, that when the VM loads a class D, because it is referenced by a class C (e.g. with "new D()"), the VM uses the classloader, which defines C to load D. Isn't it then obvious, that if class B is defined by a different classloader than C and you try a "new D()" from B as well, that the D instance in B may be (but does not have to be) of a different type than the D instance in C?
I understand that but it wasn't clear to me from what you were writing that you did. It's hard to know when you talk about a class whether you mean the resolved definition in a classloader or the more general conceptual class.
Now that I understand exactly what you mean, we can have a more meaningful conversation. Please don't take it as on offense that I misunderstood you.
If you use Class.forName("D") from A, B and C to load D, you will see exactly the same behaviour.
I've been reading some stuff and I might have an idea how it might differ but I need to test it out. What you are saying makes sense to me but I'm reading things that suggest it works otherwise.
|
|
|
Message #267526
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EJB, not Java EE
As I tried to explain, it will not, or at least it does not have to. The servlet container does not have to support JNDI lookups or EJB invokations from threads not managed by the servlet container itself. OC4J must be started with a "-userThreads" argument to allow JNDI looups from non-managed threads, but the actual EJB invokation may still fail, depending on the classloader hierarchy of the deployed applications.
Oh, that's good to know, thanks :)
|
|
|
Message #267528
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Topic starter is confused
JEE spec is not EJB Spec. EJB Spec is one of the many specs for various technologies that make up JEE. Similarly, a JEE server runs various sub-containers for each of these technologies.
I believe the poster's question, hence a correction to the topic title, should be Does Spring violate the EJB Spec.
Yes you can argue, that violating the EJB spec is violating JEE spec, but not everyone that uses JEE uses EJB.
Btw, the specs for other technologies in JEE may be a bit more relaxed compared to the EJB spec for some stuff. In that case, if you are a person that is anal about spec violation, you might want to bootstrap such process that violate the EJB spec into the other containers within the JEE server and make that available.
Personally I really wouldnt bother.
|
|
|
Message #267529
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
I already knew that you should not write directly to the filesystem.
does that mean i should not use logging framework which writes to file .
Most enterprise Java applications should use log4j, a logging framework that writes to files.
Not only does log4j write to the file system it also creates threads to monitor the config file and to support the asynch loggers. This also violates the EJB spec.
There is no good way to do many of the things enterprise developers generally need to do inside of the EJB spec.
My reaction learning about EJB in 1999 was "How can EJB fulfil these promises?" Alot less than nine years later it was clear that EJB has failed to deliver on the promises made for it and that it should be avoided in general.
EJB is a lesson to us all that others don't always know better.
|
|
|
Message #267530
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring violates JEE spec? or EJB spec? A Misleading Headline
In my opinion, no. While you correctly quote the EJB spec, nowhere in the J2EE spec is it mandated that you *have* to use EJB's.
Assuming you are correct, this doesn't completely resolve the question. As I understand it the author had a specific use of Spring with EJBs that would appear to violate the spec. I think the focus on whether Spring as a whole is in violation of the JEE spec is obscuring the actual question at hand.
Why "violate EJB spec" == "violate JEE spec"? Are we still debating "JEE == EJB"?
|
|
|
Message #267531
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Agree and disagree
I already knew that you should not write directly to the filesystem.
does that mean i should not use logging framework which writes to file .
Most enterprise Java applications should use log4j, a logging framework that writes to files.
Not only does log4j write to the file system it also creates threads to monitor the config file and to support the asynch loggers. This also violates the EJB spec.
There is no good way to do many of the things enterprise developers generally need to do inside of the EJB spec.
My reaction learning about EJB in 1999 was "How can EJB fulfil these promises?" Alot less than nine years later it was clear that EJB has failed to deliver on the promises made for it and that it should be avoided in general.
EJB is a lesson to us all that others don't always know better.
I've gotta agree and disagree. I agree on your conclusion that others don't always know better.
I'd disagree that there is no good way to do many of the things enterprise developers generally need to do inside of the EJB spec. To some extent.
First off, as I said in the post above yours, JEE is not only about EJB. If enterprise developers only limit themselves to EJB, then they are not enterprise developers, they are EJB developers and will not get far. The other components/system/tomato/tomaeto within JEE has different restrictions, some more relaxed and if you feel the need to be 100% compliant, which I personally wouldnt bother, you can do it outside of the EJB container, thus not violating the spec.
In your example of log4j. A lot of enterprise level apps use asynchronous logging where they dont write to file sychronously, the log message gets dispatched to a jms queue via an asycn log4j appender. If you are really strict on compliance you can then have a standalone jms client java app reading from the queue and writing to log files outside of the JEE container. You can also disable the monitoring thread for config changes, in Prod we wouldnt change stuff dynamically anyway, well at least for me.
The point is, there are many valid ways to do things without violating the spec. Just because you havent found one, does not mean it cannot be done. Dont fall into the boolean thinking mental pit of can/yes and cannot/no when there is also the other possibility of you dont know.
And enterprise/JEE is not EJB, EJB is merely a subset, its restrictions should not mean the same applies to JEE as a whole. And just because the EJB spec prohibits you to do something within the EJB container, does not mean you cannot externalize the work into other parts of the JEE container and feed the result back to your EJB.
|
|
|
Message #267532
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring violates JEE spec? or EJB spec? A Misleading Headline
In my opinion, no. While you correctly quote the EJB spec, nowhere in the J2EE spec is it mandated that you *have* to use EJB's.
Assuming you are correct, this doesn't completely resolve the question. As I understand it the author had a specific use of Spring with EJBs that would appear to violate the spec. I think the focus on whether Spring as a whole is in violation of the JEE spec is obscuring the actual question at hand.
Why "violate EJB spec" == "violate JEE spec"? Are we still debating "JEE == EJB"?
No. I was just pointing out that even though the terminology was imprecise or even incorrect, there was still a valid question to be discussed.
|
|
|
Message #267533
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
I already knew that you should not write directly to the filesystem.
does that mean i should not use logging framework which writes to file .
Most enterprise Java applications should use log4j, a logging framework that writes to files.
Not only does log4j write to the file system it also creates threads to monitor the config file and to support the asynch loggers. This also violates the EJB spec.
There is no good way to do many of the things enterprise developers generally need to do inside of the EJB spec.
My reaction learning about EJB in 1999 was "How can EJB fulfil these promises?" Alot less than nine years later it was clear that EJB has failed to deliver on the promises made for it and that it should be avoided in general.
EJB is a lesson to us all that others don't always know better.
I agree completely at a conceptual level but I would refine it a little. The thing that has always bothered me about EJB (and any number of other 'trust the vendor' tools) wasn't so much that they limit what you can do in certain contexts but that they don't provide a clean way to modify and extend that context so that you can solve your own problems. "others don't always know better" is a good way to say how I feel about this. I've been left high-and-dry by vendors too many times to feel comfortable placing all my eggs in their basket without any contingency plans that can be quickly implemented.
|
|
|
Message #267537
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
Wouldn't be more proper to say:
Does Spring rapes JEE spec?
|
|
|
Message #267539
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does Spring violate JEE spec?
But what I did not know was that you must not use Class.forName() and similar methods in EJBs (EJB 3.0 Spec 21.1.2):
"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."
The snippet below from "http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html" might help.
Why is there a restriction against using the Java Reflection APIs to obtain declared member information that the Java language security rules would not allow? Doesn't Java automatically enforce those rules?
Contrary to common belief, most of the Java Reflection API can be used from EJB components. For example, loadClass() and invoke() can both be used by enterprise beans. Only certain reflection methods are forbidden.
This restriction refers to the enabling of the security permission ReflectPermission. The suppressAccessChecks permission target name, when enabled, allows a class to use reflection to inspect, access, and modify protected and private members and methods in other classes. Obviously, if EJB components are using private or protected members or methods to manage sensitive information, this facility could be used to violate security mechanisms. Therefore, the EJB specification explicitly restricts usage of suppressAccessChecks, to prevent the security hole that would result. Denial of ReflectPermission is part of the standard security policy for an EJB container.
Why all the restrictions on creating class loaders and redirection of input, output, and error streams?
Class loading is allowed, but creating custom loaders is not, for security reasons. These restrictions exist because the EJB container has responsibility for class loading and I/O control. Allowing the EJB to perform these functions would interfere with proper operation of the Container, and are a security hazard.
The Java Pet Store has code that loads classes from inside an enterprise bean class using Class.forName(), in StateMachine.
|
|
|
Message #267540
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does Spring violate JEE spec?
The most complete lightweight container.
Spring scaled up for deployment in any environment (J2SE or J2EE).
|
|
|
Message #267541
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Evolution
I think rules are valuable until we don’t have to break them. After it we need new rules which are responsible to our needs. After a while new rules will be some old conventions. What is J2EE? It contains some tools which developed based on rules and conventions and not more. It is only a sign of evolution.
|
|
|
Message #267546
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wow! One night over and tons of useless messages!
As I read this post yesterday (without any comments) I asked myself I there would be some people having enough time to investigate - to write really useful and profounded answers. But all I found this morning is a boring and useless discussion about classloaders and what somebody could have heard about it in the context of OSGi... WOW!
|
|
|
Message #267548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName() caching
The problem with Class.forName() is that it has the side effect of caching the results. In some environments, the same classname may exist multiple times, such as in an OSGi environment.
This means that your second call to Class.forName could actually return a Class that is not visible to the classloader doing the call.
Instead, you should load classes using classloader.loadClass() .
Can you point me to something that I could read for a more in-depth understanding of this?
Thanks.
Sure. I found a nice article here: http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
|
|
|
Message #267550
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
nothing to see here, move along sir...
Geez this thread is pointless. We all know Spring is ok, and Spring AS is failure. Next please.
|
|
|
Message #267559
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wow! One night over and tons of useless messages!
As I read this post yesterday (without any comments) I asked myself I there would be some people having enough time to investigate - to write really useful and profounded answers. But all I found this morning is a boring and useless discussion about classloaders and what somebody could have heard about it in the context of OSGi... WOW!
Does it occur to you at all that it's really stupid to post things like this?
Is this really all you have to contribute? And, you almost seem proud of this uselessness.
|
|
|
Message #267560
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName() caching
The problem with Class.forName() is that it has the side effect of caching the results. In some environments, the same classname may exist multiple times, such as in an OSGi environment.
This means that your second call to Class.forName could actually return a Class that is not visible to the classloader doing the call.
Instead, you should load classes using classloader.loadClass() .
Can you point me to something that I could read for a more in-depth understanding of this?
Thanks.
Sure. I found a nice article here: http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
I guess the remaining question here is whether this caching behavior of Class.forName() is consistent with new or not.
|
|
|
Message #267579
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No. Should be "Does Spring rape EJB spec?
Wouldn't be more proper to say:
Does Spring rapes JEE spec?
No. Should be "Does Spring rape EJB spec?
|
|
|
Message #267581
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No. Should be "Does Spring rape EJB spec?
Wouldn't be more proper to say:
Does Spring rapes JEE spec?
No. Should be "Does Spring rape EJB spec?
Better yet, "Does Spring rape the EJB spec"?
|
|
|
Message #267664
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EJB3 Session Beans
The spec says that a Stateless Session Bean is not allowed to be a subclass of anything.
Just to clarify what the specs says:
The session bean class may have superclasses and/or superinterfaces ...... A session bean class must not have a superclass that is itself a session bean class.
Thanks,
-Mag
Thanks for the clarification, but things are still a bit unclear. Could you repeat that for me? :P
So you have a Session Bean- BeanA (BeanAHome BeanARemote, BeanAImpl)
If yo were to write another Bean- BeanB(BeanBHome, BeanBRemote, BeanBImpl) If BeanBImpl extends BeanAImpl- you will be guilty of voilating the specs and Sun microsystems will drag you to court :)
|
|
|
Message #267675
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Agree and disagree
In your example of log4j. A lot of enterprise level apps use asynchronous logging where they dont write to file sychronously, the log message gets dispatched to a jms queue via an asycn log4j appender. If you are really strict on compliance you can then have a standalone jms client java app reading from the queue and writing to log files outside of the JEE container.
You can do that, but it's not what I would suggest if you asked me how to do asynchronous logging from an EJB.
You can also disable the monitoring thread for config changes, in Prod we wouldnt change stuff dynamically anyway, well at least for me.
The point is, there are many valid ways to do things without violating the spec. Just because you havent found one, does not mean it cannot be done.
There are creative ways to deal with the limitations of EJB. Some of them might even be good. Finding them is not the best use of time.
|
|
|
Message #267676
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
I agree completely at a conceptual level but I would refine it a little. The thing that has always bothered me about EJB (and any number of other 'trust the vendor' tools) wasn't so much that they limit what you can do in certain contexts but that they don't provide a clean way to modify and extend that context so that you can solve your own problems. "others don't always know better" is a good way to say how I feel about this. I've been left high-and-dry by vendors too many times to feel comfortable placing all my eggs in their basket without any contingency plans that can be quickly implemented.
Repeating two perspectives on this I have heard lately, one, that the divide between the framework/DSL (Domain Specific Language) provider and the user is bug not a feature, two, that components/libraries are much easier to design and evolve than frameworks/DSL's.
|
|
|
Message #267822
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does Spring violate JEE spec?
Repeating two perspectives on this I have heard lately, one, that the divide between the framework/DSL (Domain Specific Language) provider and the user is bug not a feature, two, that components/libraries are much easier to design and evolve than frameworks/DSL's.
I actually think that frameworks and DSL have an important role to play in modern development. The problem begins when the framework or DSL provider makes the decides that all problems that cannot be solved within the framework will be solved by the provider only. My problem with EJB is not that it's a framework but that it lacks powerful mechanisms for extension. A constrained approach can be useful as long as it's not the only approach available. The time lost trying to solve problems with inadequate tools more than eliminates the time saved with such frameworks in my experience.
|
|
|
Message #267840
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring jobs claims
Wow, big transition from the claims on TSS to a full-fledged press release:
http://www.springsource.com/node/521
Rod, you have my friend Solomon Duskis to thank for that release, and yet, i still don't understand why you continue the general banter about "over-taking" and "legacy" EJB...
It is defensive posturing and is not reflected in the customers you are trying to work within, you will not start a revolution and get everyone to ditch app servers, you just need to integrate with them...
I am all for Spring, and I give SpringSource props for the past year, but this is a staid analysis of momentum and actual implementations,
surely, you guys can do better than that...
|
|
|
Message #267843
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Class.forName()?
Just look at the code. Class.forName(String) delegates to Class.forName(String, boolean, ClassLoader)
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
