I haven't found a Maven plugin or target that will package my app and deploy it to Glassfish without error. I get this exception:
[ERROR] com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while preparing the app : java.lang.RuntimeException: Could not resolve a persistence unit corresponding to the persistence-unit-ref-name [org.us.impl.MyClass/entityManagerFactory] in scope of the module called [man-java-really-stinks-app]. Please verify your application.
This isn't a Spring/Hibernate/EntityManagerFactory/Jpa problem. The app runs fine in the embedded Maven Glassfish container.
I changed packaging to ear in my pom.xml and got this when I deployed to Glassfish
Error during deployment : org.xml.sax.SAXParseException: The content of element type "application" is incomplete, it must match "(icon?,display-name,description?,module+,security-role*)".
IS there a plugin that will take care of the J2EE packaging requirements?
Bonus question: Since the Entities (just POJOS!) and the application need to be packaged differently, is it best to separate these into Maven sub-projects?
I haven't found a Maven plugin or target that will package my app and deploy it to Glassfish without error.
For the packaging, there is everything you need: the maven-jar-plugin for JARs (including JARs packaging JPA entities), the maven-war-plugin for WARs, the maven-ejb-plugin for EJB-JARs, the maven-ear-plugin for EARs, the maven-rar-plugin for resource adapters.
This isn't a Spring/Hibernate/EntityManagerFactory/Jpa problem. The app runs fine in the embedded Maven Glassfish container.
Well, I'm still tempted to say that there is a JPA configuration problem somewhere anyway, the container is clearly failing at finding a (default?) persistence unit. But since I have no idea of the kind of app you're running (I guess it's a webapp but would like to get confirmation), what your persistence.xml looks like, how you inject the EntityManager, how you configured the database access, how you configured Spring, the version of GlassFish you're running, etc, etc, it will be hard to say anything more.
I changed packaging to ear in my pom.xml and got this when I deployed to Glassfish
That's not that easy. Building an EAR typically involves a multi-modules build, and you are expected to provide a special deployment descriptor. But I'm not convinced you need an EAR packaging and if you can avoid it, don't use it.
IS there a plugin that will take care of the J2EE packaging requirements?
As I said, there are plugins for everything you need, from J2EE to Java EE 6. Just provide the details requested above.
Bonus question: Since the Entities (just POJOS!) and the application need to be packaged differently, is it best to separate these into Maven sub-projects?
Entities and the application do NOT (always) need to be packaged differently, you can package entities directly inside a WAR (I'm extrapolating but I suspect this is your case). I just think you have a configuration problem somewhere, even if the application is running in GF Embedded.
By the way, almost Everything is POJO in Java EE (Entities, Session Beans, Message Driven Beans, etc), but there is no direct consequence on packaging, packaging and POJOness are unrelated.
org.us.impl.MyClass had a #PersistenceUnit annotation. The persistince is managed by Spring, but Glassfish takes a sweep of the annotation classes and tries to resolve it itself. You can tell Glassfish to knock it off by adding
metadata-complete="true"
to your web.xml, like so
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
metadata-complete="true">
Further reading: https://glassfish.dev.java.net/issues/show_bug.cgi?id=4204
Related
I'm having an EAR project, consisting from 3 modules/projects: WEB, EJB and JPA. In WEB project, i have added log4j2 for logging. Therefore i've putted log4j2.xml file into WebContent/WEB-INF/ direcotry.
Now, i have made two projects out of one: the developer version and the test version. The differs mainly in project name. They also have different file location configured in log4j2.xml file, to which to write logs.
When i deploy only one project (for instance developer version), everything works fine. However, when im deploying both projects, then, both of them are logging to the same file (it is always the file configured in log4j2 from the project that was deployed first).
My Glassfish version is 3.1.2.2 and Log4j2 version is 2.0.2.
Does any one konws how to solve it?
The log4j2 manual has details on configuration for web applications.
Are the log4j2 jar files also in the WebProject1/WEB-INF/lib and WebProject2/WEB-INF/lib folders (and not in some shared location)? That way the log4j2 classes will be loaded by separate webapp class loaders and they can have separate configurations.
I' starting to use ServiceMix and Camel and I've run through many examples.
It seems that the examples that are OSGi can be deployed in ServiceMix via hot deploy or via console, but I don't know how to deploy a project that is not an OSGI. Can it be done?
For example, I'm looking at the example project from Camel 2.10.0 called camel-example-cxf-proxy. I did some alterations and now I wanted to load it in ServiceMix. If I copy/paste to the deploy directory it is loaded but when I try to run it via osgi:start id it fails.
However if I run it from the IDE as a standalone it runs just fine and I can send and receive requests via SoapUI.
When I'm done with the examples I'll want to create my own project in eclipse and do tests in the IDE and in ServiceMix. I don't really understand the advantage of OSGi yet. SO I'm not too compelled to use OSGi for my project.
My main question is: Can I deploy a non-OSGi non-JBI compliant project in servicemix? Something like the camel-example-cxf-proxy. If yes, how can I do it? If no, how can I OSGi-fy the camel-example-cxf-proxy?
Thank you :)
Apache ServiceMix which uses Apache Karaf as its kernel, support pluggable deployment units. Though OSGi is the main unit.
You can deploy JBI artifacts (eg JBI was used as deployment units for Apache ServiceMix 3.x). So we offer that as a migration path to run JBI in SMX 4.x.
A plain WAR file can be deployed as well. You can for example just drop a .war file in the deploy directory. If you deploy from the shell, you need to prefix the deployer with war so it knows to use the war deployer.
There is some documentation about the various pluggable deployers here
http://fusesource.com/docs/esbent/7.0/esb_deploy_osgi/UrlHandlers.html
For example to install an Apache Wicket WAR example using Maven you can do from the shell:
osgi:install war:mvn:org.apache.wicket/wicket-examples/1.4.7/war?Web-ContextPath=wicket
The Apache documentation about deployer is mainly documented at Apache Karaf
http://karaf.apache.org/manual/2.2.9/users-guide/deployer.html
Now to deploy OSGi applications can be a bit of pain to assemble. And that is why FuseSource created FAB to make it much easier. I blogged about this a bit, which references to videos and more material: http://www.davsclaus.com/2012/08/osgi-deployment-made-easy-with-fab.html
With FAB you can just deploy regular Maven projects out of the box without any OSGi pain.
If your project is a maven project, you can try :
mvn install
Then start your servicemix, and in servicemix command line :
install mvn:groupId/artifactId/version
This will prompt a bundle ID. Then, juste start the bundle :
start <bundle_id>
You can check the state of your bundle with command "list"
The project has to be a bundle to be installed in servicemix / karaf. So the steps to make a camel project work in OSGi are the following.
Use the maven bundle plugin in the pom and configure it to import / export the necessary packages if necessary.
Make sure your camel context is defined in a way that OSGi can start. This is either in the activator of the bundle or in a spring config in the right location or with a blueprint config in the right location.
See two of my karaf tutorials for the details:
CXF: http://www.liquid-reality.de/x/EoBk
Camel: http://www.liquid-reality.de/x/G4Bk
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
I'm in the process of porting several J2EE projects from Ant to Maven2. All of these projects contain 1 EJB and 1 web module, and use the recommended "skinny" EAR packaging method. This means that the JARs that the EJB and/or web modules depend on are all just put in the root of the EAR. Both EJB and web modules have Class-Path entries in their respective manifests to reference the specific JARs, plus the web module Class-Path will also reference the EJB jar.
I was horrified (is that too strong? :)) to find that Maven doesn't support this very well. I read the official page on handling skinny WARs, but that meant I had to duplicate the WAR dependencies in the EAR pom and, even worse, also the transitive dependencies. It seems pointless to adopt Maven if you have to manually handle dependencies anywhere!
I then starting Googling and found a variety of workarounds - obviously, I'm not the first person to (a) want to do a skinny EAR and (b) don't like the Maven suggested approach (which is itself a workaround).
I tried some of these approaches, but none of them worked for me. I also found some issues that looked like Maven bugs, e.g. the WAR plugin 'packagingExcludes' directive excludes only the direct dependencies, not any transitive ones! Not very confidence inspiring. I found a JIRA issue for this specific one, but it's still open.
I then found that my command-line Maven 2.2.1 does things differently to my m2eclipse embedded Maven (Embedder v. 3.0). Our developers would definitely want to drive Maven from Eclipse, so relying on the latest command-line version was not an option.
So, my question is: right now, and for the forseeable future, is it worth migrating to Maven if we do all our development in Eclipse, and work mostly on skinny EAR projects? Is there anything in Maven's future that would make it handle EARs in a more robust and integrated way?
So, my question is: right now, and for
the forseeable future, is it worth
migrating to Maven if we do all our
development in Eclipse, and work
mostly on skinny EAR projects? Is
there anything in Maven's future that
would make it handle EARs in a more
robust and integrated way?
Short story: No, not while M2Eclipse remains broken.
Long story:
Currently, I would recommend against it, at least in Eclipse. At the time of writing the M2Eclipse plugin has and always has had a very nasty bug where it generates its own version of the application.xml descriptor file rather than use the one Maven would otherwise create.
Unfortunately, this custom-created application.xml is downright wrong: it ignores finalNames, has an apparently hardcoded "lib/" prefix and assigns EJB JARs the extension ".ejb" for some reason. What's worse, you cannot remove it to be replaced with Maven's version as it keeps getting regenerated by M2Eclipse.
Maven will only generate application.xml if it's not already in place. Because the WTP/M2Eclipse-generated application.xml keeps getting regenerated, the Maven application.xml doesn't get a chance.
There is a workaround for this problem, however: you can tell Maven to ignore the application.xml during packaging so that it thinks application.xml is not there, in which case it will still generate its own version. That way, the wrongly-generated application.xml file wouldn't matter. For future reference:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<version>5</version>
<earSourceExcludes>**/application.xml</earSourceExcludes>
<generateApplicationXml>true</generateApplicationXml>
</configuration>
</plugin>
One major problem though is that the Ant script used for deployment to GlassFish in Eclipse generates its own separate EAR for deployment, and uses the M2Eclipse-generated application.xml for doing so. That means the EARs it generates will always be wrong as long as the M2Eclipse plugin remains broken. There are bug reports for this on the codehaus JIRA, can't access them right now though.
YMMV for other application servers, but be prepared for heavy fiddling with application.xml.
Unfortunately, this custom-created application.xml is downright wrong: it ignores finalNames, has an apparently hardcoded "lib/" prefix and assigns EJB JARs the extension ".ejb" for some reason. What's worse, you cannot remove it to be replaced with Maven's version as it keeps getting regenerated by M2Eclipse.
Are you really sure it's m2eclipse doing this? I'm using JBoss Tools 3.1 which includes m2eclipse integration and get exactly the problem you're stating. However, I don't see the rationale for m2eclipse to care at all about the source application.xml.
My suspicion is that JBoss Tools injects information into the application.xml. Please prove I'm wrong, I'd stop using m2eclipse forever fi it changed anything that's not under /target.
//GG
I was horrified (is that too strong? :)) to find that Maven doesn't support this very well (...)
Indeed, Maven doesn't support skinny WARs (see also the Solving the Skinny Wars problem wiki page) very well because this was just not planned from the start and Maven assumes fat WARs. So the way to build skinny WARs and skinny EARs is indeed more a workarounds built on top of existing plugins. And, yes, this is error prone.
(...) I then found that my command-line Maven 2.2.1 does things differently to my m2eclipse embedded Maven (Embedder v. 3.0).
Note that you can configure m2eclipse to use an external Maven instead of the embedded Maven. This is actually what I do, I want exactly the same version that the CI engine uses.
So, my question is: right now, and for the forseeable future, is it worth migrating to Maven if we do all our development in Eclipse, and work mostly on skinny EAR projects?
My advice is simple: if Maven doesn't support the way you want to build software (legitimate or not, that's not the question), don't use it.
My shop has been running Oracle's Application Server for several years. As such, before we knew better, we have developed a norm of having application config files stored outside of the WAR file and the app-specific config directory is added to each application using an Oracle-specific deployment descriptor. This deployment descriptor allows us to add classpath elements at the application layer rather than having to include all dependencies in the WAR.
Now we are faced with upgrading to WebLogic 10.3 and I need to find an alternative for our applications that depend on external configs.
Is there a way in WebLogic to add external jars or directories to the classloader at the application level? I've found ways to add them to the system classloader, but I'd prefer to add them to the application level to avoid having to re-work the applications beyond modifying deployment descriptors.
Is such a thing possible in WebLogic 10?
After further research, we've learned about WebLogic's Generic File Loading Overrides feature.
This feature allows us to use a Deployment Plan for our application and specify a "config-root" for the application. Within the config-root, we can create a directory called "AppFileOverrides" and override any file in the WEB-INF/classes or WEB-INF/lib directories.
This feature works by injecting a classloader just in front of the Web Application classloader, thus any resource loaded from the classpath will be found in this classloader before anything bundled into the web application archive.
Using this feature, we are able to add configuration files (and in theory, classes) that don't exist in the war file at all. Thus, we are able to mimic the functionality of keeping configuration files outside the war.
Moving forward, I'm encouraging our developers to include the configurations inside the war file, but this will work nicely for legacy apps and for situations where we need to change the configuration for a given deployment target (dev vs production)
External jars can be referenced by deployments using the shared libraries.
Roughly, the external jars should be 'deployed' as libraries. Then they can be referenced from your app's weblogic-application.xml using library-ref descriptors.
refer to this doc.
Though, I dont think you can provide external directories/config files other than by using system classpath.
To my knowledge, this is not possible with Weblogic. External configuration files need indeed to be added to the system classpath. You can tweak a bit the classloader (see filtering and loading order) but there is nothing allowing to add dependencies at the "application level" a la OAS. For this, you'll have to run separated domains if the scenario mentioned above is not an option.
I'm building my application to run in an OSGi container. I use Maven and the Maven Bundle Plugin from Apache Felix to set up the OSGi manifests for my own modules and that works great.
Now, I'm deploying my bundles into an OSGi container together with several 3rd party libraries. Some of these are already OSGi-fied when I get them from the Maven repos, others, I want to convert into OSGi-compatible jars. I want to set up a Maven project that collects all dependencies, and puts each in its own OSGi jar. The ultimate goal is to collect these jars and my own into an assembly that I can use as a standalone deployment package.
I know how to convert standard jars to OSGi jars, and I have a (somewhat hackish) approach to merge multiple OSGi bundles, even if I probably shouldn't. But if I have a dependency that's already fine as it is, and I just want to copy it from the repo into my assembly, what part of Maven do I use? The bundle plugin is wrong, it messes up the manifests if a dependency is already OSGi-compatible. Do I use the dependency-plugin, the assembly plugin or something else?
I have the feeling I'm overlooking something very simple here.
Did you have a look at the PAX tools? In particular Pax-Runner and
pax-construct... They do not only give you a nice template to start with, but also solve most the problems you mentioned for free.
We use many libraries which are not OSGified by the vendor and which are not available on the Spring bundle repository. We also have many of these and want to deploy them all together hassle free. For this we have created a 2-layer maven setup:
Individual maven projects that either download or contain (as 'system' scope depends) the 3rd party lib in question, and OSGify these using the Apache Felix bundle plugin
One container project that has a dependency on all of these small projects and makes an assembly of them using the core assembly maven plugin. This POM also uses the copy-dependencies goal of maven to make sure everything is in place.
Once it is turned into an assembly (ours is a tar file) we deploy this to our servers. We have gone one step further and used this assembly of 3rd party libraries as the Target Platform for our Eclipse build environment. But this may be irrelevant for you.
You can get OSGi friendly versions of many common artifacts from the Spring bundle repository. So you may not have to do it yourself.
See details of how to configure the bundle repository for Maven.
(will update with some ideas for those that aren't available as bundles already)