Can a Worklight Server be deployed to a WebSphere application server which also runs other non-Worklight .ear applications? Or does Worklight need its own separate instance of WAS?
Just like you can deploy multiple instances of Worklight (v6 and above) projects - multiple .war files to the same WAS application server, there should not be issues to deploy it to an application server running other services.
That said, possible issues to consider:
When deploying a Worklight project, you will want to enable "application security"
(in the WAS admin console, Security > Global Security). If there are some other web
applications for which application security is undesired, you need a different WAS server
instance.
Setting up, enabling and migrating security
The list of users that can use the web applications are configured through LDAP or
"federated repositories", or similar. If, for Worklight, you need to use a completely
different set of user logins than for the other web applications, then you need to use
multiple "security domains".
Configuring multiple security domains
The machine hosting the application server will probably need memory upgrades...
Deploying the Enterprise Archive (EAR) Using the WebSphere Admin Console
Probably also need to make clear seperation where required:
IBM WebSphere Developer Technical Journal: Co-hosting multiple versions of J2EE applications
Worklight is itself an application running inside a web container, whether that be Tomcat, WAS Liberty, or full WAS. It's essentially a layer running underneath the container to handle requests for Worklight applications, fielding their context root requests. If you create the WAR file for your Worklight app and extract out the deployment descriptor you'll find all the necessary filters and listeners that most other apps would have.
Things like adapters and wlapps are "installed" to this underlying layer, and are merely extracted and stored as whatever was packaged with them, such as the JS and CSS you used to make you app. In fact, with a standard Liberty install you can typically find your adapters in plain sight at (for the WL5.0.6 instance I have handy, it's different for WL6):
/opt/IBM/Worklight/server/wlp/usr/servers/worklightServer/worklight.home/worklight/data/export/adapters
So, in addition to what Idan has said, I also present you with the following docs (assuming WL6)
Overview of the Worklight Server installation process
Given my own experience, you should be perfectly able to install other EAR and WAR files to your existing WAS instance, just make sure your context roots are unique, as always ;)
I also second the memory considerations.
Related
I do not understand the following statement of DefaultCacheManager's Java doc. It says
CacheManagers are heavyweight objects, and we foresee no more than one CacheManager being used per JVM
Am I allowed to create DefaultCacheManager programmatically for each web application in the server? For example, I have two web applications, A and B. They are running in the JBoss AS (standalone only). Each web application (A and B) creates own DefaultCacheManager object.
Yes, you can create more cache managers. The term heavyweight here means that cache manager contains thread pools, JGroups channels (that means consumed ports) etc. so you should not create too many of these.
The situation might be a bit different in an application server with deep integration - some of the resources can be shared there. Check out the Infinispan subsystem - cache manager then maps to a cache-container. It's perfectly fine to have multiple cache containers in the configuration.
In application server, the applications should not create the cache managers; these should be only injected (e.g. through CDI) to your webapp.
Will PCF run the Tomcat embedded in Spring boot jar or it runs its own tomcat. In PCF we never mention the port number. In the classic approach, we start 3 Tomcat instances in different port number and have apache server before that. Does PCF work the same way.
This is a pretty broad question, so I'm going to answer with a pretty broad response but link you to where you can find more details, if you are inclined to dig in more.
How PCF works internally when deploying Spring boot project
Will PCF run the Tomcat embedded in Spring boot jar or it runs its own tomcat.
When you run cf push -p my/cool/file.jar (or even file.war), the cf cli extracts everything from that archive and pushes it up to CF. CF stores your app files & then your app is staged.
During staging, the Java build pack runs. It looks at all the files that were pushed & tries to determine what to do with them. It knows how to handle several different types of apps [1], including both standard WAR files & Spring Boot apps. The build pack will check your app to see if its one of the supported types in order [2] and will select the first match.
After selecting the type of app, it runs through and installs what is necessary to run your app. For a Spring Boot app, that's basically just the JVM. For a WAR file, it installs Tomcat & a JVM. In addition, it writes out the configuration & start up commands necessary for CF to launch your app.
At this point staging is complete and you have what is called a "droplet". If you have any additional questions on the staging workflow, read here for more details [3].
At this point, the app would be started. The platform takes the droplet that was created and executes the command specified by the build pack to start the app [4]. If all goes well, your app will then be up and running on CF.
In PCF we never mention the port number.
Correct. The platform will tell you the port on which your application should listen. For Java apps, you don't have to do anything. The Java buildpack will handle configuring Spring Boot or Tomcat to start and listen on the correct port.
For Spring Boot apps, you can look at the start up command to see how it's doing this. For Tomcat, it happens in the server.xml that's generated by the Java buildpack [5].
In the classic approach, we start 3 Tomcat instances in different port number and have apache server before that. Does PCF work the same way.
Yes and no. Each application you run can have multiple instances. If you scaled your app to have three instances, that would be roughly like having 3 Tomcat instances in your classic approach.
The main difference is that there would be no Apache Web Server in front. On Cloud Foundry, this is not necessary because it has it's own load balancer called Gorouter [6] which handles proxying traffic to your app and load balancing across available app instances.
This is a classic mistake that people new to CF make. They try to replicate classic architectures and shoehorn a reverse proxy into their app when it's not necessary. This is one of the benefits of CF. It handles routing traffic to your app in a scalable way, freeing you up to focus more on your app.
[1] See "Standard Containers -> https://github.com/cloudfoundry/java-buildpack#additional-documentation
[2] https://github.com/cloudfoundry/java-buildpack/blob/master/config/components.yml#L18
[3] https://docs.cloudfoundry.org/concepts/how-applications-are-staged.html
[4] https://docs.cloudfoundry.org/concepts/overview.html#apps-anywhere
[5] https://github.com/cloudfoundry/java-buildpack/blob/master/resources/tomcat/conf/server.xml#L21
[6] https://docs.cloudfoundry.org/concepts/architecture/#routing
No. The simple answer is each instance of ur application jar is running in its own container within PCF. So there is no clash of using the same port numbers.
So, we have two Liberty servers with different versions.
WAS Liberty 16.0.0.2, and
WAS Liberty 17.0.0.2
Both of servers has the same configuration
But, the problem is, even with the same configuration, WAS Liberty version 17.0.0.2 will auto load application context/servlet on start/restart without sending a request to them, while WAS Liberty version 16.0.0.2 will not auto load application context/servlet on start/restart unless we send a request on it.
As per our search regarding this issue. In the IBM Knowledge center, it says that by default Liberty defers servlet loading until a request is received for the associated web application... but in WAS Liberty version 17.0.0.2, it will automatically load the servlet/application context.
Help will be very much appreciated for this one.
Note: we did not add <webContainer deferServletLoad="false"/> in our server.xml
Liberty used to deploy the web application on first request. That was the behaviour in 16.0.0.2. I don’t recall exactly when we changed when we deploy, but we updated to deploy async during startup rather than on first request since a number of people were expecting their servlet inits to be triggered sooner than first request.
My organization is using Websphere Application Server with RAD. My unit is developing Web Services that take data from a consumer, and often pass the data through other Web Services.
Currently, we have two ways of defining time-out's for data to be returned from called services:
Using the Spring framework
Websphere profile configuration
If we need to update the values using Spring we need to re-deploy our service. If we define them as JVM properties we need to do a JVM configuration change and 'restart/recycle/stop and start' the application.
My co-worker had it suggested to him that there may be some better solutions to this problem. I'm wondering if this is true, and if so what they are?
edit:
One option we might be considering is "Application Policy Sets". We'd like to know if this is a good alternative method:
can we define Spring to leverage policy sets
can we define multiple policy sets for an application when timeout values for different services called by our service are different?
Does this console change take affect at run-time, or do we need to recycle?
I suggest you use JAX-WS policy sets and bindings on WAS level, because it allows you to:
define policy set for each web service separately
in policy set define web service parameters, from HTTP transport parameters to WS-Security policies such as UsernameToken, digital signature and encryption
web services remain unchanged, the code remains the same
there is only one place where you change it: in WAS console, application is not changed
The only drawback here is that web services should be generated from RAD (you can use top-down or bottom-up approach).
Please see more details in this excellent 3-part DeveloperWorks tutorial
I am new to MDB, so my questions may sound simple.
I implemented an MDB( serving as a Consumer ) using JDeveloper 11.1.7 and built a JAR file using deployment functionality. Now I need to deploy it to WebLogic 10.3 app server. I have several questions:
1) Should I deploy it as a library or as an application?
2) After I successfully deploy and it's in the "RUNNING" mode I assume it should be listening to the particular Queue I specified as a Resource in my MDB implementation. Is that correct?
3) When implementing an MDB all the examples only specify the "destination" but not the "ConnectionFactory". How does it know where to connect to?
Should I deploy it as a library or as an application?
Deploy as an application since the MDB will likely contain business logic specific to the app.
After I successfully deploy and it's in the "RUNNING" mode I assume it
should be listening to the particular Queue I specified as a Resource
in my MDB implementation. Is that correct?
Yes, if your JMS provider is local, specify the name bound in the local JNDI tree for the destination using destination-jndi-name.
When implementing an MDB all the examples only specify the
"destination" but not the "ConnectionFactory". How does it know where
to connect to?
If the MDB is consuming messages from the local WebLogic JMS provider, the container manages configuration for the connections and sessions automatically, so don't set provider-url, initial-context-factory, or connection-factory-jndi-name, unless you have a custom factory to use.
Refer to WebLogic 10.3 documentation for details: