An osgi bundle in my application which runs inside fuse esb required pgp encryption provided by bouncycastle. Bouncycastle provider should not have an impact with other applications bundles / fuse esb functionality. Since bouncycastle is not an OSGI jar, how it can be added to fuse ESB environment ?
I repackaged bouncycastle jar as an OSGI jar but it gives the signature error. I copied the jar to JDK security directory but my application bundle does not start saying bouncycastle classes not found. Same with copying to karaf external library directory.
You didn't specify the version of Fuse ESB (then called JBoss Fuse, now called Red Hat Fuse). I used Fuse 7.6.
I checked trivial pgp example and all I needed was to add bcpg-jdk15on-164.jar to $FUSE_HOME/lib/ext - this directory already contains bcpkix and bcprov libraries. OpenPGP support is however provided from bcpg library.
From OSGi point of view, you just need proper imports (or dynamic imports). No need to install any bundles, because everything is configured in $FUSE_HOME/etc/config.properties:
org.osgi.framework.bootdelegation = \
...
sun.*, \
org.bouncycastle, \
org.bouncycastle.*, \
...
If you're using JBoss Fuse 6.x, it's the same. Just $FUSE_HOME/lib/ext contains only bcprov-jdk15on.jar.
1) Add bouncycastle jar files to lib/ext
2) Add bouncycastle packages to bootdelegation in etc/config.properties ( as above first answer)
3) Explicitly remove bouncycastle packages from imports section of maven-bundle-plugin
<Import-Package>
!org.bouncycastle.jce.*,
!org.bouncycastle.bcpg.*,
!org.bouncycastle.openpgp.*,
!org.bouncycastle.openpgp.operator.*,
!org.bouncycastle.openpgp.operator.bc.*,
!org.bouncycastle.openpgp.operator.jcajce.*,
*
</Import-Package>
4) Import those packages in dynamic import section
Related
I have a JSF app running on embedded jetty. It works when I run it from eclipse but not from command line. I realised it was because eclipse uses the folders and cli uses the jar. I assumed, after googling, it was because my jar was missing a faces-config.xml. I added one in the META-INF folder but I'm still getting Target unreachable errors for the beans in my xhtml.
How can I check that JSF is in fact scanning my jar for #ManagedBean?
Ps. I build my projects' jar with maven, copy it to my lib folder then run it from cli with java -cp "lib\*" com.test.MainSystem
After debugging AnnotationConfiguration I could see that Jetty only scans jars under WEB-INF.
Fortunately, they provide a method for adding external jars. Adding this got me up and running...
WebAppContext webapp = new WebAppContext();
// Add "this" jar to the list of jars to scan for annotations
String jarPath = JettyServer.class.getProtectionDomain().getCodeSource().getLocation().getPath();
webapp.setExtraClasspath(jarPath);
I've been transitioning a portlet from Liferay 6.2 to a bundle for Liferay 7. When I deploy it, it can't load, because of a missing resource:
$ blade sh diag 1084
diag 1084
org.mycompany.caasd.portal-ldap-sync [1084]
Unresolved requirement: Import-Package: com.liferay.portal.kernel.service;
version="[1.20.0,2.0.0)"
When I use Felix Gogo shell to see what's available, I don't see any kernel bundles. Is that a bundle I should be expecting to be installed, install myself, include in my bundle, or am I just not thinking about this the right way?
The com.liferay.portal.kernel version for CE GA4 is 2.32.1. So if you were developing for CEGA4, with a gradle project, you'd configure the dependency in your project's build.gradle like this:
dependencies {
compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel", version: "2.32.1"
}
You can find this by looking in the portal-kernel.jar file's MANIFEST/MANIFEST.MF or if you have the liferay src for your version, in any of its own modules build.gradle files. In my tomcat bundle, the portal-kernel.jar if in tomcat/lib/ext.
Unless I've misunderstood your question, that should get you what you want.
See the docs here for more information
When you build your bundle, bnd will either
inspect your classpath and detect the package versions for you
use whatever versions you manually provide in Import-Package
In your case, it seams it somehow detected that the version of com.liferay.portal.kernel.service package is 1.20.0. It therefore generated the range "equal to or greater than current version but lower than next major version" which in your case is expressed as [1.20.0,2.0.0). That may have been because you had old jar on claspath or behacause you had wrong Import-Package statement.
This may compile just fine as long as you are nor using functionality that was added/changed in the newer version. At runtime though, the actual package version is higher (something like 2.32.1) and therefore it does not meet your requirement. As OSGi runtime can not resolve your bundle requirement, the bundle is left in "istalled" state!
To solve that you have two options:
install your bundle on older Liferay version (where com.liferay.portal.kernel.service package is between 1.20.0 and 2.0.0)
recompile your bundle making sure the classpath contains only those jars in which com.liferay.portal.kernel.service package has version that will generate a version range in which you runtime package version fits.
we have a command in apache felix to install an OSGi bundle i.e "felix:install Jar-file". My query is :Does this command also perform verification(before installing) of contents of jar-file against the signature with which it was signed earliar?
Or do we have any specific command in Apache felix to do the same.
If any above command does not perform verification then do i have to use
"jarsigner -verify jar-file" command provided by jarsigner tool in OSGi framework? if yes then how?
Or
do i have to write/embed some code/API in my own bundle code for verification which might run after installation and before resolving any the bundle's dependencies?if yes then what are those APIs provided by OSGi framework or some OSGi container implementaions(like Apache felix, Apache Ace, Equinox etc)?
Or does it require any configuration to set in OSGi bundle, specifically for signature verification?
please do share your some views.
Thanks
I am struggling around a wrong usage of composer, for sure.
I set up this repository: https://github.com/alle/assets-merger
I forked the project and was just trying to make it a kohana-module, including all the dependencies.
As for it would need the YUI comporess JAR, I was trying to make just that JARfile as a dependency, and I ended to declare it in the composer.json file (please, look at this).
Once I need to add my new package to a project I add it in the require section as follows:
...
"alle/assets-merger": "dev-master",
...
But the (latest) composer update command says:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for alle/assets-merger dev-develop -> satisfiable by alle/assets-merger[dev-develop].
- alle/assets-merger dev-develop requires yui/yuicompressor 2.4.8 -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
And my story ends here.
How should I configure my composer.json in the https://github.com/alle/assets-merger repository, in order to include it as a fully satisfied kohana-module in other projects?
Some things I notice in your composer.json.
There is a version of that CSS minify available on Packagist which says it is just a copy of the original Goole-Code hosted files, but with Composer: natxet/cssmin. It is version 3.0.2, but I think that shouldn't make a difference.
mrclay/minify is included twice in the packages with the same version. It also is available on Packagist. You will probably already use that (version 2.2.0 is registered, and because you didn't turn of Packagist access, it will be generally available for install unless a version requirement or conflict prevents it).
You are trying to download a JAR file (which is a java executable without and PHP), but try to get PHP classmaps out of it. That will fail for sure.
You did miss the big note in the Composer documentation saying that Composer cannot resolve repositories mentioned in sub packages, only in the root package. That means that whatever you mention in your alle/asset-merger package will not be used if you use that package anywhere else. You'd have to duplicate these repositories in every package in addition to adding the package name itself as "required".
What this means is that you probably avoided missing mrclay/minify because it is available on Packagist, you might as well have added the cssmin by accident, but you definitly did not add YUICompressor.
But you shouldn't add this in the first place, because it is no PHP software. You can however add post-install commands to your projects. All your Composer integration does is download the JAR file. You can do that with a post-install or post-update command. See the documentation here.
I am working on a JSF taglib. To test it I compile it to a JAR as described here and add it manually to a Dynamic Web Project (In the WEB-INF/lib directory).
I know that this step can be automated, but I do not know how. Can anybody explain how to copy a generated jar to a second project in Eclipse?
Thanks in advance!
quite some steps to do :)
add a pom.xml into your project and follow the maven directory structure. use packaging "jar" for the taglib project. Lets assume you use groupId=com.company.taglib artifactId=company-taglib version=1.0.0-SNAPSHOT
if you do a mvn install on this project it will copy the jar into your local maven repository (usually found at ~/.m2/ - now maven can resolve the dependency on your local machine
add a pom.xml to your webproject, use packaging "war" and add the taglib project as a dependency (within <dependencies> in pom.xml).
<dependency>
<groupId>com.company.taglib</groupId>
<artifactId>company-taglib</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
Maven will resolve this dependency from your local repository. In Eclipse using the m2e Plugin it will resolve the project directly.
To "publish" the taglib.jar you need an infrastructure to share artifacts. Usually using a repository proxy (Sonatype Nexus or Artifactory). You can also use a network folder using the file:// protocol for quick startup.
In the pom.xml you need to add the <distributionManagement> section (in the taglib pom.xml) to specify the folder / proxy the artifacts are uploaded to. A mvn deploy will then build and copy the jar file for you.
Other developers need to add that location as repository in settings.xml (I dont recommend doing that in pom.xml) or if you setup a maven proxy configure a mirrorOf in settings.xml
There are archteypes available (project templates) that will help you creating initial project structures: http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
see also: http://maven.apache.org/guides/getting-started/index.html