|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 46
Messages: 46
Messages: 46
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Craig Walls: Message-Driven POJOs
Craig Walls, author of Spring in Action and XDoclet in Action, has written a blog entry showing how to use Message-Driven POJOs in Spring with ActiveMQ.Message-driven POJOs offer MDB-like functionality to simple JavaBeans. I have found message-driven POJOs to be a compelling alternative to MDBs, especially if you're already a big fan of Spring and are using it to develop your applications. Message-driven POJOs can take advantage of all of the features provided by Spring (such as dependency injection and AOP). One of the claims about using POJOs as MessageListeners is that they're "lighter than MDBs." This is clarified in a later section:- MDBs must be run within an EJB container. Depending on the architecture of your app, this may be an excessive requirement, especially if you aren't use any other EJBs and do not require the features of a full-blown EJB container. Message-driven POJOs, on the other hand, can run anywhere, even (as shown here) in a simple main() method. The only requirement is an ActiveMQ message queue.
- MDBs require that you implement the lifecycle methods of javax.ejb.MessageDrivenBean. Often these lifecycle methods aren't needed and are left as empty implementations. This isn't a real problem, except that it's simply unnecessary.
- Although it may not be apparent from the simple HelloBean example, message-driven POJOs can take full advantage of the dependency injection and AOP support offered by Spring (including Spring's support for declarative transactions and Acegi's support for declarative security). In short, you can do anything with the POJO that you can do with any other bean in a Spring context.
- The XML used to declare a message-driven POJO is slightly more verbose then for an MDB. You should, however, keep in mind that you'll only need to declare one JCAContainer bean, regardless of how many message-driven POJOs your application has.
What do you think of the idea? What about the requirement for a Java EE container? Is the replacement of a JEE container with a JMS container a worthwhile trade-off?
|
|
|
Message #178563
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig Walls: Message-Driven POJOs
I don't think lighter weight is the main problem for me, it's function.
What would be useful is if you could dynamically create these at runtime. Thats the main trouble with MDBs for me, they are static beasts. Applications need to be able to create new MDBs while they are running for a Destination that was unknown when the application was deployed. This pattern is used all the time by customers of WebSphere XD who are using the partition facility. When a partition is activated, the application typically creates one or more JMS destination listeners specific to the partition which has the effect of routing partition specific messages to the cluster member where the partition was activated.
The J2EE spec doesn't help here either with it's banning of certain JMS APIs required to do useful stuff in an application. We've worked around this in WebSphere when the application uses an async bean proxy for the MessageListener but still so at least you can use async message delivery albeit non transactionally.
The other question on efficiency is the threading model used to inject the messages in to the listener, this needs to be flexible/customizable also.
These would be my main gripes w.r.t. MDBs.
Billy (IBM)
http://www.billynewport.com
|
|
|
Message #178571
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig Walls: Message-Driven POJOs
I don't think lighter weight is the main problem for me, it's function.What would be useful is if you could dynamically create these at runtime. Thats the main trouble with MDBs for me, they are static beasts.
Agreed, the static nature of MDBs is painful.
FWIW with Message Driven POJOs, because its all just Spring and you can make as many BeanFactory / ApplicationContexts whenever you wish, in a hierarchy and you get completely dynamic message driven POJOs. So you could have a single parent context with the JCA container and resource adapters & thread pools configured; then create child contexts with different sents of dynamically created MDPs in them.
The other really nice thing is you get to use full dependency injection on the MDPs - which is a big win - as well as other goodies like interceptors etc.
Applications need to be able to create new MDBs while they are running for a Destination that was unknown when the application was deployed.
Agreed! Its surprisingly common to need to, say, query a registry or database to find all the topics you need to consume etc.
This pattern is used all the time by customers of WebSphere XD who are using the partition facility. When a partition is activated, the application typically creates one or more JMS destination listeners specific to the partition which has the effect of routing partition specific messages to the cluster member where the partition was activated.
Agreed. Though for partitioning, you can use 'exclusive queues' as TibCo calls them or 'message groups' as others call them, to basically create consumers on all destinations everywhere, then let the JMS provider perform the partitioning on your behalf (so some subscriptions are really inactive, until there are failures and things are repartitioned.
The J2EE spec doesn't help here either with it's banning of certain JMS APIs required to do useful stuff in an application. We've worked around this in WebSphere when the application uses an async bean proxy for the MessageListener but still so at least you can use async message delivery albeit non transactionally.The other question on efficiency is the threading model used to inject the messages in to the listener, this needs to be flexible/customizable also.These would be my main gripes w.r.t. MDBs. Billy (IBM)http://www.billynewport.com
I'm in complete agreement Billy. You might like Message Driven POJOs then :)
Here's hoping Java EE version 5 fixes this stuff and provides a standard - and dynamic - message driven POJO standard. Until then, message driven POJOs are very useful.
James
LogicBlaze
|
|
|
Message #178572
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig Walls: Message-Driven POJOs
Is the replacement of a JEE container with a JMS container a worthwhile trade-off?
BTW one minor nitpick. Its not a JMS container per se; its a JCA container (one piece of a JEE container) which just happens to be lightweight and embeddable inside any JVM be it J2SE, a servlet engine or a full blown JEE container.
Also there's no reason why other JEE servers can't support Message Driven POJOs too with dependency injection, interceptors and allow them to be dynamically deployed at runtime inside an application.
James
LogicBlaze
|
|
|
Message #178584
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tibco EMS server
Has anybody tried to use the POJO listening to tibco's ems server (E4JMS). How is the error recover in this approach i.e. what happens if the jms server goes down and comes back up. MDB seems to recover atleast with weblogic server we are using.
|
|
|
Message #178586
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tibco EMS server
Most application servers, WebSphere for sure, will attempt to periodically reconnect to a failed JMS connection factory using by MDBs. WebSphere by default tries to reconnect every 30 seconds.
Billy
|
|
|
Message #178588
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig Walls: Message-Driven POJOs
The tibco stuff goes some of the way towards whats possible with the partitioning facility in XD but it's no where near as flexible as whats possible with XD plus it's coupling the partitioning to a single destination which isn't typical also. Plus there are lifecycle events around a partition activating on a particular application server which are critical also.
Billy
|
|
|
Message #178590
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tibco EMS server
Has anybody tried to use the POJO listening to tibco's ems server (E4JMS). How is the error recover in this approach
Does TibCo EMS have a JCA Resource Adaptor? If so it should work.
i.e. what happens if the jms server goes down and comes back up. MDB seems to recover atleast with weblogic server we are using.
Handling auto-reconnection with the JMS server is normally an issue for the JMS client or JMS resource adapter rather than the JCA container per se.
e.g. if you use ActiveMQ with the reiiable:tcp://host:port transport then the JMS connections are automatically reconnected for you when using message driven POJOs - or when using regular JMS client applications as well.
James
LogicBlaze
|
|
|
Message #178594
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
I'd like to take this opportunity to compare Spring MDP do EJB3 MDB and also JBoss MEssage Driven POJOs
* MDBs must be run within an EJB container. Depending on the architecture of your app, this may be an excessive requirement, especially if you aren't use any other EJBs and do not require the features of a full-blown EJB container. Message-driven POJOs, on the other hand, can run anywhere, even (as shown here) in a simple main() method. The only requirement is an ActiveMQ message queue.
This will be remedied by JBoss EJB 3.0 implementation as we will be releasing an Embeddable version later this summer. We an embeddable EJB3 container working in CVS, but it is not fully featured yet. Ping our forum if you want to try it out and help us work on the API.
* MDBs require that you implement the lifecycle methods of javax.ejb.MessageDrivenBean. Often these lifecycle methods aren't needed and are left as empty implementations. This isn't a real problem, except that it's simply unnecessary.
Completely unneccessary in EJB 3.0. Actually, your example HelloBean class can be used *as is* in EJB 3.0 if you use an EJB 3.0 deployment descriptor.
* Although it may not be apparent from the simple HelloBean example, message-driven POJOs can take full advantage of the dependency injection and AOP support offered by Spring (including Spring's support for declarative transactions and Acegi's support for declarative security). In short, you can do anything with the POJO that you can do with any other bean in a Spring context.
The EJB 3.0 specification has dependency injection and support for interceptors.
If you want more fully-featured AOP, JBoss EJB 3.0 is built on top of JBoss AOP (a much richer AOP framework than Spring). JBoss EJB 3.0 is also integrated with our Microcontainer/Kernel. Later this summer, we'll be even offering Spring integration with our EJB3 implementation.
JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.
Bill
|
|
|
Message #178601
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
I'd like to take this opportunity to compare Spring MDP do EJB3 MDB and also JBoss MEssage Driven POJOs * MDBs must be run within an EJB container. Depending on the architecture of your app, this may be an excessive requirement, especially if you aren't use any other EJBs and do not require the features of a full-blown EJB container. Message-driven POJOs, on the other hand, can run anywhere, even (as shown here) in a simple main() method. The only requirement is an ActiveMQ message queue. This will be remedied by JBoss EJB 3.0 implementation as we will be releasing an Embeddable version later this summer. We an embeddable EJB3 container working in CVS, but it is not fully featured yet. Ping our forum if you want to try it out and help us work on the API. * MDBs require that you implement the lifecycle methods of javax.ejb.MessageDrivenBean. Often these lifecycle methods aren't needed and are left as empty implementations. This isn't a real problem, except that it's simply unnecessary. Completely unneccessary in EJB 3.0. Actually, your example HelloBean class can be used *as is* in EJB 3.0 if you use an EJB 3.0 deployment descriptor. * Although it may not be apparent from the simple HelloBean example, message-driven POJOs can take full advantage of the dependency injection and AOP support offered by Spring (including Spring's support for declarative transactions and Acegi's support for declarative security). In short, you can do anything with the POJO that you can do with any other bean in a Spring context. The EJB 3.0 specification has dependency injection and support for interceptors. If you want more fully-featured AOP, JBoss EJB 3.0 is built on top of JBoss AOP (a much richer AOP framework than Spring). JBoss EJB 3.0 is also integrated with our Microcontainer/Kernel. Later this summer, we'll be even offering Spring integration with our EJB3 implementation.JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.Bill
Here is a question. If I want richer AOP than Spring, why wouldn't I go with AspectJ/AspectWerkz? Neither are tied to JBoss. Also, from what I've heard(and it is still early) the dependency injection of EJB3 is not as full-featured as Spring.
So basically, if I want top-notch IOC and tons of third-party integration AND AOP go with Spring which can run in any app server. If I want better AOP, Spring integrates with AspectJ and you still get vendor independence and can run on something as small as tomcat?
Why JBoss?
|
|
|
Message #178605
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Here is a question. If I want richer AOP than Spring, why wouldn't I go with AspectJ/AspectWerkz? Neither are tied to JBoss. Also, from what I've heard(and it is still early) the dependency injection of EJB3 is not as full-featured as Spring.So basically, if I want top-notch IOC and tons of third-party integration AND AOP go with Spring which can run in any app server. If I want better AOP, Spring integrates with AspectJ and you still get vendor independence and can run on something as small as tomcat?Why JBoss?
It is a common misconception that JBoss AOP requires JBoss AS. JBoss AOP can run on any app server or standalone application or Tomcat. It has been able to do this for years.
Our EJB3 solution is scheduled to have an embeddable release that can run in JUnit, standalone apps, Tomcat standalone, or other vendor app servers. Much of it is already functional within CVS and we'll be releasing soon. I've already gotten trememdous feedback that this will be a popular option and predict other EJB3 vendors will follow with their own embeddable solutions or risk falling behind the competition.
I think you will find that EJB 3.0 has some nice persistence integration that Spring does not, not to mention it is *much* easier to deploy than Spring.
If you're so concerned about vendor lock-in, I think you'd be better off writing things like MDB's in EJB 3.0 and using Spring to compliment EJB 3.0. Remember, Spring is a vendor too and they want you to be as dependent as possible on them so that their services are more attractive. Interface21 can flame me all they want, but the fact remains, they are a business. Nothing wrong with that, but you should at least be aware of it.
Bill
|
|
|
Message #178608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
One more thing, like Spring, EJB3, JBoss AOP are technologies that glue together middleware services like ORM, TransactionManagement, messaging, security, servlet containers, etc... Spring/Interface21 are dependent on vendors and/or open source projects to provide these services. So, I don't think the argument is "Should I use Spring or JBoss?", but rather "Do I need to use Spring with JBoss?".
JBoss can pretty much stand on its own as a middleware stack. Spring and Interface21 cannot. This is not to say that Spring doesn't add value, they do, but this isn't a Spring vs. JBoss App server thing. Its a Spring vs. EJB3, Spring vs. JBoss AOP, Spring vs. JBoss Microcontainer. Not Spring vs. JBossMQ, Spring vs. JBoss TM, Spring vs. Tomcat., Spring vs. JCA, etc...
If you're using Hibernate + Spring, that's JBoss Inc. If you're using Tomcat, that's JBoss Inc as we fund development for both Apache Tomcat and ModJK.
Bill
|
|
|
Message #178611
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Here is a question. If I want richer AOP than Spring, why wouldn't I go with AspectJ/AspectWerkz? Neither are tied to JBoss. Also, from what I've heard(and it is still early) the dependency injection of EJB3 is not as full-featured as Spring.So basically, if I want top-notch IOC and tons of third-party integration AND AOP go with Spring which can run in any app server. If I want better AOP, Spring integrates with AspectJ and you still get vendor independence and can run on something as small as tomcat?Why JBoss? It is a common misconception that JBoss AOP requires JBoss AS. JBoss AOP can run on any app server or standalone application or Tomcat. It has been able to do this for years.Our EJB3 solution is scheduled to have an embeddable release that can run in JUnit, standalone apps, Tomcat standalone, or other vendor app servers. Much of it is already functional within CVS and we'll be releasing soon. I've already gotten trememdous feedback that this will be a popular option and predict other EJB3 vendors will follow with their own embeddable solutions or risk falling behind the competition.I think you will find that EJB 3.0 has some nice persistence integration that Spring does not, not to mention it is *much* easier to deploy than Spring.If you're so concerned about vendor lock-in, I think you'd be better off writing things like MDB's in EJB 3.0 and using Spring to compliment EJB 3.0. Remember, Spring is a vendor too and they want you to be as dependent as possible on them so that their services are more attractive. Interface21 can flame me all they want, but the fact remains, they are a business. Nothing wrong with that, but you should at least be aware of it. Bill
I'm aware that both JBoss and Interface21 offer professional services for their products. Of course, the difference is that I can run even Spring-integrated EJB code on any app server including JBoss. JBoss would be just JBoss. However, I am interested in how your EJB3 is "much easier" to deploy than Spring. I mean, Spring doesn't do persistence. It integrates wraps JDBC, integrates with Hiberate 2.x,3, Toplink, JDO, and IBatis. Does EJB3 do the same? What does EJB3 integrate with?
Also, I'm still asking WHY I would choose JBoss AOP over AspectJ. Assuming one can run JBoss AOP without the container, why tie myself to the JBoss version?
Now, my concern with vendor lock-in is in terms of the app server, not a specific library. After all, If, for example, my transactions can be configured via Spring and run on any or no app server at all, why be concerned with the app server? A standard is no guarantee. Look at entity beans. A disaster. Or in my case, we have to support JRun 4.0 of all things. I would say that Spring-integrated persistence would have been a better, easier, more portable choice than say JRun 4 EJB 2.0 entity beans(which we didn't use, BTW).
|
|
|
Message #178615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
One more thing, like Spring, EJB3, JBoss AOP are technologies that glue together middleware services like ORM, TransactionManagement, messaging, security, servlet containers, etc... Spring/Interface21 are dependent on vendors and/or open source projects to provide these services. So, I don't think the argument is "Should I use Spring or JBoss?", but rather "Do I need to use Spring with JBoss?". JBoss can pretty much stand on its own as a middleware stack. Spring and Interface21 cannot. This is not to say that Spring doesn't add value, they do, but this isn't a Spring vs. JBoss App server thing. Its a Spring vs. EJB3, Spring vs. JBoss AOP, Spring vs. JBoss Microcontainer. Not Spring vs. JBossMQ, Spring vs. JBoss TM, Spring vs. Tomcat., Spring vs. JCA, etc... If you're using Hibernate + Spring, that's JBoss Inc. If you're using Tomcat, that's JBoss Inc as we fund development for both Apache Tomcat and ModJK.Bill
Spring, wisely, in my opinion integrates with various products. If I use JBoss' transactions, persistence, etc, I'm stuck with JBoss. With Spring, I can use vendor A's transactions, Vendor B's persistence, Vendor C's security.
Many companies would have to fail for Spring's stack to fall, right? Or will you say that only Spring would have to fall, in which case, only JBoss would have to fall?
What arguement can be presented about a Spring tie-in that cannot be used as a JBoss tie-in? Standards? Well, as we all know, all standards don't succeed. Heck, EJB3 isn't even finalized.
Regardless, I'll bite. Why should I write to JBoss instead of Spring, when the Spring stuff is so much more portable? Why should I select JBossAOP instead Spring/AspectJ?
So I
|
|
|
Message #178617
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Bill
JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath. Ignoring the blatant product plug, this shows a rather peculiar idea of what a POJO is. Since when were interfaces bad? javax.jms.MessageListener is a JMS interface, and nothing to do with Spring--it's perfectly reasonable that message listeners should implement it. And, of course, implementing it does not tie user code to Spring. I point this out (obvious as it is) to clear up the FUD elsewhere in this thread about the Spring team wanting code to depend on Spring APIs. In fact, we make a big point about the fact that Spring is designed to minimize the amount user code depends on its APIs.
Obviously it's trivial to create an abstraction that hides the MessageListener interface and invokes a method--we've considered it and will probably do so at some point--but it really doesn't add a huge amount of value in most cases. A relatively simple routing class could do this, and then work behind any MessageListener, and be portable between messaging solutions.
Rgds
Rod
|
|
|
Message #178622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
One more thing, like Spring, EJB3, JBoss AOP are technologies that glue together middleware services like ORM, TransactionManagement, messaging, security, servlet containers, etc... Spring/Interface21 are dependent on vendors and/or open source projects to provide these services. So, I don't think the argument is "Should I use Spring or JBoss?", but rather "Do I need to use Spring with JBoss?". JBoss can pretty much stand on its own as a middleware stack. Spring and Interface21 cannot. This is not to say that Spring doesn't add value, they do, but this isn't a Spring vs. JBoss App server thing. Its a Spring vs. EJB3, Spring vs. JBoss AOP, Spring vs. JBoss Microcontainer. Not Spring vs. JBossMQ, Spring vs. JBoss TM, Spring vs. Tomcat., Spring vs. JCA, etc... If you're using Hibernate + Spring, that's JBoss Inc. If you're using Tomcat, that's JBoss Inc as we fund development for both Apache Tomcat and ModJK.Bill Spring, wisely, in my opinion integrates with various products. If I use JBoss' transactions, persistence, etc, I'm stuck with JBoss. With Spring, I can use vendor A's transactions, Vendor B's persistence, Vendor C's security.
And you can do the same with JBoss. You can plug in Vendor A's transactions (Arjuna), message (any JCA compliant vendor), persistence (EJB3 is pluggable persistence and we have deployers for Hibernate), Security (through JAAS). Really, you can plug in *any* packaged component type by writing a JBoss Deployer. Even Spring Deployer could be (and is being) written.
Many companies would have to fail for Spring's stack to fall, right?
Same with JBoss as, unlike Spring, we're standards based as you point out.
Well, as we all know, all standards don't succeed. Heck, EJB3 isn't even finalized.
Another myth propagated by the likes of Interface21 and the Spring crowd. Even though Rod likes to give talks like "Why J2EE Projects Fail" (why? becuase you're not using Spring obviously!) and "J2EE without EJB" (so what do I use instead? Spring of course!), the fact remains that there are a huge amount of applications that have SUCCEEDED on top of EJB and J2EE.
The fact of the matter remains is that the Spring crowd prefers to push their own custom solutions based on their framework rather than working with standards bodies.
Why should I write to JBoss instead of Spring, when the Spring stuff is so much more portable?
So you're saying Spring has a persistence solution more portable than JBoss's? It's messaging solution? Transaction solution?
Or are we just talking about EJB3?
Why should I select JBossAOP instead Spring/AspectJ? So I Dynamic per-instance AOP, hot deployment that works without a special VM. Richer type expressions. Remotable proxying and integrated remote capabilities. When JBOSS MC is released, full dependency propagation (exists in CVS now). I'm not talking about DI, I'm talking about disallowing a service to start because the aspect that cross-cuts it hasn't been initialized yet. Currently being developed is the ability to disable/enable beans at runtime (like Windows service manager).
Bill
|
|
|
Message #178624
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
The EJB 3.0 specification has dependency injection and support for interceptors. If you want more fully-featured AOP, JBoss EJB 3.0 is built on top of JBoss AOP (a much richer AOP framework than Spring).
This is surely like Microsoft saying "if you want fully-featured GUI, we do it better than Java can". You're comparing your own AOP on JBoss to an open framework that works on any J2EE platform including JBoss, not to mantion several non J2EE platforms. I'll stick to the open framework, that way I can choose if I want EJB3 or something more efficient. I might even choose JBoss but at least I have a choice.
Unlike Spring MDP, there is no MessageListener interface you have to implement.
Oh great, you've saved an "implements MessageListener" and "onMessage()" method. We're not talking complex here.
You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.
Sounds OK, so can I run it on my WebLogic and WebFear servers?
-John-
|
|
|
Message #178625
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Even though Rod likes to give talks like "Why J2EE Projects Fail" (why? becuase you're not using Spring obviously!) Please, Bill, if you're going to try to make any points based on my presentations, actually listen to them, or get the slides, first. Otherwise readers might assume that it's your agenda that is coming out.
There was very little (if anything) about Spring in that presentation. Much of it is not even about technology at all.
|
|
|
Message #178626
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Rod
JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath. Ignoring the blatant product plug, this shows a rather peculiar idea of what a POJO is. Since when were interfaces bad? javax.jms.MessageListener is a JMS interface
By this definition, EJB 2.1 MDB is a POJO. It implements a tiny interface and has a little bit of XML to glue it the destination. Spring MDP is not very POJO because you're dealing with untype JMS specific message format and implementing a JMS specific interface, where JBoss MDPs are pure business interfaces.
, and nothing to do with Spring--it's perfectly reasonable that message listeners should implement it. And, of course, implementing it does not tie user code to Spring.
Yes, I think I already said that the same HelloBean class could be used in EJB3 land.
I point this out (obvious as it is) to clear up the FUD elsewhere in this thread about the Spring team wanting code to depend on Spring APIs. In fact, we make a big point about the fact that Spring is designed to minimize the amount user code depends on its APIs.
Then why the propagation and proliferation of all your template and helper classes? Also, just because something is a POJO doesn't mean its not dependendant on the framework. For example, Why on a Spring 1.2RC release thread months ago did you not recommend people move to Hibernate 3 because Spring 1.2 wasn't ready yet? Sounds like lock-in to me...
Obviously it's trivial to create an abstraction that hides the MessageListener interface and invokes a method
Same thing could be said about most of Spring technology(that it's trivial), but together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.
Bill
|
|
|
Message #178627
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
So you're saying Spring has a persistence solution more portable than JBoss's? It's messaging solution? Transaction solution? I'm puzzled as to where this over-reaction came from, and why the focus on "Spring vs JBoss". A thread based on this false premise is going to produce more heat than light, so a flame war seems pointless. There is no need to choose between the two products.
JBoss is an application server, and JBoss Group are trying to build other products around it. Spring is an application framework that runs on all application servers, and runs equally outside an application server. The majority of Interface clients--and, presumably the majority of Spring users overall, based on market share--are running Spring on application servers other than JBoss. Or on web containers. So while Spring runs happily on JBoss, Spring is not dependent on JBoss technology.
Spring and JBoss are not in the same space, and therefore not mutually exclusive products.
|
|
|
Message #178628
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
One more thing, like Spring, EJB3, JBoss AOP are technologies that glue together middleware services like ORM, TransactionManagement, messaging, security, servlet containers, etc... Spring/Interface21 are dependent on vendors and/or open source projects to provide these services. So, I don't think the argument is "Should I use Spring or JBoss?", but rather "Do I need to use Spring with JBoss?". JBoss can pretty much stand on its own as a middleware stack. Spring and Interface21 cannot. This is not to say that Spring doesn't add value, they do, but this isn't a Spring vs. JBoss App server thing. Its a Spring vs. EJB3, Spring vs. JBoss AOP, Spring vs. JBoss Microcontainer. Not Spring vs. JBossMQ, Spring vs. JBoss TM, Spring vs. Tomcat., Spring vs. JCA, etc... If you're using Hibernate + Spring, that's JBoss Inc. If you're using Tomcat, that's JBoss Inc as we fund development for both Apache Tomcat and ModJK.Bill Spring, wisely, in my opinion integrates with various products. If I use JBoss' transactions, persistence, etc, I'm stuck with JBoss. With Spring, I can use vendor A's transactions, Vendor B's persistence, Vendor C's security.
And you can do the same with JBoss. You can plug in Vendor A's transactions (Arjuna), message (any JCA compliant vendor), persistence (EJB3 is pluggable persistence and we have deployers for Hibernate), Security (through JAAS). Really, you can plug in *any* packaged component type by writing a JBoss Deployer. Even Spring Deployer could be (and is being) written.Many companies would have to fail for Spring's stack to fall, right? Same with JBoss as, unlike Spring, we're standards based as you point out.Well, as we all know, all standards don't succeed. Heck, EJB3 isn't even finalized. Another myth propagated by the likes of Interface21 and the Spring crowd. Even though Rod likes to give talks like "Why J2EE Projects Fail" (why? becuase you're not using Spring obviously!) and "J2EE without EJB" (so what do I use instead? Spring of course!), the fact remains that there are a huge amount of applications that have SUCCEEDED on top of EJB and J2EE.The fact of the matter remains is that the Spring crowd prefers to push their own custom solutions based on their framework rather than working with standards bodies.Why should I write to JBoss instead of Spring, when the Spring stuff is so much more portable? So you're saying Spring has a persistence solution more portable than JBoss's? It's messaging solution? Transaction solution?Or are we just talking about EJB3? Why should I select JBossAOP instead Spring/AspectJ? So I Dynamic per-instance AOP, hot deployment that works without a special VM. Richer type expressions. Remotable proxying and integrated remote capabilities. When JBOSS MC is released, full dependency propagation (exists in CVS now). I'm not talking about DI, I'm talking about disallowing a service to start because the aspect that cross-cuts it hasn't been initialized yet. Currently being developed is the ability to disable/enable beans at runtime (like Windows service manager). Bill
Okay. So first you say JBoss is good because it is standalone,(which ties you to JBoss), but then JBoss is good because it allows you to use other vendors tools? Which is it? Is it a virtue to be able to switch between third-party implementations or not?
Two, JBoss AOP, to my knowlege isn't a standard. Neither is JBoss Microcontainer. Neither is JBossMQ(I've never heard of that). So, you are not just standard's based, are you. Also, without bring Rod into this(I have done EJB work so I can draw my own conclusions about how well people like EJBs,especially given how even YOU mention that EJB3 copies Spring), what doesn't working with a standard body have to do with anything?
Hibernate didn't become a jewel in JBoss' crown because of any cooperation with a standards body, right? And it took the standards body years to come out with something to displace Struts(which still hasn't happened). So, considering the amount of seemingly non-standard code you've mentioned, how exactly can you tout being standards based when you list so much non-standard code?
What I'm saying about Spring persistence, is that Spring integrates with pretty much every major form of persistence available to Java. Does JBoss or EJB3? Can I use EJB3 to integrate with JDO or JDBC? I'm asking.
I've got to check on your AOP stuff. I wasn't aware that running AspectJ required any special VM support.
|
|
|
Message #178629
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill
What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)
|
|
|
Message #178630
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Then why the propagation and proliferation of all your template and helper classes? Users choose to use Spring APIs if they add value. For example, consider JDBC. You can choose to use raw JDBC, or another JDBC abstraction library, but the class library that Spring provides over JDBC adds a lot of value, and many users like it. There is simply no practicable solution in that space that has no API, and it's worth noting that we don't reinvent core JDBC concepts such as PreparedStatements and ResultSets, just make them easier to use.
Some parts of Spring are class libraries, some are not. Spring APIs are not normally necessary for the important areas of configuration management and transaction management, for example. You can configure much legacy code that was written without knowledge of Spring, and you can make many existing objects transactional. The example in this thread (since we may at least make some attempt to stay on topic) shows a dependence on the JMS API, rather than the Spring API.
You really do seem very worked up about Spring today...
|
|
|
Message #178631
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)
Good! I'm glad somebody picked up on my "Spring marketing machine" comment. It's annoying isn't it?
|
|
|
Message #178632
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)
Good! I'm glad somebody picked up on my "Spring marketing machine" comment. It's annoying isn't it?
????? I don't think there is any Spring marketing machine. TSS' main function is to talk about technology, so what the big deal. I use Spring. I also use Hibernate and Struts. Should I toss them out because some people write articles and talk about the things and oh, BTW, they are not standard?
Or should I trust that I am as capable of seeing through exaggeration as I am through unsubtle jabs at a perceived competitor? You don't see BEA knocking Spring? Or Oracle. They just stepped up and supported a popular piece of software that has saved many developers many thousands of man-hours.
|
|
|
Message #178637
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what is wrong with jboss employees?
jeebus, this guy bill burke is such an _sshole it's unbelieveable. i mean, you just see the topic posted on here and you know it's not long before he'll be around telling everyone what a piece of sh_t product xyz is and why jboss is so much better. it's amazing anyone uses their server with public relations like this.
|
|
|
Message #178640
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
David
Okay. So first you say JBoss is good because it is standalone,(which ties you to JBoss), but then JBoss is good because it allows you to use other vendors tools? Which is it? Is it a virtue to be able to switch between third-party implementations or not?
Which is it? The answer is both. We're aiming to do both. We've had a pluggable, integrated app server from day one, now we're aiming to offer our middleware stack in other environments.
Hibernate didn't become a jewel in JBoss' crown because of any cooperation with a standards body, right?
True, but we brought Hibernate to a standards body (EJB3).
Or should I trust that I am as capable of seeing through exaggeration as I am through unsubtle jabs at a perceived competitor?
Yes, I was exaggerating to prove a point.
Bill
|
|
|
Message #178643
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Rod wrote: You really do seem very worked up about Spring today...
Yeah, i don't know what happened...
|
|
|
Message #178646
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Rod wrote: You really do seem very worked up about Spring today...
Yeah, i don't know what happened...
Something in the koolaid? ;-)
Peace.
|
|
|
Message #178647
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig Walls: Message-Driven POJOs
Will a Spring MD POJO consume messages serially or can a pool of these objects service a queue/topic?
Of not, that is definitely one advantage of using MDB's over Spring's consumer template.
-Michael
|
|
|
Message #178648
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)
Good! I'm glad somebody picked up on my "Spring marketing machine" comment. It's annoying isn't it?
No, actually you are the annoying one. Congratulations, now I'm even less interested in trying JBOSS or EJB3 before you jumped into this thread. I don't know, maybe its just me but I get a little wary when new and untested technologies like EJB3 get hyped so much before they are even released. I remember when EJB 1.0 was going to be the be-all end-all solution too.
Seriously, tone down the evangalising man. At this point you and the JBOSS crowd are just annoying people. JBOSS could cure cancer and I wouldn't want to hear about it now.
|
|
|
Message #178654
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig Walls: Message-Driven POJOs
I think i have somewhat unique prospective here having run the product that was similar in certain sense to Spring. As much as I openly and frequently disagree with some technical decisions behind Spring, the idea behind Spring is sound and solid (and market penetration of it says it all).
But it is hard to imagine where people do take these ideas of comparing Jboss AS and Spring which obviously are completely different species with different goal, applications, etc. As Spring growths, however, I suspect there will be naturally more and more overlapping.
Out current client, for example, uses Jboss/Spring/iBatis mix. Jboss is used for Web and clustering, Spring is used for static configuration (potentially something else). It is a vanilla setup that can be found in thousands of projects.
Nikita.
GridGain Systems.
|
|
|
Message #178657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)
Good! I'm glad somebody picked up on my "Spring marketing machine" comment. It's annoying isn't it?
No, actually you are the annoying one.
I was trying to be subtle and it failed miserably. It is annoying to be called a "marketing machine" was my point. Especially when you deliver on your marketing vision. Is that too subtle again?
Seriously, tone down the evangalising man.
This *is* a discussion forum, not a pat-you-on-the-back forum. If Spring is such a Holy Icon to you where nobody can criticize it or offer alternatives, then you really have serious issues man.
I really see no difference, other than being a JBoss employee, in my postings compared to other more frequent lurkers on different threads.
Bill
|
|
|
Message #178663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Hibernate didn't become a jewel in JBoss' crown because of any cooperation with a standards body, right? True, but we brought Hibernate to a standards body (EJB3).
Hibernate is quickly becoming the underdog in JCP politics, and is no longer "the" EJB3 source.
|
|
|
Message #178681
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.Bill
Often in JMS/MOM applications you actually want to use the JMS API to see the various headers of the message (has it been redelivered, if so how many times, whats the reply to destination, its time to live, priority and so forth). So being dependent on a simple JMS interface MessageListener is not a big deal.
Though if you want to hide the JMS API and MessageListener interface, you can use Lingo which is a Spring remoting library for JMS which works great with Spring MDPs to hide the JMS API. Whats more, Lingo works great on the client side too - providing a clean, load balanced and clustered POJO based remoting solution using the performance and reliability of JMS. In addition Lingo can handle asynchronous one way method calls or asynchronous request/response queries as well as the regular synchronous request/response of remoting/RMI.
Its worth highlighting again that Spring MDBs work great today, in any JVM 1.4 or later, in any servlet engine or in any ap server 1.4 onwards. EJB 3.0 only really works in Java 5 onwards with Java EE 5.0. I don't know about you but few of our customers can move to Java 5 yet.
Incidentally Bill, its kinda funny you see being dependent on 1 well established JMS interface as being somehow bad; yet are happy to promote a solution which adds exactly the same kind of runtime dependency - but this time on a number of annotations which are defined in EJB 3.0, which is still early draft and only works on Java 5. Thats way more restrictive and risky than using a MessageListener :).
Remember if you're using JMS you are already dependent, in jar form at least, on the JMS API - so EJB 3.0 actually adds more dependencies - Java 5, an EJB 3.0 application server and the EJB 3.0 annotations plus the added risk of the specification still being an early draft.
James
LogicBlaze
|
|
|
Message #178683
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig Walls: Message-Driven POJOs
Will a Spring MD POJO consume messages serially or can a pool of these objects service a queue/topic?Of not, that is definitely one advantage of using MDB's over Spring's consumer template.-Michael
Yes it can process messages concurrently and using an embedded JCA container can pool JMS connections, sessions and threads - along with performing all of the local or XA transaction handling, retry and exception processing. So it has all of the features of MDBs - its just that
* its simple and embeddable in any JVM or servlet engine or app server
* it works just fine on Java 1.4
* you can use Spring for dependency injection and AOP in your message listeners
* if you wanna hide the JMS API you can use Lingo a Spring remoting implementation for JMS
* you can reuse Spring's ability to dynamically deploy contexts/factories to dynamically depoy MDPs at runtime - whereas EJB only supports static registration.
James
LogicBlaze
|
|
|
Message #178684
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
I am writing applications using both Spring and JBoss. They are both great, and I'm grateful that such excellent software is available at no charge.
I have no connection to either organisation, and no axe to grind.
However I can safely say that what I read from those involved in Spring increases my respect for them; what I read from those involved in JBoss does the opposite.
|
|
|
Message #178689
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interfaces considered harmful? Bah.
BillJBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath. Ignoring the blatant product plug, this shows a rather peculiar idea of what a POJO is. Since when were interfaces bad? javax.jms.MessageListener is a JMS interface, and nothing to do with Spring--it's perfectly reasonable that message listeners should implement it. And, of course, implementing it does not tie user code to Spring.
Amen. All this Spring bashing by JBoss guys has been unbelievably obnoxious for days, now, but it's clear that with this kind of arguments it is also being ridiculous. I imagine they are coming out with a pojolet and start claiming that servlets are heavyweight components because they have to implement service(ServletRequest, ServletResponse) in order to work ("all other application servers lock you into their proprietary extensions to the simple pojo without interfaces!")...
|
|
|
Message #178696
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interfaces considered harmful? Bah.
All this Spring bashing by JBoss guys has been unbelievably obnoxious for days, now...
i personally haven't read any bashing by the JBoss, Inc. folks around these parts, specifically twords the spring product. Bill even stated that the two products (spring and jboss) serve a different space.
imo, jboss continues to innovate their products and delivers that innovation to the consumers at a rate that far surpasses the competition. they had a small bypass to become j2ee certified, and continued to stay on top of the customer demands (simplified integrating of software into the container) the entire time.
|
|
|
Message #178716
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
DavidOkay. So first you say JBoss is good because it is standalone,(which ties you to JBoss), but then JBoss is good because it allows you to use other vendors tools? Which is it? Is it a virtue to be able to switch between third-party implementations or not? Which is it? The answer is both. We're aiming to do both. We've had a pluggable, integrated app server from day one, now we're aiming to offer our middleware stack in other environments.Hibernate didn't become a jewel in JBoss' crown because of any cooperation with a standards body, right? True, but we brought Hibernate to a standards body (EJB3).Or should I trust that I am as capable of seeing through exaggeration as I am through unsubtle jabs at a perceived competitor? Yes, I was exaggerating to prove a point.Bill
I guess Spring has a different opinion. Don't duplicate unless it adds value. I'm still not sure why I should use JBoss over Spring. You really haven't explained why tying myself to JBoss' versions of certain technology is more desirable than Spring nor have you really addressed the issue that a "standard" is not necessarily a slamdunk.
In addition, since Spring abstracts the very middleware stack you value and thus allows me to use it fairly seamlessly coupled with the fact that if I need such things(like JTA for example), I'll use an app server, I can still use Spring, but not necessarily JBoss. What would be better? Moving my Spring enabled JTA app from say Weblogic to SunOne or tying myself to JBoss and not being able to move as easily?
Now, you may have brought Hibernate to a standards body, but it didn't gain popularity from that move nor is Hibernate a standard. By your apparent feelings about non-standard technology both of us should drop Hibernate. Yet, JBoss purchased it because...I guess I'm not sure. It was not a standard. Where's the value?
As for your exaggeration, I'm didn't get your point.
|
|
|
Message #178718
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interfaces considered harmful? Bah.
All this Spring bashing by JBoss guys has been unbelievably obnoxious for days, now...
i personally haven't read any bashing by the JBoss, Inc. folks around these parts, specifically twords the spring product.
Try scrolling up ;-)
Bill has been totally paranoid about Spring (and Interface21) for months now, and hasn't missed an opportunity to be downright nasty about it. Combine that with his "all your base are belong to us" rhetoric, such as:
Bill: If you're using Hibernate + Spring, that's JBoss Inc.
It's just plain childish. It's deliberately false. It's purposefully insulting. It's also a shame, because it makes Jboss look completely unprofessional and it detracts from any good technical work occurring in Jboss.
imo, jboss continues to innovate their products
Exactly. So why the pointless attacks on Spring? Especially since Rod (& co.) has put lots of work into supporting the Jboss server, Hibernate, etc.
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
|
|
|
Message #178727
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
vs. EJB3 MDBs and JBoss Message Driven POJOs
Since we're all doing product plugs here... :-)
I've got a framework built on XWork and JMS which allows you to take JMS messages and map them to XWork actions so you can reuse your XWork actions across your web-app and your asynchronous backend code. The message dispatcher can be deployed as either an MDB or as just a plain MessageListener, so you can make the MDB vs. MDP decision a runtime deployment decision, rather than an architectural decision.
Ignoring the blatant product plug, this shows a rather peculiar idea of what a POJO is. Since when were interfaces bad? javax.jms.MessageListener is a JMS interface, and nothing to do with Spring--it's perfectly reasonable that message listeners should implement it. And, of course, implementing it does not tie user code to Spring. I point this out (obvious as it is) to clear up the FUD elsewhere in this thread about the Spring team wanting code to depend on Spring APIs. In fact, we make a big point about the fact that Spring is designed to minimize the amount user code depends on its APIs.Obviously it's trivial to create an abstraction that hides the MessageListener interface and invokes a method--we've considered it and will probably do so at some point--but it really doesn't add a huge amount of value in most cases. A relatively simple routing class could do this, and then work behind any MessageListener, and be portable between messaging solutions.RgdsRod
|
|
|
Message #178736
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ActiveMQ vs. JbossMQ
Has anyone compared the two ? Any links would be appreciated.
We're completely biased of course but here is one comparison.
But don't take our word for it - I suggest you try them both. Certainly try to benchmark them in your own environment to see how they perform.
James
LogicBlaze
|
|
|
Message #179724
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
incredible !!!
I just read thru all the comments and discussion.
I find that incredible.
I already was bluffed by the logemann blog incident and by the way the hibernate guys were almost barking answers (and yes beginners ask beginners questions) in their forum.
I guess it can't be only be professionnal...Rod ? Which JBoss staff member's wife did you stole ? wow !!! wow !!! it was only a joke...don't let Bill come after me.
I really enjoy Jboss AS, hibernate...but guys you really try hard to loose support of the community.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore 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.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
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)
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)
|
|
