Hi Juerg,
Juerg Meier schrieb:
Hi Felix,
Progress! Both bundles are now installed, visible in the console and
started!
Cool !
However, there not yet doing what they supposed to do: for instance, I
cannot retrieve resources from the resource bundle. E.g. the license
file has path /license.txt within the bundle jar. So, in combination
with the
Sling-Bundle-Resources: /libs/fckeditor
I would have guessed that the URI for it is:
http://localhost:7402/libs/fckeditor/license.txt
But I get a 404 instead.
Any idea?
Yes, the license file is expected to be at /libs/fckeditor/license.txt
in the bundle. So the path used to access the resource is looked up as
is in the bundle providing the resource.
If you want to have the fckeditor in the root of your bundle, you might
want to use the path mapping feature:
Sling-Bundle-Resources/libs/fckeditor!/
This functionality cause the bundle resource provider top cut off
everything before the bang ("!") from the requested resource path and
only using the remaing path to access the bundle.
Regards
Felix
Thanks so much,
Juerg
On Mon, 2008-08-25 at 08:15 +0200, Felix Meschberger wrote:
Hi Juerg,
Juerg Meier schrieb:
Hi Felix,
Well. my first adventure into OSGi was not a very lucky one... I
prepared two bundles, one for the resources, one for the taglib, but
adding them with the mgmt console, they remained invisible. Looks like
their falling in a black hole, because there wasn't an error message
either...
Perhaps the manifests are incomplete? Here the one for the static
resources:
Manifest-Version: 1.0
Bundle-Version: 1.0.0
Bundle-Name: FCKEditorResources
Bundle-ManifestVersion: 2
Sling-Bundle-Resources: /libs/fckeditor
The problem with this manifest is, that the Bundle-SymbolicName header
is missing, which is required by OSGi R4. The same problem is with the
tag lib bundle.
I observed that
in CRX quickstart there is bundle #33 that contains
resources only. Howewver, its manifest does not contain a
Sling-Bundle_Resources header, but something called
Sling-Initial-Content.
These have different use cases: Sling-Bundle-Resources provides the
files (and folders) in the Sling Resource tree directly without any
traces in the repository. The main advantage of this is, that simply
updating the bundle also updates the files and folders in the reource tree.
The Sling-Initial-Content header causes the addressed content to be
copied to the repository. The main advantage of this is, that you can
then directly manipulate these files in the repository without having to
redeploy a bundle -- but of course you loose the code management
functionality of the bundle in this case.
So in the end, using Sling-Bundle-Resources in this case is supperior IMHO.
For the taglib bundle, I declared the following:
Manifest-Version: 1.0
Bundle-Version: 1.0.0
Bundle-Name: FCKEditor-taglib
Bundle-ManifestVersion: 2
Export-Package: net.fckeditor, net.fckeditor.handlers,
net.fckeditor.tool
Bundle-ClassPath: ., ./lib/commons-fileupload-1.2.1.jar,
./lib/commons-io-1.3.2.jar, ./lib/slf4j-api-1.5.2.jar
Build-Jdk: 1.5.0_13
You should not include the slf4j-api library in the tag lib bundle,
otherwise you get errors while running the library. Rather define an
Import-Package statement for the slf4j API:
Import-Package: org.slf4j
This works perfectly because the Sling log bundle provides this API for use.
Do I need an activator, an import header or something else?
no, this is not needed as the JSP compiler recognizes the *.tld files in
the bundle's META-INF folders automatically and registers the respective
tag library from those files.
Hope this helps.
Regards
Felix
