Hi Juerg,
Juerg Meier schrieb:
Hello Felix,
***
This is my 2nd wiring of this posting, first one has been rejected as it
was qualified as spam, so I intentionally put spaces into URIs and the
word "sl ing".
***
Well, the exclamation mark in the Slin
g-Bundle-Resources:/libs/fckeditor!/
did it, in fact! I actually thought about this definition rather like a
traditional mount point than a path within the bundle. Great that both
ways are possible.
Good to hear. Thanks for the feedback.
Now, looks like I need another of your very valuable tips with the
taglib bundle...
As mentioned, the taglib bundle installed fine. In the jsp (where I use
the FCK:edit tag), I declared the recommended taglib directive:
<%@ taglib uri="http://fckeditor .net/tags-fckeditor" prefix="FCK" %>
At runtime, the jsp reacted with an error 500:
org.apache.jasper.JasperException: This absolute uri
(http://fckeditor .net/tags-fckeditor) cannot be resolved in either
web.xml or the jar files deployed with this application.
If you just embed the tag library (I assume the java-core-2.4.jar ?) in
your bundle, the JSP compiler should recognize the FCKeditor.tld file in
the jar's META-INF folder and load that descriptor. As a URL, the one in
the tld file is assumed (lacking any other means of configuration). This
your taglib declaration should probably read:
<%@ taglib uri="http://java.fckeditor.net"; prefix="FCK" %>
Then other thing of defining a bundle resource and using an absolute
path should not be required.
Well, to make a long story short, I combined then a
Slin g-Bundle-Resources: /libs/fckeditor-taglib!/
header with the jsp taglib directive
<[EMAIL PROTECTED] uri="/libs /fckeditor-taglib/META-INF/FCKeditor.tld"
prefix="FCK" %>
Now, the jsp seems to be a little happier, it just issues the following
error:
java.lang.NoClassDefFoundError: javax/servlet/jsp/tagext/TagSupport
at java.lang.ClassLoader.defineClass1(Native Method)
...
May be a missing import?
Yes, I created a simple maven project using the maven-bundle-plugin,
which creates the following imports:
javax.portlet {resolution:=optional}
javax.servlet
javax.servlet.http
javax.servlet.jsp
javax.servlet.jsp.tagext
javax.xml.parsers
javax.xml.transform
javax.xml.transform.dom
javax.xml.transform.stream
org.slf4j
org.w3c.dom
I have not tested this, though ;-)
Hope this helps.
Regards
Felix
The manifest looks like this now:
Manifest-Version: 1.0Bundle-Version: 1.0.0
Bundle-Name: FCKEditor-taglib
Bundle-SymbolicName: net.proxymit.fck.fcktaglib
Bundle-ManifestVersion: 2
Import-Package: org.slf4j
Export-Package: net.fckeditor, net.fckeditor.handlers,
net.fckeditor.tags, net.fckeditor.tool
Bundle-ClassPath: /fckeditor-java-core-2.4.jar,
/lib/commons-fileupload-1.2.1.jar, /lib/commons-io-1.3.2.jar
Build-Jdk: 1.5.0_15
Sli ng-Bundle-Resources: /libs/fckeditor-taglib!/
Thanks,
Juerg
On Tue, 2008-08-26 at 08:43 +0200, Felix Meschberger wrote:
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
