I am working on one of many modules in an OSGi based Java/Spring application.
The case I am dealing with is, on the face of it, rather simple - I need to make use of external jars by including a dependency into my local module maven pom file.
The problem I am facing is that as soon as the module is compiled and run, with the new dependencies sucked in, and hot deployed onto a local multi-module supporting Apache Felix server I see no SOAP web services defined within that particular module getting started.
Confusingly, it appears the same dependency used elsewhere (in a similar component, that is) does not bring about any problems and compiles/runs just fine.
Am I missing something fundamental in the way Maven/OSGi works or is it that there is some sort of a more serious issue at play here?
The images below should further illuminate the problem at hand.
It must be noted, though, that the following images have been purposefully modified as it has been assumed the kinds of jars added have no bearing on the way the deployment responds (for what it's worth, it is an external library providing hashing algorithms).
Before adding dependency running localhost:8080/cxf displays
Rerunning after including the above dependency causes it to not show anymore
Any insight would be hugely appreciated!
Related
I am coding a java web app.
When I started, every time I needed to use an external package, I would download the jars manually and download all dependencies of each jar manually and place them in the libraries folder (in Netbeans).
As time went on, I started using a dependency manager (Ant).
Now, I would like to use my dependency manager for all of my external libraries.
If, after executing this change I run my application and it successfully deploys (no ClassNotFoundExceptions and no NoClassDefFoundErrors), is it safe to assume that I have not missed anything and that my application will run smoothly as far as the external packages go?
Or, do I need to individually test out each functionality in my web app to confirm that the changes I made to the libraries didn't change how the application runs?
It's actually depends on the code inside these libraries. Only part of classes are loaded at startup, thus you can miss something. Also there might be a possibility that you're loading some classes in runtime manually, i.e. Class.forName(String) and this code has not been triggered at startup. Thus, I would say you can't be 100% sure.
Generally in Java here are 3 build approaches:
Imperative - you're saying "How to assembly your code". The typical example of this is Apache Ant.
Declarative - you're saying "Which code you want to assembly". The typical example of this is Apache Maven
Mixed - which takes benefits of previous systems. This is Gradle.
How it helps!
I'm trying to build a simple REST service to learn OSGI. I am using Spark Servlet to handle the requests.
I embedded spark core as a dependency, built my project in maven and got a wiring package error in Karaf upon deployment.
It seems like I follow package after package, one by one to resolve each error and it takes about 2 hours just to resolve the dependencies. Clearly I'm doing something wrong..
How should I go about doing this so I can use spark servlet?
The primary idea of OSGi is to create reusable modules. Massive transitive dependencies indicate that someone did not get the message.
If you find yourself in your situation then it is an indication you're in a mess. Now, plenty of people clearly live in that mess because they're oblivious of a better world, where you get reuse and things work out of the box.
A simple rule is that on the application parts (which should be really small) you can use whatever you want since it will never be reused. However, I would go out of my way to limit dependencies on libraries that have transitive dependencies because, imho, they always cause more problems in the long run then that they deliver in the short run.
Using OSGi with large transitive dependencies is paying a lot of money and not getting any benefits.
I just started to develop a java web application based on the ninjaframework. Everything works great, but: With all the ninja-dependencies, the deploy-war has around 25MB. I really hope, I won't have to upload a 25MB java archive all the time - especially due to the fact, that the dependencies won't barely change as often as e.g. a stylesheet of my app.
Is there a practical solution to move the ninjaframework-dependencies to a separated jar? I am working with eclipse, therefore a solution that integrates in the IDE would be great.
So far, I have had a look into the maven dependency-scoping and have (unsuccessfully) tried to move the dependencies into a separated project and refer to the project with a system-scoped dependency (which I would in my understanding be able to deploy as a separated jar file). I currently fail at building this dependency-jar with maven - but I also wonder, if there are better approaches.
I deploy the application on a tomcat-server in a plesk installation
Another option would be to exclude libraries that you don't use. For instance if you don't use JPA you can safely exclude it from the build via Maven's xml tag.
Background: Ninja 4 potentially bundles too many libraries by default. That's cool, because everything will work out of the box without thinking about libraries needed. The downside is that the jar/war may be too big for what you want to do. There are discussions on the way to make Ninja more modular - feel free to chime in on our mailing list :)
But as written above - you can cut Ninja's bundle down yourself using Maven's exclude.
If you have to use all the dependencies, there is no way to avoid deploying them with your application.
You don't tell if you are deploying into a container (maybe Tomcat). If you do, you can try to deploy the needed libraries into the container and set the Maven scope to provided to avoid redeploying the libraries.
Having the libraries provided by the container has benefits, but it can also be a burden. Depends strongly on your deployment and operation processes.
I need advice on how to structure a multi-tier GWT/Spring project so that Gradle can build the artifacts and deploy the correct jars..
Google hasn’t helped much – I can find a number of articles on building multi-projects and indeed building GWT project in Gradle however, all of these seem incomplete for my problem domain as I’m finding the following problems as I have encountered the following issues.
In the multi-project examples, the GWT dependencies are being included in the web-application from the war plug-in.
If I go down the single gradle build route then I’m losing decoupling with the projects..
Both the client & Server have dependencies on certain class files (for GWT-RPC); currently these are packaged in the client project so has resulted, again, in a server dependency on the client (for the GWT-RPC DTO objects).. This leads me to feel I need a third module exclusively for the shared class files with the source being also present in the gwt-client project (for the GWT compiler to pick these up)..
So; the question is has anyone came across a multi-tier GWT examples that uses Gradle as the build tool & deals with some/all of the above issues?
Thanks in advance,
Ian.
We're using a single build, but we address point #2 - "coupling of projects" using the Classcycle maven dependency plugin.
Ultimately, you want three genres of code: server, client and shared. The advantage of packaging those separately in separate jars (as you said in point #3) is that your server jar size will be decreased, and you could use more liberal source directories in your .gwt.xml file.
If you decide to use a single jar/war, then you will be including the extra, unused client classes on the server. This could lead to runtime exceptions from code leakage and (potentially?) worse performance on the server. We avoid the runtime exceptions by enforcing the layering separation at build time (using Classcycle), and the extra performance overhead from the extra client classes should be marginal. You can always strip out the client code from the jar after compile, using a post-build task.
Sorry, I don't know much about gradle, but I figured I would try to help anyways.
We are building a small application using different architectural layers such as domain, interface, infrastructure and application. This follows the Onion DDD model. Now I am wondering if there is any benefit in splitting the application into a multimodule maven project. As far as I can see now it seems to make things more difficult than needed. The entire application will be deployed as a single WAR file into a Tomcat container.
Splitting your application makes sense for the following:
When a certain part of the project needs to have new functionality or bug fixes, you can simply focus on that module and run just the tests for it. Compiling a fraction of all the code and running just the related tests speeds up your work.
You can re-use the code from the modules across different projects. Let's assume your project contains some well-written generic-enough code for mail sending. If you later have another project that need mail sending functionality, you can simply re-use your existing module or build upon it (in another module by adding it as a dependency).
Easier maintainability on the long run. Maybe now it seems like a small project. In a few months things might look different and then you'll need to do more refactoring to split things into logical units (modules).
Conceptual clarity (as added by Adriaan Koster).
Concerning the WAR: You can have an assembly module which puts things together and produces a final WAR file from all the related modules.
Initially, this may seem as more work, but in the long-run, modularized projects are easier to work with and to maintain. Most sane developers would prefer this approach.
Using multiple modules forces you to have a hierarchy of dependencies. You have one module which is standalone and doesn't depend on any other of your modules. You have another which only depends on that. It might appear harder than allowing anything to depend on anything else but this approach results in a mess of dependencies which is hard to fix later.
If you are trying to follow a layered model I suggest you place each layer in a different module. This will ensure you are not tempted to break the model.
Short answer: today it is small, tomorrow it will bigger and more complicated to maintain, reuse, extend, integrate with other system and so on
As far as I know, Maven do little help for WAR dependencies. As you are talking about single WAR, this should never be a problem.
You can separate java classes into several "jar" submodules, but if you split the WAR project into several smaller WARs, using some kind of "overlapped" packaging things get complicated.
Just information, one of our projects, it contains too many web pages, so we decided to split it into several WAR submodules, however, the session is not shared between different WARs deployed, and we are not going to use Kerberos stuff. At last, we modified a lot sources of Glassfish, Jetty, MyFaces, etc. To make them resolve web.xml stuff inside JARs. And converted the whole project to Facelets 2.0 (to avoid the dependency of JDK tools.jar and custom resource handler), the only reason is to change the WAR submodules to JAR submodules, and move all webapp/pages into class resources. So the conclusion, Maven does great job for JAR dependencies, but no WAR or single WAR.
EDIT You can put applicationContext.xml in one of the base submodule, and import it by classpath:com/example/applicationContext.xml. Also Spring 3.0 do have annotation supports, you can make spring auto scan them instead of declaring them all in the xml.
Spliting your project into multiple maven projects is useful if you want to reuse your classes in another project or if your projects are deployed in different configurations.
Maybe think of a webservice - if you are hosting the server, you could build a project for your domain classes (models) and your endpoint interfaces that could be used by server and client. The server would be another project that is build to a WAR.
To develop further clients the first project could be used, too.
Use a parent project for dependency management on common projects (like logging) and different profiles and build configurations.