I need a advice for design purpose my structure of the application is as follows.
I have three module designed in ZK framework as a separate war application (web application) e.g finance-module , general-ledger and cash-account , all are separate war files can be deploy on tomcat as a separate war files,
Now I want to have a seperate war ZK application that has index or home page and have menu and from that menu I can able to call these three module or war application.
-------------------------- Main module -------------
Menu : general-ledger link , cash-account-link ,finance-module
1) This 4th Main module also has feature to user login and change user preference , means can also have code e.g view module as well as spring service.
Now the question is that how to call other war files zul pages and even if v call how to manage from 4th module and also how to share session across the four war files or applications.
Thanks
Vikas
I have worked in a similar scenario and this worked well for us:
When you create separate war's it means that they are independently running in it's own web context inside tomcat. Usually when you want to share resources like datasources, transactionManagers, or any other kind of jee resource you need to configure them at the tomcat instance level and they will be available in the JNDI directory of the tomcat server and any web application can pull any of them to use it.
https://tomcat.apache.org/tomcat-8.0-doc/config/context.html
https://tomcat.apache.org/tomcat-8.0-doc/jndi-resources-howto.html
There are several jee resources than you can share in the tomcat server but if you need more flexibility and robustness you might need a full stack java enterprise application server like wildfly http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/ or any other commercial like WebSphere, Oracle Weblogic, etc
Now, if you want to share java classes, zul's or any other file, you may want to package them in separate common jars and use them in any war as a dependency and then reference them through the classpath of the web application.To organize and maintenance this modular projects Maven and Gradle are very good tools you can use.
From ZK you can call any other url of the other war's as simple as
<a href="htt://myserver/account/home.zul" label="Account"/>
<a href="htt://myserver/finnance/home.zul" label="Finance"/>
To share the session what you need is to implement a Single Sign On (there are other implementations like oracle opensso), you can configure it directly in tomcat but be aware of this Sharing security context between few web applications .
Spring Securityhas an extraordinary support for this kind of escenario.
Related
I want to register filter class for all web application in websphere; Tipically in tomcat I specify filter in /conf/web.xml. How can I do this in Websphere 8.5.
Also what is the common library (lib folder) in websphere. The filter class is in jar file and I want to put that jar file in websphere server lib directory.
-Thanks
Unfortunately there is no easy way to do it in WebSphere. It was already discussed here - Global Filter for all Web Applications
WebSphere solution involves creating custom listener and programmaticaly attach filters. You can find sample solution and description here - Adding a servlet filter to all web applications
What is the common library (lib folder) in Websphere?
You can put your jar to WebSphere\AppServer\lib\ext directory to be shared by all profiles, servers and apps, or create a shared library via web console Environment > Shared libraries and attach it to the specific server or application.
OFBiz by default works as a collections of small webapps each with its own front controller. OFBiz webapps typically depend on a lot of common modules. Typically, modules under specialpurpose or hot-deploy would end up depending on pretty much all of the modules under framework and applications... with the embedded container, all libraries go into the catalina shared library class loader but if ofbiz needs to be deployed in a different container, there is simply no easy way. the only options i believe are
package ofbiz as an EAR with a EAR/lib or EAR/APP-INF/lib so that all webapps have access to a common set of EAR level classpath resources.. typically each modules's config, lib and the all important ofbiz-$module.jar
each webapp packages each of the required jars into its own WEB-INF/lib.. too much duplication and also increases the filesystem footprint in a sense
use the application system classpath in lieu of catalina shared.lib folder - which means the JVM has to be dedicated to ofbiz as its jars would otherwise interfere with other sibling deployments and potentially even with the container itself, typically things such as XML, XSL, STAX apis etc..
given that ofbiz load most of the resources using the filesystem (ofbiz.home + component://) resulution. What the webapp really needs access to in a convential servlet context kind of way is the
controller.xml
classpath resources - across the various ofbiz-$module.jar in shared.lib. typically, each modules's config, lib and the all important ofbiz-$module.jar
imported (component://) webapp resources like other controller.xml for various modules. most importantly the framework/common/webcommon/WEB-INF/controller.xml that provides the boiler plate security implementation like checkLogin and autoLogin....
I was wondering if we could somehow package multiple webapps into a single monolithic webapp using front controller namespacing so that the war maps to a single root content like say / (ROOT on tomcat) and /content, /webtools, /catalog, /ecommerce etc. are mere URL namespaces/subcontexts rather than separate webapps. framework/common/webcommon/WEB-INF/controller.xml could become the root controller for / (ROOT in tomcat) and provide checkLogin, autoLogin etc to all webapps without each controller having to import that controller.xml
This would allow us to simply the deployment model when we would want to move to other containers like say weblogic, jboss et al where we would be better of building a single webapp with all of its dependencies neatly packaged into its WEB-INF/lib such that it could coexist with other deployments in the same container without interfering with their dependencices and their versions...
I believe struts had this kind of modular namespacing where there could be a root level struts.xml (our case controller.xml) and each module would be a folder with its own module/struts.xml or module/struts-module.xml etc...
i personally feel this would be helpful.. i have not thought enough about the downsides. there could be many? i honestly don't know. I have not given enough thought to themes either.. developers clearly would not like to see any change in the way code is laid out or organized.. so with some minor? :) changes in the core MVC code in the framework, we could potentially support this kind of deployment using a simple ant build script that stages candidate webapps into a merged monolithic webapp...
i was hoping to see a debate on the merits of this idea... i would even be willing to invest some time into making this work if i get some direction and inputs..
Have you considered using chef to deploy Ofbiz instead?
I wrote the following cookbook to demonstrate how it could work:
https://github.com/myspotontheweb/chef-ofbiz
This is a difficult part of how Apache OFBiz is architected. Using EAR files works okay, but shared classpath resources in an EAR file are app-server specific, and you have to deploy in a container that supports EAR files which limits choices.
One of the limitations is the flat namespace for requests in the controller.xml files, and what you describe would be the best way to handle that (use a different ControlServlet mount point for each OFBiz component app). Doing so may require some code changes for the URL writing (the #ofbizUrl FTL tag and the underlying code used elsewhere). It would also require a bit of work to write an ant target or something to build the WAR file, pulling in all the webapps from the various components (or just those desired), writing a combined web.xml file, etc, etc.
This is a recognized issue with OFBiz, and isn't a problem for most deployments, but does make it more difficult to scale down or host along with other applications. You can add other webapps through OFBiz components to host them on the embedded servlet container, but I don't imagine that is what you are looking for.
One of the issues with making this and many similar changes in OFBiz is the large code base, large user base, and the somewhat large committer group with diverse opinions on things like this. For these and other reasons a lot of the ideas for improving OFBiz can't be easily realized there, and that is why I started the Moqui Framework project in 2010.
Moqui deploys with a single WAR file, and can have an external or embedded runtime directory to make it easy to deploy on WAR hosting services such as AWS ElasticBeanstalk, as well as dropping in to servlet containers such as Apache Tomcat. The WAR file is also an executable JAR file using an embedded Winstone servlet container for easier development and automated testing. There are details about running and deploying Moqui here:
http://www.moqui.org/framework/docs/RunDeploy.html
BTW, this is one of hundreds of ideas for improvements to OFBiz that made it into Moqui Framework and the separate project with data model and services (Mantle Business Artifacts). There is general information about it here:
http://www.moqui.org/
Hullo - issue is this:
I wrote a servlet in Eclipse which requires mysql-connector-java-5.1.22-bin.jar
To compile I need to add the jar via the project's "Java Build Path"
To deploy I need to add the jar to the project's "Deployment Assembly"
To run the servlet within eclipse I need to add the jar to the servlet's Run Configuration -> Classpath
It's not the end of the world re-re-repeating myself like this, but it does seem odd.
Given that Eclipse gets a lot of other stuff correct I'm guessing / hoping that maybe I'm overlooking some feature to avoid this silliness (I cannot imagine a scenario where you'd benefit from entering this in 3 different spots ... but maybe I'm being uncreative here ...).
Insights appreciated :-)
The only thing you need to do is to drop the jar in WebContent/WEB-INF/lib.
You are developing a Java Web project, so the traditional place to put the required libs (JAR files etc) is under /WEB-INF/lib. And you do it only once.
In Eclipse, when you create Dynamic Web Project the appropriate project structure is generated for you (this is a development structure). In this case you place your JAR files in ProjectName/WebContent/WEB-INF/lib folder. And this folder is *automatically included in the project's build path.
Considering the fact that it is a Java Web project (you said you use servlets) you have to deploy your web app to some Application Server, like GlassFish, JBoss, WebLogic, WebSphere etc, or more simple Web Container like Apache Tomcat. If you do this thru Eclipse, then again your web project is automatically deployed.
NB!
There may be some additional details related to using libraries.
For instance, when it comes to using database drivers (MySql, PostgreSQL, Oracle etc) Tomcat advises the following while configuring JNDI Datasource (quote):
Before you proceed, don't forget to copy the JDBC Driver's jar into
$CATALINA_HOME/lib
In your case (MySQL) see the example here: MySQL DBCP Example
Also see my answer related to Webapp configuration file organization convention.
Hope this will help you.
P.S. Here is a step-by-step example: How do I access MySQL from a web application?
We have ".sar"(Service Archive file) used in jboss. Currently we are planning to migrate the code to Weblogic.
Is there a way to deploy .sar files into weblogic.
If not directly possible, is there a work around where we can deploy the services on web logic.
In order to get the custom mbeans that are in the .sar you will need to repackage the contents as an .ear as a .sar is not standard Java EE deployment mechanism - that is a JBoss proprietary archive.
Here are some instructions on how to create, package and deploy your own service MBeans (JMX Beans) along with an example of how to use it.
https://blogs.oracle.com/WebLogicServer/entry/developing_custom_mbeans_to_ma
One thing you could do is to "substitute" or "emulate" the SAR Deployer, by creating, configuring and registering MBeans. That, AFAIK, could be done in two ways:
1) Using Standard Java EE components: that means on web tier you can use the init() method of a servlet (make sure that it is preloaded on startup) or, better, a ServletContextListener
2) Using WebLogic specific components. I'm talking about Startup classes. Simply register a startup class that creates, configures and registers your MBeans.
If you are using a web module, the first approach has the obvious advantage that you are using pure Java EE components. Although you are not using that, you can add a "dummy" web module only for doing that
Concerning what you have to do in those classes, you can choose a "from scratch" approach, by parsing the xml files that describe services and therefore manually create, configure and register MBeans or, if I remember well, the XMBeans from JBoss is something that can be reused outside JBoss but you need to check because I'm not sure
I am in the process of designing a build system and the directory structure for a large software system developed with Java EE 5. The build system will be implemented using ant.
We have multiple different services, which are grouped thematically. Each service offers either a web service or EJBs. Each service runs on a dedicated application server cluster. Thus, we have multiple clusters and some of these clusters can be grouped logically by topics.
I did read generic definitions and examples, but I am still confused about the Java EE terminology:
What is a Java EE application? And thus, what is the content of an EAR file?
What is a Java EE Project? (the term is used by Netbeans as well as in the Java Blueprints Guidelines Project Conventions for Enterprise Applications)
Do I have to put all EJB and WAR-module-package-files into one single EAR, so that this single EAR contains our complete system?
Or do I put each group of services into one EAR, despite the fact that these services are only grouped logically but not technically?
Or do I assemble a separate EAR for each service, i.e. most often only containing a single EJB jar file and sometimes and EJB and a WAR file?
Or do I dismiss the concept of applications and merely build EJB and WAR files, so that I have exactly one deployment file for each application server cluster?
I guess, my main question is: What are the advantages of packaging EAR files?
As I see it at the moment, there is only the need for EAR-EJB and WAR files and additionally the concept of nested subproject in the ant-build-system and the directory structure of our source?
Edit: Thanks a lot for the answers! It seems to me that an application packaged into an ear is a rather atomic subsystem. So I guess, that I will have a nested subproject-structure (only logical, visible only to the build system and in the directory structure of the source) and a rather large amount of EARs, each of those containing mostly only one ejb-jar and/or war module and implementing a single service (which is deployed on a single application server cluster).
I think what you decide to put in each EAR is governed by organizational and technical issues.
I think most important technical role of an EAR is a classloader root in a runtime environment. This normally means you can deploy different versions of libraries and your own classes in different EAR's. This means you should keep your container root classpath fairly empty (or as supplied by the container vendor), because it may allow one phsyical container to service multiple applications using possibly conflicting libraries. This is great news if you're developing a number of different applications using a common code-base. You can have a number of projects deploying to the same farm of servers without messing up for eachother.
You will normally never deploy a smaller unit of software than the EAR. Each EAR can be more or less fully self-contained. I would normally let the content of these refelect what the owning organization thinks of as applications or subsystems. You can usually package the same components in multiple EAR's.
Lots of questions here.
Java EE projects are either EAR or WAR deployments that use Java EE technology. If you have a WAR with JSPs and JDBC access of a relational database, that's a Java EE project. The original intent was that EAR files were "enterprise", and that meant EJBs. An EAR file an contain EJBs, WARs, JARs, the whole enchilada.
Thinking in terms of services are a little different. I think deployment deserves careful consideration, because components that are packaged together must be brought down and up together if any maintenance has to be done.
So think carefully about how you package your services. It's not an all or none blanket answer, IMO. You should look at what your services are doing and how they might be used together to decide how they should be packaged and deployed.
Both Logical and Organizational considerations come into play. Each EAR would contain all the pieces that are related for a particular capability. We can always assume that each EAR will be self contained and can be deployed on one or more containers. The typical approach that I have always followed is to have each EAR contain one or more jars and wars. Each war or jar contains some key component or set of related components. The EAR represents an Enterprise application that contains the components and web apps for the application.
An Example is a Payment processing system I was involved in.
The EAR contained everything required to run the Payment Processing system. This included half a dozen jars and 3 wars. Each jar represented some functionality or logical grouping of functionality. Each war represented a web app.
An example of the jar's composition:
a jar for core functionality
a jar for ejbs
a jar for our advanced financial math pieces
a jar for our security pieces
etc.
Having multiple jars was dictated by the fact that different people developed different pieces so they worked in different Eclipse projects and combined them all as needed.
There are no hard and fast rules, just whatever works for your team and situation.