jetty fragment bundle fails due to lack of package import [PAXWEB-264]

ops4j-issues commented 13 years ago

Caspar MacRae created PAXWEB-264

bundle 54 is mvn:org.ops4j.pax.web/pax-web-jetty/1.0.1 to which my fragment correctly attaches
bundle 47 is packages:imports | grep org.eclipse.jetty.server.handler

Running packages:imports | grep org.eclipse.jetty.server.handler shows that only bundle 47 imports the package for the ContextHandler I'm trying to use

jetty.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

<Configure class="org.eclipse.jetty.server.handler.MovedContextHandler">
    <Set name="ContextPath">/old-context-root</Set>
    <Set name="NewContextURL">/new-context-root</Set>
    <Set name="Permanent">true</Set>
    <Set name="DiscardPathInfo">false</Set>
    <Set name="DiscardQuery">false</Set>
</Configure>

The jetty.xml is located in the root of the bundle jar

snippet_of_pom.xml

...
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <version>${version.plugin.felix.bundle}</version>
                <configuration>
                    <instructions>
                        <Bundle-Vendor>${project.organization.name}</Bundle-Vendor>
                        <Bundle-ContactAddress>${project.organization.url}</Bundle-ContactAddress>
                        <Bundle-Description>${project.description}</Bundle-Description>
                        <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
                        <Bundle-Version>${project.version}</Bundle-Version>
                        <Fragment-Host>org.ops4j.pax.web.pax-web-jetty</Fragment-Host>
                        <Import-Package>org.eclipse.jetty.server.handler</Import-Package>
                    </instructions>
                </configuration>
            </plugin>
...

I tried using dev:dynamic-import 54 but this doesn't seem to help, so may be I'm wrong in thinking that org.ops4j.pax.web/pax-web-jetty/1.0.1 should import org.eclipse.jetty.server.handler.

Another thing, when the above log message is seen none of the contexts are available, but requests don't 404 they just spin endlessly until timeout.

The attachment of the fragment causes a refresh of the attached-to bundle AFAIK - I suspect that this is causing the port from etc/jetty.xml to be picked up instead of that defined by org.osgi.service.http.port - if I set them to be the same the the contexts are accessible and the logged error doesn't appear but the MovedContextHandler has no effect.

I think this issue relates to PAXWEB-186 and apologize if this issue should really be created on the Karaf Jira.

thanks.

Affects: 1.0.1 Fixed in: 1.0.4, 1.1.0 Votes: 0, Watches: 1

ops4j-issues commented 13 years ago

Achim Nierbeck commented

Since your using Karaf 2.2.0 there is a jetty.xml located at $ {karaf.home}

/etc/
could you try to use this one instead of the fragment?

If it still doesn't work, are you sure the Class in question is really already available.
Since in Karaf it is not the jetty-all bundle used, but rather just the needed parts, so
it might be not available.

ops4j-issues commented 13 years ago

Caspar MacRae commented

Hi Achim,

From what I can see the configure.dtd of Jetty only allows a single <Configure> element so it's not possible to configure the classes org.eclipse.jetty.server.Server and org.eclipse.jetty.server.handler.MovedContextHandler in the same jetty.xml

wrt to the MovedContextHandler, it's in the mvn:/org.eclipse.jetty/jetty-server/7.2.2.v20101205 (bundle 47 in issue description, which i forgot to name) what's confusing is that the bundle mvn:org.ops4j.pax.web/pax-web-jetty/1.0.1 has an import for this package ... ,org.eclipse.jet
ty.server.handler;version="[7.1.0,8.0.0)", ... This has me a little perplexed, especially as there's little information in the log - i will hopefully find sometime to debug this over the weekend and report back.

wrt to the pax-web-jetty not being jetty-all (a good thing) - surely should have a header such as DynamicImport-Package: org.eclipse.jetty.* to allow other (non-pax-web core) jetty bundles to be used too?

ops4j-issues commented 13 years ago

Achim Nierbeck commented

About the import package, I'll think about it :smile:

ops4j-issues commented 13 years ago

Caspar MacRae commented

@Achim re: package import - thanks, it'd be nice and I think the limiting to org.eclipse.jetty.* wouldn't adversely impact performance (and has the upside of not requiring users to wrap other jetty libs as fragments).

Couple of things i've noticed;

1) the Jetty instance does start listening on the port defined in $ {KARAF_HOME}/etc/jetty.xml though the comment states that this is overridden by pax-web configuration - however the webapps deployed are only available on the org.osgi.service.http.port.

terminal 1:
cd ${KARAF_HOME}

./bin/karaf
features:install war

terminal 2:
sudo lsof -p <PID_OF_KARAF> | egrep '(8080|8181|http)'

Setting the etc/jetty.xml port to 8181 (Karaf default org.osgi.service.http.port) and the Karaf/PaxWeb stops listening to 8080

2) There appears to be an issue with using the root context-path, apps deploy and function but resources such as CSS and images aren't found (I tested this with simple wars using the maven-jetty-plugin and the resources are found fine). I've tried defining the root as "/" and also "//"

Should I create 2) as a separate issue?

ops4j-issues commented 13 years ago

Achim Nierbeck commented

@Caspar

about 2) yes please open a new issue for that. But it might also be related to PAXWEB-108
about the port, yes the Jetty Server starts with 8080 and does get reconfigured to the one set by the org.osgi.service.http.port.
This is because the 8080 is also the default port, and how the jetty starts up. First the server needs to be started before it can be reconfigured to use a new port.

ops4j-issues commented 13 years ago

Achim Nierbeck commented

@Caspar,

no need to create a new issue for your second problem it's fixed by now with PAXWEB-266

ops4j-issues commented 13 years ago

Achim Nierbeck commented

will go into a 1.1.x version since it is a change in the dependencies

ops4j-issues commented 13 years ago

Achim Nierbeck commented

After taking a deeper look at what you request and how pax web works, I don't think this is possible right now.

Some thoughts about what you have done already and some comments on that.
It's a good way of creating a fragment bundle and it's even better if you need additional packages to define those imports in the fragment bundle, the import-package of the host bundle and the fragment bundle do get merged therefore this is the right way of doing it. A more generic dynamic import doesn't help in this case, since using the fragment it's already clear that the import is required. Now it might be possible that the package in question isn't exported, might be wrong I didn't have the time to check :slightly_frowning_face:

why non fixable?
Well, the way pax-web configures jetty, there is no easy way of adding an additional ContextHandler or better a replacement of the context Handler. I even would say it's almost impossible since there is no explicit ContextHandler used from the jetty packages, but one of pax web itself and the way pax web handles the requests.

The only way I could see to achieve that is to make the pax-context-handler extensible for customization. That would be a new "requirement".

You might take a look at how the NCSARequestHandler ( PAXWEB-269 ) was added, this might help you to understand why this is merely impossible.

ops4j-issues commented 13 years ago

Achim Nierbeck commented

In http://wiki.ops4j.org/display/paxweb/Advanced+Jetty+Configuration there is a description on how to add custom ContextHandlers to the Jetty server
which is primarily configured by pax-web.

In this special case it is also needed to do the following:

<Get name="handler">
        <Call name="addHandler">
          <Arg>
          <New class="org.eclipse.jetty.server.handler.MovedContextHandler">
    <Set name="ContextPath">/old-context-root</Set>
    <Set name="NewContextURL">/new-context-root</Set>
    <Set name="Permanent">true</Set>
    <Set name="DiscardPathInfo">false</Set>
    <Set name="DiscardQuery">false</Set>
        </New>
</Arg>
        </Call>
    </Get>

ops4j-issues commented 13 years ago

Caspar MacRae commented

Great stuff, thanks Achim =)

ops4j / org.ops4j.pax.web

jetty fragment bundle fails due to lack of package import [PAXWEB-264] #599