I have been trying WildFly as application server for a production enviroment, however I have few doubts that I can't answer with the documentation or previous questions.
In the domain mode using the same machine, I have created two server group that are containing one server each one, this is with the idea of isolate two different production enviroments. The problem with the dataSource, is that obviously I have to create them in the profile associated to the server group, but always that I create a new dataSource I need to restart de group, this is a problem since I can't restart the servers for doing this.
Is there a way to do this in a more friendly way?
I'm currently using WildFly 13 and the HAL console to admin the servers.
Related
Encountered a requirement in our team when trying to migrate a WebSphere application into Tomcat and deploy onto Pivotal Cloud Foundry to have same application to connect to two different databases which have entirely same schema with different data, essentially having same application code deployed in different paths and be able to connect to the databases based on the URL being called for accessing the application.
Currently, we handle this situation in Websphere by using the deployment script to deploying the application into two servers and give the different database details in JNDI and access the application using the server names.
We use Jenkins to deploy the application onto PCF.
Tried to use maven to deploy on to different context paths which did not help and have ended up in the loop, Have anyone encountered a situation like this, Any thoughts would be appreciated.
I think there are a number of ways you could handle this.
Modify your application so it's aware and let's you pick. Perhaps have a query parameter to select or /dev/blah goes to one DB and /test/blah goes to another.
Push the same application twice, but bind different databases and routes to each app.
Attempt to run two instances of the same app code inside Tomcat in one app on CF.
Of those, #1 is fine but would probably require code changes. #2 would be my choice as it's very quick to do, #3 would be a lot of work because you'd be fighting against the Java buildpack, which is not recommended.
To accomplish #2, you would do the following:
Push your app code as app-A.
Bind the database service.
Map a route with a context path like my-cool-app.example.com/app-a.
Start your app.
Repeat the same for app-B, but use a different database and route/path (i.e. my-cool-app.example.com/app-b)`.
If you are deploying a WAR file, you will need to tell the Java buildpack to deploy your app on a context path (it should match the route context path you set).
cf set-env my-application JBP_CONFIG_TOMCAT '{tomcat: { context_path: /app-a }}'
https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md#common-configurations
If you're using Spring Boot and a JAR deployment, you'd need to set server.contextPath=/app-a.
Hope that helps!
I am creating a simple web project with mysql database using Java Spring-MVC. Now I want to understand the full workflow of the web system development cycle.
How to upload a project to a real server?.
How to sync the database to a real server?.
How DC and DRC is sync with each other?.
Why and how to use "Load balancer" to the server?.
Apologize, if I said something non-technical.
I'll not go into too much details but here is the gist of it.
Before anything, the first thing to get sorted is the operating system of the server be it Linux, Windows Server and so on. The choice of operating system will depend on the constraints and requirements.
How to upload a project to a real server?
Any files which needs to be served should be hosted and served by a web application server such as Apache Tomcat, IIS, Websphere and many more.
The choice of web application server depends on a few things, such as the server operating system, the web application implementation and so on. For your case, which is a Spring MVC implemented in Java, you'll need to use a web application server that supports that, such as Apache Tomcat for example.
Once the choice is made, install the web application server on the server. After that, install your web application on the web application server.
How to sync the database to a real server?
I infer that you're referring about the connectivity between the Java web application to the database? Do comment if its not.
The Spring MVC web application can connect directly to the database via JDBC or JNDI (provided that the necessary configuration is configured on the web application server).
Of course, the database can be connected locally (if installed on the same server) or remotely.
How DC and DRC is sync with each other?
This is too broad to cover and the recovery strategy differs for every Data Center providers. But broadly, they employ redundancy and replication strategy to ensure the data is always backed up and available. Check with the providers individually for a better picture.
Why and how to use "Load balancer" to the server?
The load balancer primary purpose is to distribute the work load across multiple servers to achieve better TTFB. To do so, it sits in front of the servers and routes the request accordingly. Some of the load balancing solutions such as f5 explains about load balancing in greater detail.
Step 1: Install Application Server on your machine.
Step 2: Install JDK, Database server which are dependent on your application.
Step 3: Export your war from Eclipse/Netbeans
Step 4: Paste your war file on app server's deployment folder (webapps incase of tomcat)
Step 5: your application deployed
I have 4 web applications added (deployed) to the apache tomcat 7 server. The server will host only these applications at any point in time i.e. tomcat is used only to host these 4 applications. And we're not deploying anything in the ROOT.
Now, I'm facing issues with Session Management.
Problem is that I'm getting different sessions for each of the application (which, if I'm correct, is because each application has a different container).
I can think of two possible approaches:
Session remains consistent across all applications. Therefore, it'll
be easy to handle session.
I listen to the web server for application change (change of
context/container, I presume) and then create, validate or
invalidate session.
Here I have two questions corresponding to both the approaches.
Is it possible to have same session across all applications
(containers)?
Is it possible to listen to apache for change of application
(container)?
If answer is YES to any of the questions above, please guide on how I can do it? And if both approaches are not possible, please suggest a better approach?
Present Approach: I'm invalidating the session before switching to another application and after the switch is made, I'll create a new session for the corresponding application. Here, all will work as expected if the user browses through UI but problem persists if the user is in one application and then directly try to access another application through URL (web address).
Please let me know if you need any additional information.
Thanks in advance.
Application containers and contexts are very much isolated, however there is opportunity to do cross context communication. See here and here.
Alternately, you can do your own custom session management using custom headers and interceptors
According to JBoss documentation:
In managed domain deployments are associated with a server group.
Deployments will be provided to any server that belongs to a
particular group.
...the multiple servers in common server group become the single one virtually.
But how does JBoss choose the target actual server for deployment?
For example, i have two different vps servers with JBoss running, which are combined to the single main-server-group. Then which vps server will actually host the application by following command?
[domain#localhost:9999 /] deploy ~/Desktop/test-application.war --server-group=main-server-group
'test-application.war' deployed successfully
The application will be deployed to both servers.
If you were to go to http://server1:8080/MyApp you should see the same as if you went to http://server2:8080/MyApp
The reason for this is that you would normally have a web server or proxy to load balance between the two servers. If you want to have two separate servers which don't have the apps deployed to each, then put them in different server groups or, a better solution would be to run JBoss in standalone mode, rather than domain mode.
I'm starting an JBoss to use on the development, and I'm using it as standalone.
I read that on the production environment the JBoss should be as a domain.
I searched for that to understand what's the difference between than. But I didn't found any document well explained.
That's not really correct. Standalone is fine for production. It's commonly used in production, especially when you only need one instance of the server.
Domain is used when you run several instances of JBoss AS and you want a single point where you can control configuration from. You can read more about it in the documentation.
Update
The link has been changed to the latest version of WildFly as the JBoss AS 7 documentation has been archived, but is still available at https://docs.jboss.org/author/display/AS71/Admin%20Guide.html#8094211_AdminGuide-StandaloneServer
Standalone mode
each JBoss server has its own configuration
single JVM process
Domain mode
central control of multiple servers
central configuration for multiple servers
It's important to understand that the choice between a managed domain and standalone servers is all about how your servers are managed, not what capabilities they have to service end user requests. This distinction is particularly important when it comes to high availability clusters.
So, given all that:
A single server installation gains nothing from running in a managed domain, so running a standalone server is a better choice.
For multi-server production environments, the choice of running a managed domain versus standalone servers comes down to whether the user wants to use the centralized management capabilities a managed domain provides.
Running a standalone server is better suited for most development scenarios. Any individual server configuration that can be achieved in a managed domain can also be achieved in a standalone server, so even if the application being developed will eventually run in production on a managed domain installation, much (probably most) development can be done using a standalone server.
For the Above explanation and more follow this link