I'm running a web-server (Embedded Jetty) that hosts multiple WARs and also supports hot deployment of new\exisitng webapps (as described here).
I have a set of common beans which needs to be shared (same instance) between the different web-apps. Is it possible to use Spring to somehow handle this beans?
Found this excellent explanation, but it explain how to do it with EAR files, which is not an option on my side since as I mentioned we support hot deployment of new WARs, we don't want to redeploy all the web-apps when deploying one web-app.
Is it possible to use Spring to handle these beans? or do I need to create some kind of wrapper in my common-beans to behave as a singleton (all web-apps runs on the same JVM)
Related
Currently I am developing an application composed of basically three modules: 1 ejb and two web apps. Using ant I am exporting this as a single ear.
My client asked to run multiple instances of the same ear on the same server. I was able to change application names and context path so they do not clash, however there is a problem with EJBs. Apache Geronimo can't startup EBJs with the same name event if they live on different ear/jar, etç.
Is there any way to make the EJB deployment specific for each "installation", or isn't possible and therefore I need to strip EJBs Jar from the web apps enclosed on the EAR ?
I would appreciate any help/hint.
Regards,
Ivan Frias
If it will be enough to have the many copies of web applications with one EJB.
Then you can separate EJB module and web modules and then load one EJB and N copies of web applications in the application server.
But it may cause some errors because of one EJB for many web applications.
Otherwise you have to run three instances of the application server because you will not be able to use equal EJB even separated by different jars/packages.
When running two applications on the same container
I would like to avoid duplication of code, and separate application responsibility and maintenance to different teams so they can maintain and package independently.
apps will reside in tomcat with different version (team A is responsible to App 1 while Team B is responsible to App 2)
So I would like to know if such scenario is possible:
Two applications running on the same tomcat
They share the same db.
They need to use the same security system (filter on app1 save a token on the session) or spring security.
They will differ only on the context as:
http://url:8080/app1 and http://url:8080/app2
Both will register a spring mapping a:
#RequestMapping(value="/pathOnApp1/{id}")
#RequestMapping(value="/pathOnApp2/{id}")
Two applications running on the same tomcat
Yes. Deploy two web application archive (war) files.
They share the same db.
They need to use the same security system (filter on app1 save a token on the session) or spring security.
This is just configuration. You could use the same xml file, properties file or database setup to configure your two (or more) applications. You might use two repositories (one for configuration, one for development). You might use Apache Zookeeper.
I'm deploying a new Spring JMS application to Weblogic 11g. What is the accepted way to deploy a Spring application with no web components to Weblogic?
Historically the apps I've been working on have used a WAR to load the application context. This does not seem like an acceptable solution now since this new application does not have any web components. Wrapping the deployment in an EJB does not seem acceptable either since Spring is supposed to be a replacement to EJB. A RAR does not seem to fit either, since the new application is not supplying any resources to other applications.
What options do I have, what is the accepted deployment method here?
Actually RAR archive is used for resources.
Firstly you should create the components of JMS in WebLogic side (JMS server, JMS module, JMS connection factory, queue or topic) that your application may use. When this components are integrated all that you need to create the EAR archive and deploy it. EAR can be created without any EJB modules.
After several days of searching, trying and head-banging, I post this question to SO although it seems to be answered already.
Here is the scenario:
I have an EAR application containing (for the moment) one WAR and one EJB module. The EJB module uses JPA (persistence.xml) and some Stateless Session Beans are exposed via Web Services. The web services use Basic authentication with a jdbc realm. The web module uses form authentication with the same realm.
The requirement:
I need to be able to deploy this application either on different servers (dev/test/prod) or on the same server (or cluster) with different deployment descriptors. The deployment settings that need to be different in each application instance are:
The jta-data-source in persistence.xml
The realm-name in web.xml
The javax.faces.PROJECT_STAGE in web.xml
The webservice-endpoint\endpoint-address-uri and login-config\realm in glassfish-ejb-jar.xml
The context-root in application.xml (i could move it to web.xml if it made any difference, see below)
The realm in glassfish-application.xml
During my research, I managed the following:
I can override the javax.faces.PROJECT_STAGE using asadmin set-web-context-param
I can override all settings in glassfish-ejb-jar.xml using a deployment plan during asadmin deploy
The same applies for glassfish-application.xml
I can probably override context-root during asadmin deploy (I don't know how would this work with more than one web modules in the EAR)
So far so good. This leaves me with the following problems:
How can I easily modify the the realm-name in web.xml?
How can I easily modify the jta-data-source in persistence.xml?
By easily I mean during deployment or using something similar to a deployment plan jar. Maintaining multiple copies of ejb.jar or war just with a modified .xml file is not an option.
Just to be clear, the need is to have different databases (either in different stages of development or for different customers) using the same application. The application uses one persistence-unit but it needs to point to different databases (hence the jta-data-source). The realm is a jdbc realm (on the same database) that also needs to be different per application instance.
Any help or pointer would be greatly appreciated.
Have you thought about preparing templates for the deployment descriptors, and populating them with value from property file during build? If you are using ant, you can use the expandproperties filter.
You can do all those things with a deployment plan jar.
It looks like the content of the deployment plan jar is pushed into archive/directory tree of the application BEFORE any of the heavy lifting associated with deployment happens.
See
http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/deployment/javaee-core/src/main/java/org/glassfish/javaee/core/deployment/DolProvider.java
and
http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/Archivist.java
I want to build and deploy my first Java EE 6 multi-tier application, with web and business tiers running on separate physical servers on Glassfish 3.1.
I think I understand what's required from a theoretical hi-level view but am not clear on the specifics and small details.
My current plan as is follows:
Create a Maven Enterprise Application in NetBeans 7.
Expose Session Facade EJBs via remote interface.
Have JSF Backing Beans utilise Session Facade EJBs via JNDI lookup.
Deploy EJB JAR to one server and web WAR to the other.
I'd really appreciate some pointers on:
Application structure.
Correct JNDI lookup with separate servers. Is injection possible?
Building appropriate archives.
Deployment configuration to allow tiers to communicate.
Unless you know you will be serving many requests per second, or have very data and/or CPU-heavy business logic, then you should be perfectly fine starting out by deploying both tiers on the same application server. Starting out by deploying to a single Glassfish application server using local interfaces lets you skip a lot of complexity in the runtime environment.
This in turn will allow you to use the simplest form of #EJB-injection in the web tier to access the session facades in the business tier. Local intefaces are faster because the application server can pass references rather than RMI proxies between the tiers and it lets you skip the JNDI lookups. You can always change the annotation later on, or introduce remote interfaces if you later find other reasons to deploy the tiers on separate servers.
Glassfish supports clustering, so you might never have to explicitly separate the two tiers--it all depends on the actual usage patterns, so performance monitoring is key.
Deploying the web tier as a WAR and the business logic as an EJB jar is the right thing to do. Depending on the size and the logical structure of your application, you might want to break that down into to multiple modules.
Maven takes care of building the archives. Make sure you define a sub-project for each war and jar archive, plus a sub-project for assembling the EAR-file. The latter project will pull in the war and jar files produced by the other sub-projects. String all the projects together with a master maven project and voila, you have the flexibility to build each component separately, build the entire thing, or any combination in-between.
You have chosen a hard path, as others have pointed out in comments and answers...
Let's start with the structure of your app(s). You are going to end up with four achives... two that you will deploy:
a "regular" jar for the Remote interface of your EJB (jar-of-interfaces)
an EJB jar that has the implementation of your EJB
an EAR archive that will contain the jar-of-interfaces (in the /lib subdirectory) and the EJB jar (in the 'root').
a WAR file that contains the code that uses the Remote interface of your EJB. This will have the jar-of-interfaces in WEB-INF/lib.
The rest of this answer is based on the EJB FAQ. The most applicable part of that document is here.
You can inject the EJB into the ManagedBean. You will not need to use a dot-lookup method in your ManagedBean.
You will need to use the corbaname for your bean in the glassfish-web.xml file.