From time to time I get exceptions like MethodNotFoundException and ClassNotFoundException when deploying my web application to a JBoss AS 7.1 server. The reason for this is that JBoss has its own built-in modules which it prefers over libraries in my own war. I know that I can selectively exclude modules with the jboss-deployment-structure.xml, but I rather just not think about it and have it work exactly as it would when deploying it to, for example, Jetty.
Is it possible to configure JBoss to not provide any modules?
What are the use cases for using built-in modules? In my opinion, the duplicate libraries I would have to provide when deploying multiple war's doesn't outweigh the disadvantage of having possible different behavior in comparison to the environment in which I'm running my automated tests. I must be missing a vital advantage.
Related
I am planning to use AspectJ's loadtime weaving feature for proxying in a Spring based web application. The three things (AFAIK) that are needed to get this working are:
Set the proxying mode to "aspectj" (as opposed to "proxy")
Add the spring-aspects and the aspectjweaver to the classpath
Add the spring-instrument agent to the VM startup
My question was on the best practice on how to achieve #3. My causes of concern are:
Since this is needed at application startup, I can't have it point to the spring-instrument jar in the WEB-INF/lib location of my webapp. I was thinking of having a static spring-instrument jar sitting in my CATALINA_HOME/lib that can be directly referred to.
As the web application progresses, it might be the case that the spring version may be upgraded and we may forget to upgrade the version of the jar in CATALINA_HOME/lib.
Many different applications may be using the same CATALINA_HOME and it is not always possible to have everyone upgrade the spring-instrument jar in lock-step fashion.
Since this problem seems to be like a generic one, I wanted to know from others how they address this concern.
Thanks!
Depending on the container you don't need the spring-instrumentation.jar. A single <context:load-time-weaver /> in your configuration is enough.
You will need a recent version of Tomcat (version 8), Jetty, WebSphere, Weblogic or JBoss.
I had first found a reference to JBoss Modules when I stumbled upon Ceylon language which uses JBoss Modules as its module system. Immediately I wanted to try this system in some toy project and maybe even embed it in a real project (I was writing a project with plugins support at that time), but I couldn't find any documentation on JBoss Modules as a standalone library. The only available documentation source seems to be the official wiki, but it looks abandoned and unsupported. I couldn't even find Javadocs for it (except, maybe, this, but it seems to be very old and not really related to JBoss Modules due to "osgi" presence in the link).
It seems that JBoss Modules are usable outside of JBoss AS because Ceylon language uses it, but lack of almost any documentation on the subject is disappointing.
So, here are my questions:
Is it possible to use JBoss Modules as a standalone library at all? Are there any artifacts in some public Maven repository?
If it is (and there are), is there any documentation on it? That wiki I have mentioned does not have, for example, any instructions on embedding JBoss Modules.
If you'd like to try out JBoss Modules directly, you can grab the dependencies from the JBoss Nexus repository: https://repository.jboss.org/nexus/content/repositories/public/org/jboss/modules/jboss-modules/
Unfortunately, there isn't much documentation on JBoss Modules, but if you want to try it out, you probably don't want to be hand-writing modules.xml files yourself (maybe you like pain, I don't know.)
If you'd like to try out "Furnace" the modular container based on JBoss Modules and Maven that serves as the core module system for JBoss Forge, it give you the ability to write Maven projects that can be loaded directly as Modules. This is what we are using for our entire Forge 2 architecture.
You can find some docs on Furnace here:
https://github.com/forge/furnace#furnace
https://github.com/forge/core#developing-an-addon
Note that Furnace Addons require a maven classifier, you can choose the classifier used if you want to. This is done via the Furnace Manager (which can be seen in the furnace docs above.)
Yes. Actually, JBoss is using it that way as well - so JBoss application server is actually running inside JBoss Modules system.
I'm not aware of such documentation, but usually you shouldn't be embedding jboss modules, but running the applications with it. I'm not aware if you can embed it.
I actually got most information from this presentation in vimeo, Modular Class Loading with JBoss Modules. There seems to also be Zen of Modules video there.
I'm planning to build a Java-based system to handle different business processes where each of these is a particular module in the system. Most modules would depend on some of the other modules to handle their particular business process. In other words, top modules would consume some sort of basic services provided by underlying modules. Some modules will be developed from the very beginning, but some will be added to the system later. Next, some modules will expose RESTful interfaces to handle external input / output.
To handle all this, OSGi seems appropriate, but it's a bit difficult to learn with all the different "distributions" out there (Equinox, Felix, etc.) and I'm concerned about the ease of using the Spring framework and other 3rd party libraries within each module (starting with Spring 3.2 the different jars might not come with OSGi manifests).
On top of this, I'd like a central web portal to administer all bundles, thus with each new bundle there will be a new admin section.
that's why we developed osgi-less modularity for Spring https://github.com/griddynamics/banshun Your feedback is appreciated!
Why do you need OSGi? Why not use a Web Server like Tomcat, and deploy your application as a war? You can deploy it on multiple servers in a cluster, and your application can scale on and on.
Why do you need Spring? It has become incredibly coupled. And it has a complexity that find quite useless since OSGi applications tend to be built from small components communicating through services; voiding most of the advantages of the Spring wiring model which assumes it is central.
And hard to configure is a strange remark, OSGi is excellent configuration support. It is just different than what you're used to.
Instead of using spring, why not using OSGi Blueprint it'll give you an "easy" transition from Spring to OSGi.
OSGi seems to have an excellent benefit of having small deployable artifacts by not wrapping dozens of JAR dependencies into a lib directory. However, I can't find anything that tells me an easy, reliable way to deploy dependencies to a container. For instance, I have an application that uses CXF and several Spring subprojects. If I need to deploy this application to a new Glassfish server, what would be the best way to do so, ensuring that all dependencies get installed?
I'm using Maven, and it would seem that there could be some way to have a hook that looks at the META-INF/maven directory and pulls the dependency list from the pom.xml and goes and fetches the required libs (probably from a local repo). Is there a way to do that?
The Pax plugin sort of sounds like it's doing this, but it seems to be based around boostrapping a Felix container? Which is not what I want, I am dealing with an already running, remote container.
Is there any shot such a thing exists as command line tool as opposed to GUI as well?
There are a number of ways to deploy dependent bundles to OSGi containers. Here are some of them:
1 The Felix OBR bundle repository
You first need to create an XML index file for your available bundles, using a tool such as bindex. If you are using the maven-bundle-plugin, then it automatically maintains an OBR index in ~/.m2/repository/repository.xml.
Load the index using the OBR command-line interface:
> obr:addUrl file:/Users/derek/.m2/repository/repository.xml
Then ask OBR to deploy your target bundle, with dependencies determined from the OBR index:
> obr:deploy com.paremus.posh.sshd
Target resource(s):
-------------------
Paremus Posh Ssh Daemon (1.0.23.SNAPSHOT)
Required resource(s):
---------------------
Paremus Command API (1.0.23.SNAPSHOT)
Optional resource(s):
---------------------
Paremus Config Admin Commands (1.0.23.SNAPSHOT)
Paremus OSGi & LDAP Types (1.0.23.SNAPSHOT)
2 Apache Karaf
Karaf supports "features", which are basically lists of bundles required to provide the feature:
karaf#root> features:info obr
Description of obr 2.0.0 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no dependencies.
Feature contains followed bundles:
mvn:org.apache.felix/org.apache.felix.bundlerepository/1.6.4
mvn:org.apache.karaf.shell/org.apache.karaf.shell.obr/2.0.0
mvn:org.apache.karaf.features/org.apache.karaf.features.obr/2.0.0
karaf#root> features:install obr
3 Eclipse Virgo
Virgo uses plans to define the artifacts that comprise an application and it is able to
automatically supply the dependencies of an application including bundles, plans, plan archives (PARs), and configurations, from both local and remote repositories.
4 Paremus Nimble
Nimble uses OBR (or its own extended) repository indexes, to automatically deploy all dependent bundles needed to activate a target bundle (and uninstalls them when the target bundle is stopped). It can also detect other dependencies, such as a WAB bundle requires a web-extender and automatically install one according to a configurable policy.
Nimble can also be configured to launch Glassfish, so that its features are available to bundles in the Glassfish container.
The example below also shows that logging support is automatically installed when sshd is activated:
$ posh
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
[denzil.0]% nim:add --dry-run com.paremus.posh.sshd#active
-- sorted parts to install --
4325 osgi.resolved.bundle/ch.qos.logback.core:0.9.22
-- start dependency loop --
5729 osgi.resolved.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
5727 osgi.active.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
3797 osgi.resolved.bundle/ch.qos.logback.classic:0.9.25.SNAPSHOT
3792 osgi.resolved.bundle/slf4j.api:1.6
-- end dependency loop --
436 osgi.resolved.bundle/org.apache.mina.core:2.0.0.RC1
6533 osgi.resolved.bundle/sshd-core:0.3
398 osgi.resolved.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
396 osgi.active.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
(disclaimer: I'm a developer at Paremus)
5 Apache Felix Gogo
gogo is the new RFC147 standard command-line shell. It is already used in Felix, Karaf, Nimble and will soon be available in Glassfish.
Gogo allows you to run any commands that you could type interactively, as a script. So you could generate the list of bundles to install and convert it to a script, or even capture the installed bundles from a working configuration so that it can be re-created from a clean start.
If you create an OSGi application and a classic Java application that do the same thing and use the same libraries then you'll need exactly the same set of JARs. The big difference is being able to explicitly define your dependencies (and possibly produce more granular JARs for your application).
There's only one pure OSGi-based server that I know of (Eclipse's Virgo, previously Spring's DM Server). Glassfish and Websphere have support for OSGi, but I haven't played with them so I can't say much. What I can say is that all of them require an OSGi container and that's usually Eclipse's Equinox or Apache's Felix.
Your question seems to really be about provisioning the application (working out what needs to be deployed). I know that for Maven 3.0 they've done a bunch of stuff working with Eclipse's P2 provisioning framework.
For your application are you deploying an EAR or WAR? For either of those, your build system will need to produce the archive with all dependencies or it won't work. It's a bit confusing on why you have a problem because people use Maven because it does the transitive dependency management for their builds.
There is a fundamental aspect of your question that is not yet addressed.
Glassfish is indeed a full fledged Application server like most modern application servers: these provide you with a Web container (where you would deploy WAR archives), a Java EE container (to deploy EJB's in JAR and EAR archives), as well as integrate an OSGI container. The later is then used for the application server's own internal start-up mechanisms.
In essence, you may target three containers. Modern IDE's and build tools provide you with means to pack your logic to target any of these. So the question becomes: how do I architect my application with all those possibilities?
There are a few very important technical issues not to lose from sight. (I focus here on objective and factual considerations, keeping out from any subjective choices, philosophy, strategy, and other context-dependent considerations that indeed may also weight much on your final decision):
An OSGI container does not provide you with Implicit or Declarative Thread Management, Persistence, or Transaction management services like the Web and Java EE containers. So, do plan to analyse these issues and produce the code to manage your threads and deal with transaction propagation over these threads for instance. Of course OSGi provides all necessary APIs to deal with those aspects, but does require coding (where AOP may help). On the other hand, in the Web and Java EE containers, you rely on container-managed services and/or use EJB annotations, deployment descriptors, and server managed objects like pools to simply declare how many threads you want in parallel, the sizes of connection pools, and which transaction attributes. There are advantages and drawbacks in either style (procedural in OSGi versus declarative or implicit in java app. servers).
OSGI provides an orderly way of loading your code, manage module dependencies, even deal with multiple coexisting versions of the same module, and dynamically add/remove and start/stop so-called bundles (OSGI deployment units), provided indeed your bundle contains the logic to handle potential start/stop issues like properly interrupting all launched threads on a stop -- threads which could have 'propagated' through other dependent modules. On the other hand, Java EE and Web containers will often embark copies of dependent JAR's that may yield more fat deployments unless you start to consider your application server's classloader hierarchy and take advantage of it to deploy 'shared libraries' either as plain POJO JARs, or as Java EE beans packed in JAR's. Anyhow, in the later cases, managing deployment dependencies becomes a concern which you will have to address at least at build time using frameworks like Maven indeed. Then, at run time you may have to script start/stop cascades according to dependencies; else, take advantage from specific application server extensions that address these dynamic deployment issues in Web and Java EE containers (e.g. Weblogic).
As already said, OSGI is now used by most application servers to manage their own start-up sequence. With the increasing complexity of platforms, multiplication of API's, increrase in the number of development teams to assemble a single final product, as well as use of numerous third party / open source components, OSGI becomes an indispensable server-start-up tool to ensure stable releases and a coherent set of compatible versions of all components. Think about the Eclipse IDE: with a catalogue of thousands of plug-ins and a high rate of new releases, this IDE would be a much brittle platform without OSGI as a base. Modern Application servers face just the same problem.
Based on above considerations, you may be much tempted to layer your code into some facilities which you could base into the OSGI layer, which in turn provides core services to a Java EE bean layer hosting business logic, and then a Web servlet layer to interface the whole... but two other questions pop up: (a) How do you make all these components communicate together? OSGI has its own repository mechanism and the deployed JAR's API's will not be visible by other modules unless explicitly published in OSGI. Web and Java EE containers use a completely different repository technology to access each-other components' interfaces, namely JNDI. Again, look at your specific application server documentation which may provide means to address Java EE beans from OSGI bundles and vice-versa (Glassfish for instance, since V3); but be cautious about thread management and transaction scopes. (b) How would you avoid interfering in the application server start-up sequence? OSGI tends to become a core system feature (under the vendor's governance), compared to the Web and Java EE containers naturally oriented to host your application code (under your governance). Upgrading your application server or installing a new release can interfere with your own OSGI deployments; you'll have to check the issue and organize your deployment scripts as a consequence.
The question is rich and its analysis is complex. Further consideration must take into account the nature of the application to build. Moreover, if you intend to use development frameworks like open source Spring and/or Camel, as well as vendor specific ones like Oracle Fusion SOA composites, JBoss Switchyard, etc. you will have many other technical constraints to take into consideration.
There is no "one-size-fits-all" answer in these matters and that, in essence, justifies the current plethora of overlapping technologies.
When that architecture question is first solved, then you can look to optimize productivity with a suitable configuration management and deployment repository.
We have many Spring web applications to make on a WebLogic server and are curious about when WARs should go in an EAR and when they should just exist as WARs. Occassionally, the WARs will need to access common logic JARs, but I don't see why these would need to go into an EAR when they could just be packaged into the WARs.
From what I understand, if several WARs are in an EAR and you need to modify one of those WARs, you need to redeploy the entire EAR to update the server. This will cause all of the WARs to bounce. If they weren't in an EAR, however, I could just update the one WAR and it would be the only one to bounce.
What's wrong with having 100 different WAR files standing alone and using packaged JARs and shared libraries (using WebLogic)?
Thank you for any insight!
If all you have is WAR files, then an EAR is of limited usefulness, serving only as a deployment container for your WARs. You can save a bit of bloat by sharing JARs between the WARs in this way, but that in itself is not hugely compelling.
EARs are essential, however, when dealing with full JavaEE/J2EE applications, which use WARs, EJBs, JMS, JCA resources, etc. The interactions and dependencies between the components of these sort of applications is vastly easier to manage in an EAR.
But if all you're using Weblogic for is a WAR container, then you might as well use a vanilla servlet container like Tomcat or Jetty, for all the functional use you get out of Weblogic.
I agree with almost all of skaffman's (typically) spot on comments.
If you're using Spring without EJBs you can stick with a WAR file, of course. No need for an EAR that I can see.
However, if your Spring app uses message-driven POJOs I can see where you'd still deploy a WAR file on WebLogic to take advantage of JMS.
An EAR might be necessary if you've got EJBs or JCA, but I wouldn't say that JMS mandates an EAR. I've used JMS and deployed a WAR file on WebLogic and it's worked just fine.
If you decide to go with Tomcat and deploy a WAR there, you can still keep JMS functionality if you use ActiveMQ.
The argument to package multiple WARs into an EAR can be compelling if you run into the situation that my last employer did, where you have a common set of library JARs that are used by multiple WARs, and the size of that collection of JARs is considerable. In our particular situation, the total size of 3 WARs with the common JARs packaged into each WAR totaled 124MB. By locating the JARs in the containing EAR and configuring the classpath of each WAR to use those JARs, the footprint of the EAR that contained the 3 WARs was reduced to 40MB. I'd consider that a compelling reason.
Having multiple shared libraries rather should not be the compelling reason to go for an EAR, as a JAR (or set of JARs) can always be deployed as "library" on weblogic which can, therefore, be shared by all the WARs. Isn' it right?
Nothing is actually wrong with just deploying wars, developers have an interest in getting tasks met quickly as possible. That means they often will take on technical debt, and if they are in a respectable team, they will clean that debt.
This however presents a problem, what happens when you avoid the complexity of EARs, and share a jar by adding it to the application server? Much more common in the war only team, is offloading all sorts of application complexity to the application server. Simply because it was easier to implement, in their often over-allocated schedule. I don't blame them for this at all, However now we have a new problem. A standard application server cannot be used, you must do system side customizations. Effectively the web application is bleeding all over the system. The person who maintains the Application server, now MUST also know application specific details... in an enterprise environment, this presents a very clear problem.
The developers can then take on system responsibility, but they still need to meet deadlines. They inevitably bleed all over the OS as well, and suddenly the developers are the only possible admins. If an admin doesn’t know what the application is using system side, they can very much cause major problems. These unclear lines always end in fingers pointing in both directions, unknown system states, and team isolation.
Do they have to use an EAR then? Nope, I'm a systems Engineer, so I always say they can deploy their own application server like another commercial application. Inside an RPM, if deploying a WAR is like other supported Application Servers, then they get the WAR deployment pipeline. If not, then RPM all in one... Once not allowing the team to externalize their costs, then EARs become a GREAT idea.