I would like to migrate a multi-threaded application in JSE to Spring Integration but I have to clarify some points before. First of all, the application will have the following Spring integration components:
JMS to Transformer to router to TCPOut
TcpIn (to router) to Transformer to JMS
In this context, I have to load all the TCP connections dynamically from a configuration file. I saw a couple of example of this here in StackOverflow (based in the FTP sample). These samples could be enough for the first part but I am looking for how to do that in Spring Boot and what is the best (and elegant) way to create this type of configuration.
Finally, I have to access to each different context (this is maybe the most important) from a type of Swing monitor to start/stop manually this TCP connections. Is this possible? What do you suggest me to do?
All my current components are java based configuration (not DSL).
See my answers to this question and its follow-up for examples of how to dynamically create application contexts using Java Configuration.
Also, take a look at the new feature in the Java DSL for dynamically registering/removing integration flows with the context. The 1.2 version of the DSL, containing this feature, will be released shortly.
You can stop/start endpoints using JMX or a control bus, or programmatically.
I am learning Spring using this tutorial. I am unable to get my head around the following excerpt from it:
Spring enables developers to develop enterprise-class applications using POJOs. The benefit of using only POJOs is that you do not need an EJB container product such as an application server but you have the option of using only a robust servlet container such as Tomcat or some commercial product.
In the good old days when application servers only supported EJB 2 it was a nightmare to develop services using EJBs. Each service (e.g. a stateless session bean) required a bunch of interfaces and strange additional methods to work properly (home interface, remote interface, deployment descriptors etc).
In order to run EJBs you need an application server such as Jboss or Glassfish. In order to run servlets you simply need a servlet container such as Tomcat or Jetty which is way more lightweight than an application server.
Spring offers a way of creating simple services as plain POJOs (that can be exposed via servlets). Therefore, to be able to develop services as a POJO was simply a dream come true. Services did not need all the constraining dependencies to the EJB-interfaces and they could be deployed in a lightweight servlet container.
Then came EJB3 which greatly improved life for the Java EE developer. EJBs no longer needed the dependencies for home- and remote-interfaces (at least not via inheritence). A modern EJB 3 service is very similar to a POJO-based service. The main difference is that EJBs still require an application server to be deployed.
Spring Guru Rod Johnson released the book J2EE Development without EJBs which greatly explains how to replace your old J2EE components (such as EJBs) with more lightweight Spring Pojos - good reading!
Read below link which may help you understand meaning of benefit of using POJO :
http://www.javaexperience.com/difference-between-pojo-javabean-ejb/
Is it possible to inject a bean from a web application that deploy in another server!
I declare a scenario to myself, I have two web application that use spring framework and deploy separately in different application servers (one is TOMCAT and another one is WEBLOGIC),the first application has ServiceA and the second one has ServiceB, now I want to inject ServiceB in ServieA?
I try to do this with RMI once an another one with JMS, now I am wondering that:
Is it possible with another thing?
Is there any active project about this scenario exist?
How can share application context in spring framework, is it possible?
Thanks.
Bean is just an object in JVM. You certainly cannot use an object from one JVM in another JVM straightforward.
But you can do 2 things:
Use proxies - some objects that will have the same interface but invoke somehow to the proper server as implementation.
Use service-oriented architecture (SOA). Each server should have some limited set of beans that are responsible for their functionality. And all beans can interact with each other.
Maybe OSGI is suitable for this.
Web services, JAX-RS is the simplest. But JAX-WS provides you with the tools to automatically generate the client code.
I need some direction with JMX and Java EE.
I am aware (after few weeks of research) that the JMX specification is missing as far as deployment is concerned. There are few vendor specific implementations for what I am looking for but none are cross vendor. I would like to automate the deployment of MBeans and registration with the Server. I need the server to load and register my MBeand when the application is deployed and remove when the application is un-deployed.
I develop with:
NetBean 6.7.1, GlassFish 2.1, Java EE 5, EJB 3
More specific, I need a way to manage timer service runs. My application need to run different archiving agents and batch reporting. I was hoping the JMX will give me remote access to create and manage the timer services and enable the user to create his own schedule. If the JMX is auto registered on application deployment the user can immediately connect and manage the schedule.
On the other hand, how can an EJB connect/access an MBean?
Many thanks in advance.
Gadi.
I investigated JMX and EJB in Glassfish few years ago, so I don't remember all the details. But this might still help.
Glassfish-specific JMX. Glassfish has AMX and custom MBean can be deployed. AFAIK, such beans are meant to monitor the server itself, not to interact closely with a specific application. Such bean can be made persistent, and Glassfish will store their value somewhere across restart. Maybe have a look.
Registration and lookup. You can register MBean anytime from within an application using the MBeanPlatform, or MBeanServer. See this link, I don't remember exactly. You can also lookup other JMX bean and invoke operations on them. The names for the lookup are a bit crazy though. You can register the MBean when the app. starts from within a ServletContextListener.
Classloaders and deployment. The MBeans and the EJB instances are in distinct Classloader. I think you will need to place the .jar with the MBean implementation in the Glassfish deployment directory structure or add it the list of .jar in the classpath via the admin console. You can relatively easily manage to register a bean from within an EJB module, but a bean can not access a EJB easily, at least from my experience.
I managed to use plain JMX to expose statistics from my EJB application, and that worked relatively well. But I don't know if it's adequate to have something more interactive, as in your case where you want to have the EJB change their behavior depending the timer configured with JMX. I fear you will have troubles with this approach.
Hope it helps, despite the vagueness of what I remember.
On the Tomcat FAQ it says: "Tomcat is not an EJB server. Tomcat is not a full J2EE server."
But if I:
use Spring to supply an application context
annotate my entities with JPA
annotations (and use Hibernate as a
JPA provider)
configure C3P0 as a connection pooling data
source
annotate my service methods
with #Transactional (and use Atomikos
as JTA provider)
Use JAXB for marshalling and unmarshalling
and possibly add my own JNDI capability
then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?
What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?
EJBs are JavaEE components that conform to the javax.ejb API.
JavaEE is a collection of APIs, you don't need to use all of them.
Tomcat is a "partial" JavaEE server, in that it only implements some of the JavaEE APIs, such as Servlets and JNDI. It doesn't implement e.g. EJB and JMS, so it's not a full JavaEE implementation.
If you added some additional bits and pieces (e.g. OpenEJB, HornetQ), you'd add the missing parts, and you'd end up with a full JavaEE server. But out of the box, Tomcat isn't that, and doesn't try to be.
But if I add (...) then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?
No, you don't have a Java EE application server, a full-fledged Java EE application server is more than Tomcat + Spring + a standalone Transaction Manager. And even if you add a JMS provider and an EJB container, you still won't have a Java EE server. The glue between all parts is IMO important and is part of the added value of a Java EE container.
Regarding EJBs, the EJB specification is much more than JPA and specifices also Session Beans and Message Driven Beans (actually, I don't really consider JPA Entities as EJBs even if JPA is part of the EJB 3.0 specification in Java EE 5 for historical reasons - which is not true anymore in Java EE 6, JPA 2.0 and EJB 3.1 are separate specifications).
I should also mention that a Spring bean annotated with #Transactional is not equivalent to a Session Bean. A Java EE container can do more things with Session Beans (see below). You may not need them though but still, they are not strictly equivalent.
Last thing, Java EE containers implement a standard, the Spring container does not, it is proprietary.
What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?
As I said, I think that the "glue" is a part of the added value and highly contributes to the robustness of the whole. Then, ewernli's answer underlined very well what is difficult to achieve. I'd just add:
Clustering and Fail-over (to achieve fault-tolerance)
Administration facilities
Yes, a good Java EE server will do pretty neat things to improve fault tolerance (clustering of connection pools, JNDI tree, JMS destinations, automatic retry with idempotent beans, smart EJB clients, transaction recovery, migration of services, etc). For "mission critical" applications - the vast majority are not - this is important. And in such cases, libraries on top of the Servlet API are IMO not a replacement.
1) You're confusing JPA entities with EJBs. While JPA belongs to the EJB3 specification, it was always meant to be a standalone technology.
2) EJBs are: stateless beans, stateful beans and message driven beans. While each of these functionalities can easily be achieved using spring, spring just does not use this terminology. In Spring, you don't have POJO + "magic" as in EJBs, in Spring it's POJO + your own configuration (which sometimes feels like magic, too). The main difference is that spring does more and the application server does less, which is why a spring app is happy with a tomcat while an ejb3 app needs a 'real' application server.
In my opinion, 90% of applications can be deployed using spring + tomcat, ejb3 is rarely needed.
Indeed, if you put enough effort you can almost turn Tomcat/Spring into a full-fledged heavyweight application server :) You could even embed a portable EJB3 container...
What is it that a Java EE compliant app
server gives you that you can't
easily/readily get from Tomcat with
some 3rd party subsystems?
There are still a few features that are hard to get with 3rd party modules:
stateful session beans (SFSB)
extended persistence context
application client container / java web start
clustering depending on the app. server
CORBA interoperability
JCA integration ~
remoting ~
container-managed transactions ~
decent management of distributed transactions (e.g. recover heuristic tx)
Entries with ~ are also supported by Spring, but not so trivially, at least to my best knowledge.
A few more details in this answer: EJB vs Spring
Outside of the strict definition of what is and isn't an EJB, you're adding a lot of stuff to Tomcat. Even if what you have is an EJB server, it's not really plain Tomcat anymore.
The FAQ is correct: Tomcat is not an EJB server. However, it can be that or many other things if you pile on enough extra libraries and code.
An EJB implementation would be a bean written and packaged to run on any compliant EJB server. If you do what you describe, it may work, but it won't be portable to another vendor's application server.
So EJB is a standard that adheres to a specific specification and is therefore portable.
In practice many EJB's are not fully compliant or application server neutral. However, in the main they are, so the small incompatibilities would be much easier to fix if you changed application server vendors than attempting to move the architecture you described to a GlassFish, JBoss or Weblogic server.
EDIT: In response to your comment you would not have an EJB appropriately annotated and/or configured via XML in such a way that code that accessed it in EJB compliant ways would be able to use it without changes.
There are two angles to your comment. One is what functionality would you lose deploying on a JBoss or any of the others instead of Tomcat? Likely nothing, if you brought along all of the frameworks you relied on. However, if you wanted to move your code to Weblogic, for example, to use some of its features, then your code would need some likely significant changes to keep up.
I am not saying that you cannot replicate all EJB functionality (certainly the subset you care about) via other means, just that it is not the spec, and therefore not implementation independent.
then don't I effectively have a Java EE
application server? And then aren't my
beans EJB's? Or is there some other
defining characteristic?
Quick answer EJBs actually have to follow a Java EE specification. Tomcat is a Java EE container not an app server.
What is it that a Java EE compliant app
server gives you that you can't
easily/readily get from Tomcat with
some 3rd party subsystems?
Quick answer to your second question. In your case most likely nothing.
EJBs tend to be really heavy objects and people ended up using them to solve problems when they were essentially overkill. Frameworks like Spring were created to solve those problems without using EJBs. I think the first book where Spring was introduced was even called "J2EE development without EJB."