I need some pointers/suggestions on following scenario.
Scenario:
We are trying to use JDBCTemplate in CQ 5.5 for querying database (Oracle 11g). As first step we have integrated CQ with Spring Framework. Now for JDBCTemplate to work it requires JDBC driver that needs to be loaded separately into CQ as it is not available with Spring jars. The jar that is required is available here http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html and jar in my case is “ojdbc6.jar” that contains OracleDriver class (JavaDoc: *http://docs.oracle.com/cd/E11882_01/appdev.112/e13995/oracle/jdbc/OracleDriver.html*) required to register the driver to create connection with Database.
Problems/Suggestions required on following points:
As oracle 11g is commercial product so there is no repository available online for it (for pom dependencies), we need to create a separate local repository for it. (Need pointers; is there any other way to do it?)
Jar mentioned above is not OSGi. So how to approach in that case? (I have created OSGi bundle by following directions mentioned here http://cq-ops.tumblr.com/post/21893960212/how-to-turn-a-jdbc-driver-jar-into-an-osgi-bundle-jar)
In this process of converting this jar to OSGi Bundle I have to remove versions mentioned with Imported Packages in MANIFEST.MF file. (As I understand that CQ by-default picks the latest version that is available for any class, there may be problem when a new version of any class is available that is not compatible with current version. Need pointers; should this be looked into priority? Has anybody faced any issue due to this in any project)
Current Status:
By converting ojdbc5.jar to OSGi bundle; I was able to use JDBCTemplate. But looking for some pointers to check is there any other approach someone has followed in other project to achieve scenario mentioned above?
The oracle driver is not published to any public maven repo. So indeed you will have to put the jar into your own maven repo
In Apache Karaf there is a nice feature where you write wrap: in front of a bundle url and it automatically creates a bundle on the fly using the bnd tool.
If CQ does not have such a feature then you will have to create the bundle on your own. In this case the maven bundle plugin can help you. You can depend on the oracle jar using a maven dependency. Then you can define exports for the packages of the oracle jar. Bnd should then automatically inline the classes in you bundle jar. Another option is the maven shade plugin. You can take a look at the source of the servicemix bundles. There you find poms to bundle a lot of plain jars.
Not sure what exactly you mean. As far as I know the oracle driver does not have any external dependencies.
I have written a DB tutorial for Apache Karaf that explains how to deal with the oracle driver and how to create data sources without depending on the concrete driver.
The solutions in the tutorial can not be used 1:1 in CQ but it will surely give you some pointers.
Related
I'm currently starting with JFrog Artifactory. Up to now I have only been working with source code control systems not with binary repositories.
Can someone please tell how the versioning of files is done in Artifactory?
I have been trying to deploy a file, then change it and deploy it again.
The checksum has changed, so it's the new file. But it seems that the old version is gone.
So it looks like there are no version of files. If I want that do I have to do it in the filename?
I found versions related to packages.
But I was thinking to use it for other files as well.
Thanks for your help
Christoph
Artifactory, unlike a VCS system, is not managing a history of versions for a given path. When you deploy an artifacts over an existing artifact, it will overwrite it (you can block this by configuring the right permissions).
If you wish to manage permission for generic artifacts (ones which are not managed by a known package manager like npm, Maven etc.), there are a couple of options you can take:
Add the version as part of the artifact name, for example foo-1.0.0.zip
Add the version as part of the artifact path, for example /foo/1.0.0/foo.zip
Combine the 2 above approaches, for example /foo/1.0.0/foo-1.0.0.zip
Use an existing package management tool which is flexible enough to handle generic packages. Many people are using Maven to manage all types of packages beyond Java ones (it comes with its pros and cons)
From the Artifactory point of view there are a couple of capabilities you can leverage:
Generic repositories - aimed at managing proprietary packages which are not managed by a known package manager
Custom repository layout - can be used to define a custom layout for your generic repository and assist with tasks like automatic snapshot version cleanup
Properties - can be used to add version (and other) metadata to your artifacts which can used for searching, querying,resolution and more
Lastly, Conan is another option you should consider. Conan is a package manager intended for C and C++ packages. It is natively supported in Artifactory and can give you a more complete solution for managing your C libraries.
I have an application that is currently running on JBoss AS but does not work on Glassfish. I'm trying to work through the documentation here but I'm having trouble figuring out things like what the file structure of the application should be and what (if any) additional files are needed. This documentation also refers to examples but to get the examples you need to install Netbeans and access an update tool tied to the glassfish instance installed with Netbeans. When I do this the server won't start, the update tool won't run, and I can't get the examples. Is there an easy way to get these examples (e.g. a simple download)? I've found other examples such as this one, but they are also dependent upon Netbeans.
Is there a simple and complete ejb/servlet example for Glassfish that can be simply downloaded and does not depend upon Netbeans or other IDE?
The obvious example is the Java EE CargoTracker. It was written to show what a "real" application might look like with pure Java EE APIs so should work on both JBoss and GlassFish. You will need Maven installed to build and run it, but there are more complete details in the readme for the project. Note that some of the information is a little out of date (mostly links to java.net which has been sunset in favour of a GitHub site) but the application itself is still a good example of Java EE 7 APIs.
https://github.com/javaee/cargotracker
I found the examples on github here:
https://github.com/javaee/glassfish-samples
To get and build the examples you will need Git and Maven. These examples are small, complete, and concise. The example that was helpful for my particular problem was this example:
glassfish-samples\ws\javaee5\enterprise\servlet-stateless-ear
It demonstrated that I needed to change the structure of my project such that the servlet was in a .war file and not in a .jar file in the lib folder of my project.
In a Karaf features file if I include certain bundles then Karaf stops working correctly.
How can I know what bundles I should not include in a features file? for example, if I added these bundles in the features file in Karaf on Windows, Karaf is not happy and acts strange. I assume its because Karaf already provides Java interfaces for these bundles.
<bundle>mvn:org.osgi/org.osgi.core/4.3.1</bundle>
<bundle>mvn:org.osgi/org.osgi.compendium/5.0.0</bundle>
Also is there a programmatic way to determine this?
Is there a list of bundles which I should not include?
I understand that Karaf uses pax-logging rather than those slf4j.
In more detail, my SBT project compiles a list of dependent bundles for my bundle, in my list that I get back from my code I get the org.osgi.core and org.osgi.compendium. They are dependents of my osgi bundle which is my main project. Now, the problem is, how can I know that Karaf does not want this installed as part of my features?
Thou' shall not install other framework packages besides the framework ;)
This is an absolut NOGO!
As Karaf already provides everything you need, in that case the Framework.
So don't even think about adding the std. framework packages to your OSGi env, they are already all there.
If you want to have certain compendium packages.
Make sure you Install the implementing bundle, as you already pointed out, the pax-logging bundles already provide everything needed for the osgi logging compendium services.
Same is true for Pax-Web and the OSGi HttpService packages.
You'll find a lot of already pre-registered OSGi compendium services with Karaf,
if you need more, install the implementation, not the spec bundle.
edit
nop programmatic or Karaf internal way can tell you about to not include those bundles. It's just something commonly known.
An implementing bundle always also will bring you the needed osgi packages.
It may be pretty basic question. But no luck Googling.
I was going through this URL. Because I had an issue accessing EJBs deployed on JBoss. After following this, it worked. Mainly this line.
jboss-ejb3-client.jar, jboss-aop-jdk50-client.jar, jboss-aspect-jdk50-client.jar and jbossall-client.jar -
all these .jar files are found in client folder of JBoss installation directory
But for a newbie of EJBs like me, this is following the steps without understanding the dependencies. So my question, can we find documentation like this somewhere? How do we know the jars we need to copy to client application classpath?
jbossall-client.jar for JBoss 4.X is enough - it contains all needed libraries.
For JBoss 5.X the story is more difficult - you need to reference in your project only jbossall-client.jar, but inside this JAR there are no actual classes, only MANIFEST file, which lists needed dependencies.
So, on JBoss 5, you need to have jbossall-client.jar added to classpath of your client plus all listed JARs lying next to it. Crazy, isnt't it?
JBoss 7 has sane approach. There is bin\client\jboss-client.jar that contains all dependencies needed by clients.
So i received a java api from a client and the main code is in main.jar. But the instructions he gave me require me to add these other jars (a.jar, b.jar, etc..) into the classpath whenever I want to use main.jar. These other supporting jars are things like Xerces, jakarta-oro, and a few other publicly available libraries. The problem is i don't know what versions they are, so i'm not sure if there would be issues if i just update the pom.xml file in my app to depend on main.jar and also have dependencies to these other jars as well with the latest versions of them.
Whats the best strategy for using main.jar in my maven application? I'm planning on adding main.jar to our internal maven repository, but what should i do about the xerces, jakarta-oro, and other jars when i dont know what versions they are?
Thanks
If you are lucky the file /META-INF/MANIFEST.MF inside a.jar, b.jar etc. contains an entry "Implementation-Version" or some other useful information which tell you what version they are. If not, you can download the latest release(s) from the project web site and check if they have the same file size as your bundled dependencies.
You may also come to the idea to bundle the dependencies with the main.jar in one big jar, but this may become funny, when you have the dependencies twice in your classpath at some point in the future...
What about just asking the client what version numbers this dependencies have?
If you don't have any information about these third-party libraries, just add them to src/resources/META-INF/lib and commit to SVN. That's the best way, if we're talking about black box approach.