Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Tld support for Jetty in OSGi

Hi Chris,

I can confirm that adding the Import-Bundle makes the sample webapp work.

Do you want to try out the changes in jetty-7.6.3-SNAPSHOT? If so,
I've pushed a snapshot you should be able to get from here:

http://oss.sonatype.org/content/groups/jetty/org/eclipse/jetty/jetty-distribution/

Let me know how it goes,

Jan

On 16 March 2012 23:17, Chris Frost <frostc@xxxxxxxxxx> wrote:
>
> Hi,
>
> Could also try adding the Import-Bundle header, it's a Virgo only header but it causes all exported packages of a bundle to be imported. I think it would be OK to require uses to have both headers when using tld's. If that works I'm guessing other things have been fixed as well though as previously enabling the "Require-TldBundle" in jetty.xml really broke a lot of things?
>
> I'm glad that loading the standard tlds is working again, this means we haven't regressed in functionality at all.
>
> Chris.
>
> ----- Original Message -----
> From: "Jan Bartel" <janb@xxxxxxxxxxx>
> To: "Jetty @ Eclipse developer discussion list" <jetty-dev@xxxxxxxxxxx>
> Sent: Thursday, 15 March, 2012 10:19:07 PM
> Subject: Re: [jetty-dev] Tld support for Jetty in OSGi
>
> Chris,
>
> I have found the other problem I was referring to in earlier email.
>
> The org.eclipse.virgo.jetty.sample.web.jar contains this manifest:
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.8.1
> Created-By: 1.6.0_24-b07-334-10M3326 (Apple Inc.)
> Require-TldBundle: org.springframework.web.servlet
> Bundle-Version: 1.0.0
> Tool: Bundlor 1.1.0.BUILD-20101220120024
> Bundle-Name: Web
> Bundle-ManifestVersion: 2
> Bundle-SymbolicName: org.eclipse.virgo.jetty.sample.web
> Web-ContextPath: taglibs
> Import-Package: org.eclipse.virgo.web.dm;version="[3.0.0,4.0.0)",org.s
>  pringframework.context.config;version="[2.5.6,4.0.0)",org.springframe
>  work.stereotype;version="[2.5.6,4.0.0)",org.springframework.web.bind.
>  annotation;version="[2.5.6,4.0.0)",org.springframework.web.context;ve
>  rsion="[2.5.6,4.0.0)",org.springframework.web.servlet;version="[2.5.6
>  ,4.0.0)",org.springframework.web.servlet.view;version="[2.5.6,4.0.0)"
> Bundle-Creator: cgfrost
> Implementation-Title: org.eclipse.virgo.jetty.sample.web
> Implementation-Version: 3.0.0.BUILD-20110610105057
>
> The "Require-TldBundle:" entry tells us that you need the
> org.springframework.web.servlet.jar on the webapp's classpath to use
> with jsps. However, the problem is that none of the dependencies of
> that jar are listed in this manifest, so they won't be available in
> the osgi classloader. So whilst the jsp can compile ok because the
> classes it directly refers to are all in the
> org.springframework.web.servlet.jar (and the others are referred to
> via reflection), it won't run because of ClassNotFound exceptions.
>
> How do you overcome this issue when you run this webapp with Tomcat in virgo?
>
> The only solutions I see are:
>
> 1. you declare Import-Package statements for all packages in the
> org.eclipse.virgo.jetty.sample.web.jar
> 2. we do some fiddle to analyze the dependencies of
> org.eclipse.virgo.jetty.sample.web.jar at runtime and force them onto
> the osgi classloader
>
> I'm not sure that the osgi api has enough support for 2. Option 1
> sounds the easiest?
>
> I will also have a read of RFC-66 and see if they cover this
> situation, although I suspect not.
>
> Jan
>
>
> On 13 March 2012 00:39, Chris Frost <frostc@xxxxxxxxxx> wrote:
>> Hi,
>>
>> OK, that's great to hear. I'm more then happy to test stuff out before you cut 7.6.3/8.1.3 releases to make sure it all looks good. I'll hold off upgrading Virgo to 7.6.2/8.1.2 till then.
>>
>> Thank,
>> Chris.
>>
>> ----- Original Message -----
>> From: "Jan Bartel" <janb@xxxxxxxxxxx>
>> To: "Jetty @ Eclipse developer discussion list" <jetty-dev@xxxxxxxxxxx>
>> Sent: Sunday, 11 March, 2012 9:46:49 PM
>> Subject: Re: [jetty-dev] Tld support for Jetty in OSGi
>>
>> Chris,
>>
>> Unfortuntely I discovered the solution for the main problem that was
>> holding up the taglib stuff just *after* we cut the 7.6.2/8.1.2
>> releases. However, having gotten over that hurdle, I think there is 1
>> more issue to resolve with the classloading and taglibs and then we
>> should be good.
>>
>> We will be making a 7.6.3/8.1.3 release that will contain the osgi fix
>> in the near future, will keep you up-to-date.
>>
>> cheers
>> Jan
>>
>>
>> On 9 March 2012 23:06, Chris Frost <frostc@xxxxxxxxxx> wrote:
>>> Hi,
>>>
>>> I've been through the new Jetty file, I understand the changes and looks cleaner. I have committed it to our 3.0.x line but obviously the taglib dependant apps are still bust. I doesn't work on Jetty 8.x but I might pick over some of the changes and move them over. I suspect it's the taglibs definitions messing things up again so will just comment those out as I've done already and keep the rest.
>>>
>>> Thanks, Chris.
>>>
>>> ----- Original Message -----
>>> From: "Jan Bartel" <janb@xxxxxxxxxxx>
>>> To: "Jetty @ Eclipse developer discussion list" <jetty-dev@xxxxxxxxxxx>
>>> Sent: Wednesday, 7 March, 2012 10:37:05 PM
>>> Subject: Re: [jetty-dev] Tld support for Jetty in OSGi
>>>
>>> I think there might also have been a change with the way glassfish
>>> jasper finds the classpath for compilation. It now wants an explicit
>>> classpath listing all of the jars that are considered to be on the
>>> container's classpath. In standard jetty we can create that just fine
>>> (in org.eclipse.jetty.webapp.StandardDescriptorProcessor.getSystemClassPath())
>>> because we interrogate a URLClassloader.
>>>
>>> However, in the osgi code, the classloader that we are dealing with is
>>> the special TldLocatableURLClassLoader, which seems to have been
>>> created in order to expose the location of jars/bundles that contain
>>> tlds, as it contains only the org.apache.jasper.glassfish.taglibs jar.
>>>
>>> I'm working on getting all of the other necessary jsp jar locations
>>> into this classloader (as it is the parent loader for each webapp) so
>>> the StandardDescriptorProcessor can extract them as usual during
>>> startup.
>>>
>>> Chris, BTW, the zipped virgo setup you attached to issue
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=349009 has been most
>>> helpful. There are a few things you need to do to the jetty setup to
>>> get it working better (although not fully until I resolve the
>>> classpath and tld problems). I'm attaching the modified jetty.xml file
>>> you should use, along with the 7.6.x jars.
>>>
>>> cheers
>>> Jan
>>>
>>> On 8 March 2012 03:17, Chris Frost <frostc@xxxxxxxxxx> wrote:
>>>> Hi,
>>>>
>>>> Well, the short of it is that we need to upgrade for the security fix and we need the new version of Jetty on the 7.x line to support the standard tag libs. I think we understand the problem well enough now and just need a solution.
>>>>
>>>> Chris.
>>>>
>>>> ----- Original Message -----
>>>> From: "Hugues Malphettes" <hmalphettes@xxxxxxxxxxx>
>>>> To: "Jetty @ Eclipse developer discussion list" <jetty-dev@xxxxxxxxxxx>
>>>> Sent: Wednesday, 7 March, 2012 2:48:13 PM
>>>> Subject: Re: [jetty-dev] Tld support for Jetty in OSGi
>>>>
>>>> Hi Chris,
>>>>
>>>> With the older version of Jasper we used to stuff the jars that
>>>> contain the tlds files in a URLClassLoader [1]
>>>> Because that was where jasper would discover them.
>>>> I am quite sure we could port the tld-requirebundle to the newer Jasper.
>>>> Easier said than done of course.
>>>> Let me know if you want more pointers.
>>>> I'll work on this eventually otherwise.
>>>> Cheers,
>>>> Hugues
>>>> [1] https://github.com/eclipse/jetty.project/blob/master/jetty-osgi/jetty-osgi-boot/src/main/java/org/eclipse/jetty/osgi/boot/internal/jsp/TldLocatableURLClassloader.java
>>>>
>>>> On Wed, Mar 7, 2012 at 6:59 PM, Chris Frost <frostc@xxxxxxxxxx> wrote:
>>>>> Hi,
>>>>>
>>>>> Thanks for that, that helps a lot. So there is no point trying to use the Required-TldBundle header for the jstl tags and maybe the faces tags as they need to be pre-avaliable on the servlet containers classpath. That header should just be used for other 3rd party tlds.
>>>>>
>>>>> As for figuring out the classpaths, think of each webapp bundle as being it's own webapp classpath. I'm not sure which bundle should be considered to be the system classpath, I would expect some code in the jetty-osgi-boot bundle (or it's jsp fragment) to find the bundles with the standard tlds in, scan them and set the magic context attribute that tells jasper about the system tlds. I would just scan the classpath of the jetty-osgi-boot bundle looking for tlds. Remember that fragment bundles share the same classloader as their host bundles so the jetty-osgi-boot classLoader already contains all the tlds as the jsp fragment imports them.
>>>>>
>>>>> I'm happy to try stuff out as soon as you have anything, just point me at the jars.
>>>>> Thank you for your help on this, it is appreciated.
>>>>>
>>>>> Chris.
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Jan Bartel" <janb@xxxxxxxxxxx>
>>>>> To: "Jetty @ Eclipse developer discussion list" <jetty-dev@xxxxxxxxxxx>
>>>>> Sent: Tuesday, 6 March, 2012 11:37:32 PM
>>>>> Subject: Re: [jetty-dev] Tld support for Jetty in OSGi
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> From jetty-7.5 onwards we are using jsp-impl-2.1.3.b10. For your
>>>>> reference, here's our wiki page on jsp:
>>>>> http://wiki.eclipse.org/Jetty/Howto/Configure_JSP
>>>>>
>>>>> The main difference is the way that the new version of jasper expects
>>>>> to find the tlds. As we were doing previously, we need to examine jars
>>>>> to find META-INF/tlds, but now we need to pre-load them into a
>>>>> collection (org.apache.jasper.compiler.TldLocationsCache) that jasper
>>>>> is holding onto that defines "system" tlds (ie tlds that are on the
>>>>> container's classpath, not the webapp's classpath). Jasper is very
>>>>> strict about tld urls and which ones it will consider on the webapp's
>>>>> vs the containers classpath. For example, the jstl tags (and I think
>>>>> the faces tags too, but I can't remember right now) it will only ever
>>>>> consider as being on the system classpath, so putting those jars into
>>>>> a webapp will do you no good, they have to be on the container's
>>>>> classpath.
>>>>>
>>>>> I just need to work out how to marry this concept of system/webapp
>>>>> classpath with osgi. The code that we need is in the
>>>>> org.eclipse.jetty.webapp.TagLibConfiguration  in standard jetty and
>>>>> the class I need to modify in the osgi code is
>>>>> org.eclipse.jetty.osgi.boot.jsp.TagLibOSGIConfiguration.
>>>>>
>>>>> I hope to have something for you to test today, but I'm being impeded
>>>>> by other problems getting our osgi unit tests to work - I think
>>>>> they're tangential problems but I need to resolve those before I can
>>>>> get to the Taglib stuff.
>>>>>
>>>>> cheers
>>>>> Jan
>>>>>
>>>>>
>>>>>
>>>>> On 6 March 2012 21:54, Chris Frost <frostc@xxxxxxxxxx> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Could you clarify what the changes of glassfish jasper between 7.4 and 7.6 are. As far as I can tell they are both on 2.1.0. Jetty ships with 2.1.0.v201007080150 on 7.4 and 1.2.0.v201112081803 on 7.6.
>>>>>>
>>>>>> Chris.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Jan Bartel" <janb@xxxxxxxxxxx>
>>>>>> To: "Jetty @ Eclipse developer discussion list" <jetty-dev@xxxxxxxxxxx>
>>>>>> Sent: Monday, 5 March, 2012 11:14:41 PM
>>>>>> Subject: Re: [jetty-dev] Tld support for Jetty in OSGi
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> The problem is no doubt due to the change of glassfish jasper versions
>>>>>> between 7.4 and 7.5. We need to be able to satisfy glassfish jasper's
>>>>>> requirements for the location of the tlds, some of which are required
>>>>>> to be on the container's classpath. So we need to meld osgi's concept
>>>>>> of classpath with glassfish jasper's expectations.
>>>>>>
>>>>>> I'm a mere osgi novice, but I'm happy to take a look at the code and
>>>>>> see if I can improve things. I don't really have an environment where
>>>>>> I can easily test - if I make some code changes do you have
>>>>>> environment where we could test them out??
>>>>>>
>>>>>> thanks
>>>>>> Jan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6 March 2012 03:21, Chris Frost <frostc@xxxxxxxxxx> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've upgraded from 7.4.x to 7.6.x and support for the standard tag libraries appears to have gone away. This was previously working as the 'org.eclipse.jetty.osgi.boot.jsp' fragment imported them in from the 'org.apache.taglibs.standard.glassfish' bundle. Looking at the wirings this is still the case but when trying to display a jsp page using tag libs it now fails with an exception saying the URL associated with one of the tag libs can't be resolved. For example "http://java.sun.com/jsp/jstl/core";.
>>>>>>>
>>>>>>>
>>>>>>> Ideally we could get the 'Require-TldBundle' header working so that each application can specifically it's Tld bundles instead of a server wide setup or depending on fragments of the osgi boot bundle. This has been a problem for a while and is documented in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=349009 with a zip of Virgo to recreate. It's a few versions out of date but nothing appears to have changed in the behaviour. It appears the documentation on how to use this header never got written so I've just followed the config provided in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=306971 but enabling it just breaks something very basic and Jetty can't even find static html files and there is nothing in the log saying it has had any problems. I've tried debugging through this but I'm not sure where the entry point is for http requests and I can't spot anything obvious in the code that processes the configuration.
>>>>>>>
>>>>>>> While the standard tag libraries are still working on the 8.x line the 'Require-TldBundle' header is broken on both 8.x and 7.x
>>>>>>>
>>>>>>> Chris.
>>>>>>>
>>>>>>>
>>>>>>> Christopher Frost - VMware
>>>>>>> Virgo from EclipseRT
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jetty-dev mailing list
>>>>>>> jetty-dev@xxxxxxxxxxx
>>>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>>>> _______________________________________________
>>>>>> jetty-dev mailing list
>>>>>> jetty-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>>>> _______________________________________________
>>>>>> jetty-dev mailing list
>>>>>> jetty-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>>> _______________________________________________
>>>>> jetty-dev mailing list
>>>>> jetty-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>>> _______________________________________________
>>>>> jetty-dev mailing list
>>>>> jetty-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>> _______________________________________________
>>>> jetty-dev mailing list
>>>> jetty-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>> _______________________________________________
>>>> jetty-dev mailing list
>>>> jetty-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>
>>> _______________________________________________
>>> jetty-dev mailing list
>>> jetty-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>> _______________________________________________
>>> jetty-dev mailing list
>>> jetty-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev


Back to the top