Just want to ask if how to deploy only the presentation layer? Im still new in using JBoss, so at the moment I am deploying all the layers, and I realize that only for some time I change on the presentation layer, so I dont want to deploy other layers.
You can use the JBoss Tools plugin for eclipse to keep your source folders and the deployment in sync, so you will not have to deploy at all.
If this is not an option for you, you will have to separate the layers into projects which you can then deploy separately. A single project for the backend and a project for the frontend is a simple and common separation pattern.
Related
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/
How to build and deploy process from Eclipse to jbpm6 console? When I right click on JBPM6 project or BPMN process definition, there is no option of deploying.
Is there an ant script to generate deployable process archive from an eclipse jbpm6 project?
When I ask about Guvnor, people say its removed from Jbpm 6. Where do my deployment go then?
Is there a documentation about the structure of deployment file? Can I deploy my own web services/rest services/EJBs along with JBPM process?
Camunda has a very well documented process deployment model. I am expecting similar model from JBPM6, but there is very little documentation.
http://www.bpm-guide.de/2011/09/28/less-code-bpm-with-camunda-fox-server-activiti-and-jboss-as-7/
There was a huge change in technology in the project for the 6 release, so you need to wait until the final community version is out. Now guvnor was replaced by a different more up to date repository where now all your deployments go. The structure of a deployable artifact is a regular maven project, which make your life easier when you need to deal with dependencies between packages.
Please check the following URL to see the changes in the infrastructure:
http://blog.athico.com/2013/06/goodbye-guvnor-hello-drools-workbench.html
I'm currently working on a project using Eclipse where the unit and integration tests are in one project that also contains the DAO and service layer, and there is another project that includes the Web interface. The Web interface contains the Spring configuration files, and instead of duplicating them for the tests in the DAO project, I want to reference the ones that already exist. However, as I started thinking about it, if this is possible, why not just move them into their own project completely and setup project dependencies. Has anyone done this, and do you have an example of this setup, or can you provide some roadblocks you encountered?
I went ahead with this approach, and it doesn't appear to be causing any issues so far. One of our projects has a (classpath) dependency on the other, but the third test project is able to manage that with some setup and configuration.
At my company, we use Weblogic (depending upon the installation anywhere between versions 6.1 to 11g).
Right now, we embed environment specific variables into our ears, jars, and wars. This even includes the weblogic.xml file where we have something like this:
<working-dir>/opt/bea/wl61/server/domains/deploy/prod3/temp/work</working-dir>
That means we have to rebuild the same jars, ears, and wars for each and every environment. And, if there's a change in the environment, we have to rebuild and redeploy the wars, ears, and jars. You can imagine the issues and problems we have with build and release management (which is my job).
At my last position, we used JBoss, and somehow were able to create generic and deployable ears. I would have Hudson build an ear that the developers could use for their testing. This same ear could then be passed to our QA team in their environment, to UAT, staging, and into production.
We could do this amazing feat because we configured JBoss to look for properties files OUTSIDE or the ear itself. There was a config directory that was a sibling to the deploy directory that contained any needed properties files. Is it possible to setup Weblogic to do the same thing?
We need a way to do this with minimal code changes. I've already examined the source, and we don't specify the directory name when we specify loading the values in the properties files. Therefore, we might be able to do this with some sort of CLASSPATH idea.
I understand that these properties must live somewhere, but I would prefer if it could be configured in the environment, and maybe done by having the path relative to the deploy directory. I want to use the same ear, jar, and war files no matter what system you are on: Windows PC desktop, Linux, Mac, or Solaris server.
The toughest issue will be our weblogic.xml embedded path. Can that path be relative to the deploy directory and not from the root of the system?
As I stated before, I'm the build manager, so as far as everyone is concerned, this is my headache, and not their problem. If deployments don't go well, the Finger 'o Blame can point directly at me.
In order to get this to done I have to be able to find a solution that's simple for us to implement. We can't rewrite everything and change everything around. Otherwise, I can't get the other teams to do this. After all, it's my issue and not theirs. We need something with minimal coding changes (preferably none) and minimal changes in our Weblogic setup. I want something that in Version 3.4 of our software, we do it the old fashion environment specific way, but in Version 3.5, we can deploy in an environmentally neutral way and do that with minimal changes in our deployment environment.
I can feel your pain - I went through the same process at a couple of companies. You have a couple of options that would be a significant improvement from your current setup:
1) Modify the CLASSPATH to use an external directory / properties file that overrides everything that is in the ear file. This is easy to implement but can get out of hand without the proper standards/governance.
2) Use deployment plans to define environment specific variables. However, deployment plans were not introduced until the WebLogic 9.2.
3) Roll all of your environment specific files in to its own jar. All environments would be pointing to the same file but it would be building out different contents based on your build process. Advantages - Single file that contains all the props, easy to move, etc. Disadvantages - Cannot change properties on the fly and force a reload from the JVM.
There may be other options based on the repository. IMHO, all of these work more or less the same - It's the process and enforcing it that prevents issues.
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.