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.
Related
I have a Spring Boot application (App1) that uses an embedded Tomcat. To specify the Port I added server.port=8080 to the application.properties in my main application
and it works fine.
Now I add a dependency to another Spring Boot application (App2) in the pom.xml (because in App1 I need access to the Beans from App2). App2 uses also an embedded Tomcat on a different port.
But when I run App1 it crashes because App2 want to also use the same server.port and configurations - that obviously cannot work.
Is this even possible what I want to achieve? And how would I do this that I can run both App2 in App1? If this is not possible, is it possible to access the Beans from App2 in App1?
I see two options, depending on which one suits your use case conceptually:
you have two Spring Boot applications that need to share the same code: extract this code to a separate project (a regular Java library), build it as a jar file and include into both projects as a dependency; an example could be found in the Creating a Multi Module Project guide;
you have two Spring Boot applications, one of them needs to access the functionality of another: provide and access this functionality as an API, instead of directly importing the beans. There are multiple ways to do this. For example, you could expose the bean functionality as a REST API using Spring's #RestController, and access them from the other side using RestTemplate. See the following guides: Building a RESTful Web Service, Consuming a RESTful Web Service
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)
In my company, we're developping an application which stores its data in a Neo4j DB using a semi-custom persistence layer. Using that persistence layer, we declared our security layer using classical classes : User, Group, Privilege and so on.
These elements are naturally persisted to our Neo4J DB.
Unfortunatly, we now want to declare our custom JAAS realm, usign that Neo4J DB as back-end. To write that realm in the fastest possible fashion, we decided to use our application code in that realm (by the grace of a maven <dependency/>).
Unfortunatly, we have discovered that, when we deploy our JAAS realm, application code fail to load wih various
java.lang.RuntimeException: EJB Container initialization error
Exception while loading the app : EJB Container initialization error
Maybe is it linked to the fact that we deploy our JAAS realm in ${domaindir}/lib ?
Anyway, is there a solution to have one glassfish JAAS realm share some code with one application deployed in domain ?
You say that the JAAS classes are deployed to /domain/lib (which seems correct me).
I assume that your application classes are deployed as a WAR or EAR.
If your implementation of the JAAS realm depends on classes that are in the WAR/EAR, you get classloading issues because of classloader hierarchy.
The /domain/lib classloader cannot access classes in your WAR/EAR.
You should extract the depending classes to a separate jar and put them in /domain/lib too.
See here for more info about the classloader hierarchy: http://docs.oracle.com/cd/E18930_01/html/821-2418/beadf.html
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'm reading up on JMX for the first time, and trying to see if its a feasible solution to a problem we're having on production.
We have an architecture that is constantly hitting a remote web service (managed by a different team on their own servers) and requesting data from it (we also cache from this service, but its a sticky problem where caching isn't extremely effective).
We'd like the ability to dynamically turn logging on/off at one specific point in the code, right before we hit the web service, where we can see the exact URLs/queries we're sending to the service. If we just blindly set a logging level and logged all web service requests, we'd have astronomically-large log files.
JMX seems to be the solution, where we control the logging in this section with a managed bean, and then can set that bean's state (setLoggingEnabled(boolean), etc.) remotely via some manager (probably just basic HTML adaptor).
My questions are all deployment-related:
If I write the MBean interface and impl, as well as the agent (which register MBeans and the HTML adaptor with the platform MBean server), do I compile, package & deploy those inside my main web application (WAR), or do they have to compile to their own, say, JAR and sit on the JVM beside my application?
We have a Dev, QA, Demo and Prod envrionment; is it possible to have 1 single HTML adaptor pointing to an MBean server which has different MBeans registered to it, 1 for each environment? It would be nice to have one URL to go to where you can manage beans in different environments
If the answer to my first question above is that the MBean interface, impl and agent all deploy inside your application, then is it possible to have your JMX-enabled application deployed on one server (say, Demo), but to monitor it from another server?
Thanks in advance!
How you package the MBeans is in great part a matter of portability. Will these specific services have any realistic usefulness outside the scope of this webapp ? If not, I would simply declare your webapp "JMX Manageable" and build it in. Otherwise, componentize the MBeans, put them in a jar, put the jar in the WEB-INF/lib and initialize them using a startup servlet configured in your web.xml.
For the single HTML adaptor, yes it is possible. Think of it as having Dev, QA, Demo and Prod MBeanServers, and then one Master MBeanServer. Your HTML Adaptor should render the master. Then you can use the OpenDMK cascading service to register cascades of Dev, QA, Demo and Prod in the Master. Now you will see all 5 MBeanServer's beans in the HTML adaptor display.
Does that answer your third question ?
JMX is a technology used for remote management of your application and for a situation for example when you want to change a configuration without a restart is the most proper use.
But in your case, I don't see why you would need JMX. For example if you use Log4j for your logging you could configure a file watchdog and just change logging to the lowest possible level. I.e. to debug. This does not require a restart and IMHO that should have been your initial design in the first place i.e. work arround loggers and levels. Right now, it is not clear what you mean and what happens with setLoggingEnable.
In any case, the managed bean is supposed to be deployed with your application and if you are using Spring you are in luck since it offers a really nice integration with JMX and you could deploy your spring beans as managed beans.
Finally when you connect to your process you will see the managed beans running for that JVM. So I am not sure what exactly you mean with point 2.
Anyway I hope this helps a little