Fail to embed Jetty in a bundle

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Fail to embed Jetty in a bundle

Peter Nerg
I'm trying to embed the entire Jetty in a bundle of my own, i.e. not to install Jetty as separate bundles.

I'm using one of the aggregate jars provided by Jetty and simply include it into my bundle that is built using maven.
I've included all the dependencies provided in the following package:
<dependency>
        <groupId>org.eclipse.jetty.aggregate</groupId>
        <artifactId>jetty-all-server</artifactId>
        <version>7.6.1.v20120215</version>
        <scope>compile</scope>
</dependency>


However when I try to start my bundle I get:
Unable to resolve 5.0: missing requirement [5.0] osgi.wiring package; (osgi.wiring.package=org.mortbay.log)

Not sure why it requests the mortbay logger as from what I gather it should no longer be used starting from v7 of jetty.
Reply | Threaded
Open this post in threaded view
|

Re: Fail to embed Jetty in a bundle

Joakim Erdfelt-9
The aggregates are not osgi bundle capable. (nor will they likely ever be as osgi doesn't like 2 different artifacts advertising the same content from different coordinates)
Sorry.

Any bundle-like information in the meta-inf/manifest.mf you find in them is purely a side-effect of the aggregation process and a complete accident.
For osgi related work, you'll likely want to start with the jetty-osgi packages and work your way through the standard dependency list from there.

--
Joakim Erdfelt

(the people behind jetty and cometd)



On Mon, Feb 27, 2012 at 4:43 AM, Peter Nerg <[hidden email]> wrote:
I'm trying to embed the entire Jetty in a bundle of my own, i.e. not to
install Jetty as separate bundles.

I'm using one of the aggregate jars provided by Jetty and simply include it
into my bundle that is built using maven.
I've included all the dependencies provided in the following package:
<dependency>
       <groupId>org.eclipse.jetty.aggregate</groupId>
       <artifactId>jetty-all-server</artifactId>
       <version>7.6.1.v20120215</version>
       <scope>compile</scope>
</dependency>


However when I try to start my bundle I get:
/Unable to resolve 5.0: missing requirement [5.0] osgi.wiring package;
(osgi.wiring.package=org.mortbay.log)/

Not sure why it requests the mortbay logger as from what I gather it should
no longer be used starting from v7 of jetty.

--
View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514503.html
Sent from the Jetty Support mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Fail to embed Jetty in a bundle

Peter Nerg
Really!

That's odd, if I install the aggregate and a few other bundles into Felix and then add my own bundle it simply works...:)

However when putting the jetty bundle + a few others into my own bundle it fails.

Anyways I'll drop that track and take a look at the "proper" OSGi bundles for Jetty.
That's what I get for trying to save time with one big happy binary..:(
Reply | Threaded
Open this post in threaded view
|

Re: Fail to embed Jetty in a bundle

Jesse McConnell
if you are close with your approach I don't see it being a bad thing

I had thought the aggregates were 'close' for osgi and were being
adjusted for supporting that, at least at some point in their history
they were

since your trying to generate a large bundle of your own then I would
probably look at using the same sort of dependency setup as the
aggregate pom and roll your own manifest, no reason that wouldn't work

it will be 'un-osgi' but that isn't necessarily a bad thing :)

cheers,
jesse

--
jesse mcconnell
[hidden email]



On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:

> Really!
>
> That's odd, if I install the aggregate and a few other bundles into Felix
> and then add my own bundle it simply works...:)
>
> However when putting the jetty bundle + a few others into my own bundle it
> fails.
>
> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
> for Jetty.
> That's what I get for trying to save time with one big happy binary..:(
>
> --
> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
> Sent from the Jetty Support mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Fail to embed Jetty in a bundle

Hugues Malphettes
Hi Petr and Jesse,

In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
requested and assisted us with it.
Here is the bug where the work was done:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222

I am not sure where the import for org.mortbay would come.
Please let us know if we need to change something in the build of
"jetty-all-server" to fix it or accommodate your situation.

Cheers,
Hugues.

On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
<[hidden email]> wrote:

> if you are close with your approach I don't see it being a bad thing
>
> I had thought the aggregates were 'close' for osgi and were being
> adjusted for supporting that, at least at some point in their history
> they were
>
> since your trying to generate a large bundle of your own then I would
> probably look at using the same sort of dependency setup as the
> aggregate pom and roll your own manifest, no reason that wouldn't work
>
> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>
> cheers,
> jesse
>
> --
> jesse mcconnell
> [hidden email]
>
>
>
> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>> Really!
>>
>> That's odd, if I install the aggregate and a few other bundles into Felix
>> and then add my own bundle it simply works...:)
>>
>> However when putting the jetty bundle + a few others into my own bundle it
>> fails.
>>
>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>> for Jetty.
>> That's what I get for trying to save time with one big happy binary..:(
>>
>> --
>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Jetty 8.0

Kirk Pepperdine
Hi,

I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.

Here is the cmd line. (OSX but Linux and Windows will also be used).

java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)

Regards,
Kirk


On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:

> Hi Petr and Jesse,
>
> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
> requested and assisted us with it.
> Here is the bug where the work was done:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>
> I am not sure where the import for org.mortbay would come.
> Please let us know if we need to change something in the build of
> "jetty-all-server" to fix it or accommodate your situation.
>
> Cheers,
> Hugues.
>
> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
> <[hidden email]> wrote:
>> if you are close with your approach I don't see it being a bad thing
>>
>> I had thought the aggregates were 'close' for osgi and were being
>> adjusted for supporting that, at least at some point in their history
>> they were
>>
>> since your trying to generate a large bundle of your own then I would
>> probably look at using the same sort of dependency setup as the
>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>
>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>
>> cheers,
>> jesse
>>
>> --
>> jesse mcconnell
>> [hidden email]
>>
>>
>>
>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>> Really!
>>>
>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>> and then add my own bundle it simply works...:)
>>>
>>> However when putting the jetty bundle + a few others into my own bundle it
>>> fails.
>>>
>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>> for Jetty.
>>> That's what I get for trying to save time with one big happy binary..:(
>>>
>>> --
>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Jan Bartel-3
Kirk,

The start mechanism has been changed a fair bit between jetty-6 and
jetty-8. Have you seen the doco at:

http://wiki.eclipse.org/Jetty/Feature/Start.jar
and
http://wiki.eclipse.org/Jetty/Reference/Start_Options

Having said that, checking the code, if you want to supply the xml
files on the command line, then they have to be an absolute path, or
else jetty will try to find the relative path inside $jetty.home. Not
sure at this point if that's a difference between 6 and 7/8, but it
seems that is your stumbling block.

cheers
Jan

On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:

> Hi,
>
> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>
> Here is the cmd line. (OSX but Linux and Windows will also be used).
>
> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>
> Regards,
> Kirk
>
>
> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>
>> Hi Petr and Jesse,
>>
>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>> requested and assisted us with it.
>> Here is the bug where the work was done:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>
>> I am not sure where the import for org.mortbay would come.
>> Please let us know if we need to change something in the build of
>> "jetty-all-server" to fix it or accommodate your situation.
>>
>> Cheers,
>> Hugues.
>>
>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>> <[hidden email]> wrote:
>>> if you are close with your approach I don't see it being a bad thing
>>>
>>> I had thought the aggregates were 'close' for osgi and were being
>>> adjusted for supporting that, at least at some point in their history
>>> they were
>>>
>>> since your trying to generate a large bundle of your own then I would
>>> probably look at using the same sort of dependency setup as the
>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>
>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>
>>> cheers,
>>> jesse
>>>
>>> --
>>> jesse mcconnell
>>> [hidden email]
>>>
>>>
>>>
>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>> Really!
>>>>
>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>> and then add my own bundle it simply works...:)
>>>>
>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>> fails.
>>>>
>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>> for Jetty.
>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>
>>>> --
>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Kirk Pepperdine
Hi Jan,

Thanks for the quick response. I've been looking at documentation but not of it applied to my particular deployment requirements and I hadn't run into these pages so thanks for the links. The later one looks particularly useful.
On 2012-02-28, at 6:27 AM, Jan Bartel wrote:

>
>
> Having said that, checking the code, if you want to supply the xml
> files on the command line, then they have to be an absolute path, or
> else jetty will try to find the relative path inside $jetty.home. Not
> sure at this point if that's a difference between 6 and 7/8, but it
> seems that is your stumbling block.

With 6 start.jar read the jetty.xml file supplied without munging in the $jetty.home setting so this is a difference between 6 and 8.

What forced the move is that 6.1.24 is that I ran into a JNDI bug. Fixed in later version of 6 introduced a bottleneck on access log logging. That motivated the move to 8 but unless I can generate a work-around, this will be a complete show-stopper.

>
> cheers
> Jan
>
> On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:
>> Hi,
>>
>> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>>
>> Here is the cmd line. (OSX but Linux and Windows will also be used).
>>
>> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
>> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>>
>> Regards,
>> Kirk
>>
>>
>> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>>
>>> Hi Petr and Jesse,
>>>
>>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>>> requested and assisted us with it.
>>> Here is the bug where the work was done:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>>
>>> I am not sure where the import for org.mortbay would come.
>>> Please let us know if we need to change something in the build of
>>> "jetty-all-server" to fix it or accommodate your situation.
>>>
>>> Cheers,
>>> Hugues.
>>>
>>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>>> <[hidden email]> wrote:
>>>> if you are close with your approach I don't see it being a bad thing
>>>>
>>>> I had thought the aggregates were 'close' for osgi and were being
>>>> adjusted for supporting that, at least at some point in their history
>>>> they were
>>>>
>>>> since your trying to generate a large bundle of your own then I would
>>>> probably look at using the same sort of dependency setup as the
>>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>>
>>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>>
>>>> cheers,
>>>> jesse
>>>>
>>>> --
>>>> jesse mcconnell
>>>> [hidden email]
>>>>
>>>>
>>>>
>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>>> Really!
>>>>>
>>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>>> and then add my own bundle it simply works...:)
>>>>>
>>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>>> fails.
>>>>>
>>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>>> for Jetty.
>>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>>
>>>>> --
>>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Jan Bartel-3
Kirk,

Not sure of the problem? Why can't you specify the absolute location
of the xml file on the command line, rather than the relative one
you've got now?

Jan

On 28 February 2012 16:46, Kirk Pepperdine <[hidden email]> wrote:

> Hi Jan,
>
> Thanks for the quick response. I've been looking at documentation but not of it applied to my particular deployment requirements and I hadn't run into these pages so thanks for the links. The later one looks particularly useful.
> On 2012-02-28, at 6:27 AM, Jan Bartel wrote:
>
>>
>>
>> Having said that, checking the code, if you want to supply the xml
>> files on the command line, then they have to be an absolute path, or
>> else jetty will try to find the relative path inside $jetty.home. Not
>> sure at this point if that's a difference between 6 and 7/8, but it
>> seems that is your stumbling block.
>
> With 6 start.jar read the jetty.xml file supplied without munging in the $jetty.home setting so this is a difference between 6 and 8.
>
> What forced the move is that 6.1.24 is that I ran into a JNDI bug. Fixed in later version of 6 introduced a bottleneck on access log logging. That motivated the move to 8 but unless I can generate a work-around, this will be a complete show-stopper.
>
>>
>> cheers
>> Jan
>>
>> On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:
>>> Hi,
>>>
>>> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>>>
>>> Here is the cmd line. (OSX but Linux and Windows will also be used).
>>>
>>> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
>>> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>>>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>>>
>>> Regards,
>>> Kirk
>>>
>>>
>>> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>>>
>>>> Hi Petr and Jesse,
>>>>
>>>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>>>> requested and assisted us with it.
>>>> Here is the bug where the work was done:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>>>
>>>> I am not sure where the import for org.mortbay would come.
>>>> Please let us know if we need to change something in the build of
>>>> "jetty-all-server" to fix it or accommodate your situation.
>>>>
>>>> Cheers,
>>>> Hugues.
>>>>
>>>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>>>> <[hidden email]> wrote:
>>>>> if you are close with your approach I don't see it being a bad thing
>>>>>
>>>>> I had thought the aggregates were 'close' for osgi and were being
>>>>> adjusted for supporting that, at least at some point in their history
>>>>> they were
>>>>>
>>>>> since your trying to generate a large bundle of your own then I would
>>>>> probably look at using the same sort of dependency setup as the
>>>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>>>
>>>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>>>
>>>>> cheers,
>>>>> jesse
>>>>>
>>>>> --
>>>>> jesse mcconnell
>>>>> [hidden email]
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>>>> Really!
>>>>>>
>>>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>>>> and then add my own bundle it simply works...:)
>>>>>>
>>>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>>>> fails.
>>>>>>
>>>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>>>> for Jetty.
>>>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Kirk Pepperdine
Hi Jan,

I use Jetty in my performance tuning course and as such, it gets installed on what ever and where ever. I use it for a number of different demonstrations and each demo is likely to have a different configuration. All workable with 6.x except that when I went to add in JPDC connection pooling I found bugs in the JNDI lookups which forced the move forward. That migration resulted in logging being the primary bottleneck in the application which was an unwanted side effect (i.e. a nice find by not fixable in the context of the course). Hence the motivation to move to the latest version.

Jetty has worked brilliantly for me over a number of years. It's always been stable across different releases of the JDK from early 1.4.2 right up until 1.6.0_29 and 7.0. It has always responded well to the performance enhancements in each newer version of the JDK and I've never had a problem getting it to work on dozens and dozens of different OS/hardware combinations including a number of juiced up versions of Linux and Windows (think banks and security). My one experience with GlassFish with a group of 140 people was a disaster. Sun talked me into using GF for that event and I'm kicking myself for giving in and not using Jetty as the GF problem never would have happened with Jetty. So, I'm not so happy at the moment with the thought of having to hack about to get something that is pretty simple to work. I was thinking of hacking in a fix to the start.jar but quite frankly, a move to tomcat would be much quicker. It's just that they diddle with java.io.dir which creates other challenges when working with larger groups.

Regards,
Kirk

On 2012-02-28, at 7:08 AM, Jan Bartel wrote:

> Kirk,
>
> Not sure of the problem? Why can't you specify the absolute location
> of the xml file on the command line, rather than the relative one
> you've got now?
>
> Jan
>
> On 28 February 2012 16:46, Kirk Pepperdine <[hidden email]> wrote:
>> Hi Jan,
>>
>> Thanks for the quick response. I've been looking at documentation but not of it applied to my particular deployment requirements and I hadn't run into these pages so thanks for the links. The later one looks particularly useful.
>> On 2012-02-28, at 6:27 AM, Jan Bartel wrote:
>>
>>>
>>>
>>> Having said that, checking the code, if you want to supply the xml
>>> files on the command line, then they have to be an absolute path, or
>>> else jetty will try to find the relative path inside $jetty.home. Not
>>> sure at this point if that's a difference between 6 and 7/8, but it
>>> seems that is your stumbling block.
>>
>> With 6 start.jar read the jetty.xml file supplied without munging in the $jetty.home setting so this is a difference between 6 and 8.
>>
>> What forced the move is that 6.1.24 is that I ran into a JNDI bug. Fixed in later version of 6 introduced a bottleneck on access log logging. That motivated the move to 8 but unless I can generate a work-around, this will be a complete show-stopper.
>>
>>>
>>> cheers
>>> Jan
>>>
>>> On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>>>>
>>>> Here is the cmd line. (OSX but Linux and Windows will also be used).
>>>>
>>>> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
>>>> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>>>>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>>>>
>>>> Regards,
>>>> Kirk
>>>>
>>>>
>>>> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>>>>
>>>>> Hi Petr and Jesse,
>>>>>
>>>>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>>>>> requested and assisted us with it.
>>>>> Here is the bug where the work was done:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>>>>
>>>>> I am not sure where the import for org.mortbay would come.
>>>>> Please let us know if we need to change something in the build of
>>>>> "jetty-all-server" to fix it or accommodate your situation.
>>>>>
>>>>> Cheers,
>>>>> Hugues.
>>>>>
>>>>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>>>>> <[hidden email]> wrote:
>>>>>> if you are close with your approach I don't see it being a bad thing
>>>>>>
>>>>>> I had thought the aggregates were 'close' for osgi and were being
>>>>>> adjusted for supporting that, at least at some point in their history
>>>>>> they were
>>>>>>
>>>>>> since your trying to generate a large bundle of your own then I would
>>>>>> probably look at using the same sort of dependency setup as the
>>>>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>>>>
>>>>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>>>>
>>>>>> cheers,
>>>>>> jesse
>>>>>>
>>>>>> --
>>>>>> jesse mcconnell
>>>>>> [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>>>>> Really!
>>>>>>>
>>>>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>>>>> and then add my own bundle it simply works...:)
>>>>>>>
>>>>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>>>>> fails.
>>>>>>>
>>>>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>>>>> for Jetty.
>>>>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Jan Bartel-3
Hi Kirk,

Thanks for the praise about jetty, and I'm very glad you've found it
so useful. I'm sure you'll also find jetty-7/8 useful for you too, I
just need to get a handle on what exactly is not working for you.

From what I gather, you want to be able to download a jetty distro to
a location and then run it from outside that directory, at the same
time passing in the location of some extra xml config files that you
want used.  All meat-and-potatoes stuff for jetty so far.

Now, it seems that in earlier versions of jetty, those extra xml
config files on the command line could be specified as a relative
path, but with jetty-7/8 we now expect them to be an absolute path.
I'm not really clear on why you're not able to provide the absolute
path ... but nevertheless, I will look at the code and see if we can
change our search algorithm for the xml files on the command line to
handle relative paths in the old way. In the meanwhile, if you can
just plonk in the absolute path to the file then I'm pretty sure
you'll be on your way quickly (BTW, you did see the porting page? I
know it says jetty-7, but 7 and 8 are the same, with 8 having
additional servlet 3.0 features). Here's the page :
http://wiki.eclipse.org/Jetty/Starting/Porting_to_Jetty_7)

Oh, and finally, this codehaus list has been superceeded by the
Eclipse lists, as jetty moved to Eclipse from jetty-7 onwards. The new
list locations are here:
http://www.eclipse.org/jetty/mailinglists.php. You'll see more
activity if you join those new lists.


cheers,
Jan



On 28 February 2012 17:59, Kirk Pepperdine <[hidden email]> wrote:

> Hi Jan,
>
> I use Jetty in my performance tuning course and as such, it gets installed on what ever and where ever. I use it for a number of different demonstrations and each demo is likely to have a different configuration. All workable with 6.x except that when I went to add in JPDC connection pooling I found bugs in the JNDI lookups which forced the move forward. That migration resulted in logging being the primary bottleneck in the application which was an unwanted side effect (i.e. a nice find by not fixable in the context of the course). Hence the motivation to move to the latest version.
>
> Jetty has worked brilliantly for me over a number of years. It's always been stable across different releases of the JDK from early 1.4.2 right up until 1.6.0_29 and 7.0. It has always responded well to the performance enhancements in each newer version of the JDK and I've never had a problem getting it to work on dozens and dozens of different OS/hardware combinations including a number of juiced up versions of Linux and Windows (think banks and security). My one experience with GlassFish with a group of 140 people was a disaster. Sun talked me into using GF for that event and I'm kicking myself for giving in and not using Jetty as the GF problem never would have happened with Jetty. So, I'm not so happy at the moment with the thought of having to hack about to get something that is pretty simple to work. I was thinking of hacking in a fix to the start.jar but quite frankly, a move to tomcat would be much quicker. It's just that they diddle with java.io.dir which creates other challenges when working with larger groups.
>
> Regards,
> Kirk
>
> On 2012-02-28, at 7:08 AM, Jan Bartel wrote:
>
>> Kirk,
>>
>> Not sure of the problem? Why can't you specify the absolute location
>> of the xml file on the command line, rather than the relative one
>> you've got now?
>>
>> Jan
>>
>> On 28 February 2012 16:46, Kirk Pepperdine <[hidden email]> wrote:
>>> Hi Jan,
>>>
>>> Thanks for the quick response. I've been looking at documentation but not of it applied to my particular deployment requirements and I hadn't run into these pages so thanks for the links. The later one looks particularly useful.
>>> On 2012-02-28, at 6:27 AM, Jan Bartel wrote:
>>>
>>>>
>>>>
>>>> Having said that, checking the code, if you want to supply the xml
>>>> files on the command line, then they have to be an absolute path, or
>>>> else jetty will try to find the relative path inside $jetty.home. Not
>>>> sure at this point if that's a difference between 6 and 7/8, but it
>>>> seems that is your stumbling block.
>>>
>>> With 6 start.jar read the jetty.xml file supplied without munging in the $jetty.home setting so this is a difference between 6 and 8.
>>>
>>> What forced the move is that 6.1.24 is that I ran into a JNDI bug. Fixed in later version of 6 introduced a bottleneck on access log logging. That motivated the move to 8 but unless I can generate a work-around, this will be a complete show-stopper.
>>>
>>>>
>>>> cheers
>>>> Jan
>>>>
>>>> On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>>>>>
>>>>> Here is the cmd line. (OSX but Linux and Windows will also be used).
>>>>>
>>>>> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
>>>>> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>>>>>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>>>>>
>>>>> Regards,
>>>>> Kirk
>>>>>
>>>>>
>>>>> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>>>>>
>>>>>> Hi Petr and Jesse,
>>>>>>
>>>>>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>>>>>> requested and assisted us with it.
>>>>>> Here is the bug where the work was done:
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>>>>>
>>>>>> I am not sure where the import for org.mortbay would come.
>>>>>> Please let us know if we need to change something in the build of
>>>>>> "jetty-all-server" to fix it or accommodate your situation.
>>>>>>
>>>>>> Cheers,
>>>>>> Hugues.
>>>>>>
>>>>>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>>>>>> <[hidden email]> wrote:
>>>>>>> if you are close with your approach I don't see it being a bad thing
>>>>>>>
>>>>>>> I had thought the aggregates were 'close' for osgi and were being
>>>>>>> adjusted for supporting that, at least at some point in their history
>>>>>>> they were
>>>>>>>
>>>>>>> since your trying to generate a large bundle of your own then I would
>>>>>>> probably look at using the same sort of dependency setup as the
>>>>>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>>>>>
>>>>>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>>>>>
>>>>>>> cheers,
>>>>>>> jesse
>>>>>>>
>>>>>>> --
>>>>>>> jesse mcconnell
>>>>>>> [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>>>>>> Really!
>>>>>>>>
>>>>>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>>>>>> and then add my own bundle it simply works...:)
>>>>>>>>
>>>>>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>>>>>> fails.
>>>>>>>>
>>>>>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>>>>>> for Jetty.
>>>>>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>>>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Jan Bartel-3
Hi again Kirk,

I've checked the code and I agree we can add back in the relative path
handling. I've raised the following bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=372806

In the meanwhile, its the absolute path on the command line.

cheers
Jan

On 29 February 2012 10:32, Jan Bartel <[hidden email]> wrote:

> Hi Kirk,
>
> Thanks for the praise about jetty, and I'm very glad you've found it
> so useful. I'm sure you'll also find jetty-7/8 useful for you too, I
> just need to get a handle on what exactly is not working for you.
>
> From what I gather, you want to be able to download a jetty distro to
> a location and then run it from outside that directory, at the same
> time passing in the location of some extra xml config files that you
> want used.  All meat-and-potatoes stuff for jetty so far.
>
> Now, it seems that in earlier versions of jetty, those extra xml
> config files on the command line could be specified as a relative
> path, but with jetty-7/8 we now expect them to be an absolute path.
> I'm not really clear on why you're not able to provide the absolute
> path ... but nevertheless, I will look at the code and see if we can
> change our search algorithm for the xml files on the command line to
> handle relative paths in the old way. In the meanwhile, if you can
> just plonk in the absolute path to the file then I'm pretty sure
> you'll be on your way quickly (BTW, you did see the porting page? I
> know it says jetty-7, but 7 and 8 are the same, with 8 having
> additional servlet 3.0 features). Here's the page :
> http://wiki.eclipse.org/Jetty/Starting/Porting_to_Jetty_7)
>
> Oh, and finally, this codehaus list has been superceeded by the
> Eclipse lists, as jetty moved to Eclipse from jetty-7 onwards. The new
> list locations are here:
> http://www.eclipse.org/jetty/mailinglists.php. You'll see more
> activity if you join those new lists.
>
>
> cheers,
> Jan
>
>
>
> On 28 February 2012 17:59, Kirk Pepperdine <[hidden email]> wrote:
>> Hi Jan,
>>
>> I use Jetty in my performance tuning course and as such, it gets installed on what ever and where ever. I use it for a number of different demonstrations and each demo is likely to have a different configuration. All workable with 6.x except that when I went to add in JPDC connection pooling I found bugs in the JNDI lookups which forced the move forward. That migration resulted in logging being the primary bottleneck in the application which was an unwanted side effect (i.e. a nice find by not fixable in the context of the course). Hence the motivation to move to the latest version.
>>
>> Jetty has worked brilliantly for me over a number of years. It's always been stable across different releases of the JDK from early 1.4.2 right up until 1.6.0_29 and 7.0. It has always responded well to the performance enhancements in each newer version of the JDK and I've never had a problem getting it to work on dozens and dozens of different OS/hardware combinations including a number of juiced up versions of Linux and Windows (think banks and security). My one experience with GlassFish with a group of 140 people was a disaster. Sun talked me into using GF for that event and I'm kicking myself for giving in and not using Jetty as the GF problem never would have happened with Jetty. So, I'm not so happy at the moment with the thought of having to hack about to get something that is pretty simple to work. I was thinking of hacking in a fix to the start.jar but quite frankly, a move to tomcat would be much quicker. It's just that they diddle with java.io.dir which creates other challenges when working with larger groups.
>>
>> Regards,
>> Kirk
>>
>> On 2012-02-28, at 7:08 AM, Jan Bartel wrote:
>>
>>> Kirk,
>>>
>>> Not sure of the problem? Why can't you specify the absolute location
>>> of the xml file on the command line, rather than the relative one
>>> you've got now?
>>>
>>> Jan
>>>
>>> On 28 February 2012 16:46, Kirk Pepperdine <[hidden email]> wrote:
>>>> Hi Jan,
>>>>
>>>> Thanks for the quick response. I've been looking at documentation but not of it applied to my particular deployment requirements and I hadn't run into these pages so thanks for the links. The later one looks particularly useful.
>>>> On 2012-02-28, at 6:27 AM, Jan Bartel wrote:
>>>>
>>>>>
>>>>>
>>>>> Having said that, checking the code, if you want to supply the xml
>>>>> files on the command line, then they have to be an absolute path, or
>>>>> else jetty will try to find the relative path inside $jetty.home. Not
>>>>> sure at this point if that's a difference between 6 and 7/8, but it
>>>>> seems that is your stumbling block.
>>>>
>>>> With 6 start.jar read the jetty.xml file supplied without munging in the $jetty.home setting so this is a difference between 6 and 8.
>>>>
>>>> What forced the move is that 6.1.24 is that I ran into a JNDI bug. Fixed in later version of 6 introduced a bottleneck on access log logging. That motivated the move to 8 but unless I can generate a work-around, this will be a complete show-stopper.
>>>>
>>>>>
>>>>> cheers
>>>>> Jan
>>>>>
>>>>> On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>>>>>>
>>>>>> Here is the cmd line. (OSX but Linux and Windows will also be used).
>>>>>>
>>>>>> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
>>>>>> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>>>>>>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>>>>>>
>>>>>> Regards,
>>>>>> Kirk
>>>>>>
>>>>>>
>>>>>> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>>>>>>
>>>>>>> Hi Petr and Jesse,
>>>>>>>
>>>>>>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>>>>>>> requested and assisted us with it.
>>>>>>> Here is the bug where the work was done:
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>>>>>>
>>>>>>> I am not sure where the import for org.mortbay would come.
>>>>>>> Please let us know if we need to change something in the build of
>>>>>>> "jetty-all-server" to fix it or accommodate your situation.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Hugues.
>>>>>>>
>>>>>>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>>>>>>> <[hidden email]> wrote:
>>>>>>>> if you are close with your approach I don't see it being a bad thing
>>>>>>>>
>>>>>>>> I had thought the aggregates were 'close' for osgi and were being
>>>>>>>> adjusted for supporting that, at least at some point in their history
>>>>>>>> they were
>>>>>>>>
>>>>>>>> since your trying to generate a large bundle of your own then I would
>>>>>>>> probably look at using the same sort of dependency setup as the
>>>>>>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>>>>>>
>>>>>>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> jesse
>>>>>>>>
>>>>>>>> --
>>>>>>>> jesse mcconnell
>>>>>>>> [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>>>>>>> Really!
>>>>>>>>>
>>>>>>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>>>>>>> and then add my own bundle it simply works...:)
>>>>>>>>>
>>>>>>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>>>>>>> fails.
>>>>>>>>>
>>>>>>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>>>>>>> for Jetty.
>>>>>>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>>>>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Kirk Pepperdine
Hi Jan,

Thanks for looking into this and I'll join the other mailing list.

Using absolute paths is difficult because I have to distribute a working bundle to an  unknown machine with an unknown configuration (outside of the bundle) to a variety of operating systems.  To those machines I need to deliver several configurations all of which will be used by the end user as we move from demonstration to demonstration. There are enough things to go wrong already, I wouldn't like to take on more risk by having people change the configurations to match their environment. I could work out scripts to do this but since windows is a target platform and the DOS/NT file system mess is still a mess it's just an opportunity to have to fix things in the field that have never been a problem. I require something that just works and in this case the least fragile way of going is relative pathing.

I looked at the classes in startup and was about to hack in a new property called jetty.conf. That would point to a local version of the $JETTY_HOME/etc files while leaving the $JETTY_HOME variable undisturbed. There is also a the property in the config files that I would change to $JETTY_CONF.  By default, $JETTY_CONF = $JETTY_HOME. There might be other problems in there that aren't currently visible but I'll spend a few cycles hacking this up.

Regards,
Kirk

On 2012-02-29, at 12:40 AM, Jan Bartel wrote:

> Hi again Kirk,
>
> I've checked the code and I agree we can add back in the relative path
> handling. I've raised the following bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=372806
>
> In the meanwhile, its the absolute path on the command line.
>
> cheers
> Jan
>
> On 29 February 2012 10:32, Jan Bartel <[hidden email]> wrote:
>> Hi Kirk,
>>
>> Thanks for the praise about jetty, and I'm very glad you've found it
>> so useful. I'm sure you'll also find jetty-7/8 useful for you too, I
>> just need to get a handle on what exactly is not working for you.
>>
>> From what I gather, you want to be able to download a jetty distro to
>> a location and then run it from outside that directory, at the same
>> time passing in the location of some extra xml config files that you
>> want used.  All meat-and-potatoes stuff for jetty so far.
>>
>> Now, it seems that in earlier versions of jetty, those extra xml
>> config files on the command line could be specified as a relative
>> path, but with jetty-7/8 we now expect them to be an absolute path.
>> I'm not really clear on why you're not able to provide the absolute
>> path ... but nevertheless, I will look at the code and see if we can
>> change our search algorithm for the xml files on the command line to
>> handle relative paths in the old way. In the meanwhile, if you can
>> just plonk in the absolute path to the file then I'm pretty sure
>> you'll be on your way quickly (BTW, you did see the porting page? I
>> know it says jetty-7, but 7 and 8 are the same, with 8 having
>> additional servlet 3.0 features). Here's the page :
>> http://wiki.eclipse.org/Jetty/Starting/Porting_to_Jetty_7)
>>
>> Oh, and finally, this codehaus list has been superceeded by the
>> Eclipse lists, as jetty moved to Eclipse from jetty-7 onwards. The new
>> list locations are here:
>> http://www.eclipse.org/jetty/mailinglists.php. You'll see more
>> activity if you join those new lists.
>>
>>
>> cheers,
>> Jan
>>
>>
>>
>> On 28 February 2012 17:59, Kirk Pepperdine <[hidden email]> wrote:
>>> Hi Jan,
>>>
>>> I use Jetty in my performance tuning course and as such, it gets installed on what ever and where ever. I use it for a number of different demonstrations and each demo is likely to have a different configuration. All workable with 6.x except that when I went to add in JPDC connection pooling I found bugs in the JNDI lookups which forced the move forward. That migration resulted in logging being the primary bottleneck in the application which was an unwanted side effect (i.e. a nice find by not fixable in the context of the course). Hence the motivation to move to the latest version.
>>>
>>> Jetty has worked brilliantly for me over a number of years. It's always been stable across different releases of the JDK from early 1.4.2 right up until 1.6.0_29 and 7.0. It has always responded well to the performance enhancements in each newer version of the JDK and I've never had a problem getting it to work on dozens and dozens of different OS/hardware combinations including a number of juiced up versions of Linux and Windows (think banks and security). My one experience with GlassFish with a group of 140 people was a disaster. Sun talked me into using GF for that event and I'm kicking myself for giving in and not using Jetty as the GF problem never would have happened with Jetty. So, I'm not so happy at the moment with the thought of having to hack about to get something that is pretty simple to work. I was thinking of hacking in a fix to the start.jar but quite frankly, a move to tomcat would be much quicker. It's just that they diddle with java.io.dir which creates other challenges when working with larger groups.
>>>
>>> Regards,
>>> Kirk
>>>
>>> On 2012-02-28, at 7:08 AM, Jan Bartel wrote:
>>>
>>>> Kirk,
>>>>
>>>> Not sure of the problem? Why can't you specify the absolute location
>>>> of the xml file on the command line, rather than the relative one
>>>> you've got now?
>>>>
>>>> Jan
>>>>
>>>> On 28 February 2012 16:46, Kirk Pepperdine <[hidden email]> wrote:
>>>>> Hi Jan,
>>>>>
>>>>> Thanks for the quick response. I've been looking at documentation but not of it applied to my particular deployment requirements and I hadn't run into these pages so thanks for the links. The later one looks particularly useful.
>>>>> On 2012-02-28, at 6:27 AM, Jan Bartel wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Having said that, checking the code, if you want to supply the xml
>>>>>> files on the command line, then they have to be an absolute path, or
>>>>>> else jetty will try to find the relative path inside $jetty.home. Not
>>>>>> sure at this point if that's a difference between 6 and 7/8, but it
>>>>>> seems that is your stumbling block.
>>>>>
>>>>> With 6 start.jar read the jetty.xml file supplied without munging in the $jetty.home setting so this is a difference between 6 and 8.
>>>>>
>>>>> What forced the move is that 6.1.24 is that I ran into a JNDI bug. Fixed in later version of 6 introduced a bottleneck on access log logging. That motivated the move to 8 but unless I can generate a work-around, this will be a complete show-stopper.
>>>>>
>>>>>>
>>>>>> cheers
>>>>>> Jan
>>>>>>
>>>>>> On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>>>>>>>
>>>>>>> Here is the cmd line. (OSX but Linux and Windows will also be used).
>>>>>>>
>>>>>>> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
>>>>>>> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>>>>>>>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Kirk
>>>>>>>
>>>>>>>
>>>>>>> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>>>>>>>
>>>>>>>> Hi Petr and Jesse,
>>>>>>>>
>>>>>>>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>>>>>>>> requested and assisted us with it.
>>>>>>>> Here is the bug where the work was done:
>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>>>>>>>
>>>>>>>> I am not sure where the import for org.mortbay would come.
>>>>>>>> Please let us know if we need to change something in the build of
>>>>>>>> "jetty-all-server" to fix it or accommodate your situation.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Hugues.
>>>>>>>>
>>>>>>>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>>>>>>>> <[hidden email]> wrote:
>>>>>>>>> if you are close with your approach I don't see it being a bad thing
>>>>>>>>>
>>>>>>>>> I had thought the aggregates were 'close' for osgi and were being
>>>>>>>>> adjusted for supporting that, at least at some point in their history
>>>>>>>>> they were
>>>>>>>>>
>>>>>>>>> since your trying to generate a large bundle of your own then I would
>>>>>>>>> probably look at using the same sort of dependency setup as the
>>>>>>>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>>>>>>>
>>>>>>>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>>>>>>>
>>>>>>>>> cheers,
>>>>>>>>> jesse
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> jesse mcconnell
>>>>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>>>>>>>> Really!
>>>>>>>>>>
>>>>>>>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>>>>>>>> and then add my own bundle it simply works...:)
>>>>>>>>>>
>>>>>>>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>>>>>>>> fails.
>>>>>>>>>>
>>>>>>>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>>>>>>>> for Jetty.
>>>>>>>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>>>>>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Jan Bartel-3
Hi Kirk,

I checked the fix in and it will be in 7.6.2 and 8.1.2, both due out
very soon  - next few days I expect.

Jan

On 29 February 2012 14:52, Kirk Pepperdine <[hidden email]> wrote:

> Hi Jan,
>
> Thanks for looking into this and I'll join the other mailing list.
>
> Using absolute paths is difficult because I have to distribute a working bundle to an  unknown machine with an unknown configuration (outside of the bundle) to a variety of operating systems.  To those machines I need to deliver several configurations all of which will be used by the end user as we move from demonstration to demonstration. There are enough things to go wrong already, I wouldn't like to take on more risk by having people change the configurations to match their environment. I could work out scripts to do this but since windows is a target platform and the DOS/NT file system mess is still a mess it's just an opportunity to have to fix things in the field that have never been a problem. I require something that just works and in this case the least fragile way of going is relative pathing.
>
> I looked at the classes in startup and was about to hack in a new property called jetty.conf. That would point to a local version of the $JETTY_HOME/etc files while leaving the $JETTY_HOME variable undisturbed. There is also a the property in the config files that I would change to $JETTY_CONF.  By default, $JETTY_CONF = $JETTY_HOME. There might be other problems in there that aren't currently visible but I'll spend a few cycles hacking this up.
>
> Regards,
> Kirk
>
> On 2012-02-29, at 12:40 AM, Jan Bartel wrote:
>
>> Hi again Kirk,
>>
>> I've checked the code and I agree we can add back in the relative path
>> handling. I've raised the following bug:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=372806
>>
>> In the meanwhile, its the absolute path on the command line.
>>
>> cheers
>> Jan
>>
>> On 29 February 2012 10:32, Jan Bartel <[hidden email]> wrote:
>>> Hi Kirk,
>>>
>>> Thanks for the praise about jetty, and I'm very glad you've found it
>>> so useful. I'm sure you'll also find jetty-7/8 useful for you too, I
>>> just need to get a handle on what exactly is not working for you.
>>>
>>> From what I gather, you want to be able to download a jetty distro to
>>> a location and then run it from outside that directory, at the same
>>> time passing in the location of some extra xml config files that you
>>> want used.  All meat-and-potatoes stuff for jetty so far.
>>>
>>> Now, it seems that in earlier versions of jetty, those extra xml
>>> config files on the command line could be specified as a relative
>>> path, but with jetty-7/8 we now expect them to be an absolute path.
>>> I'm not really clear on why you're not able to provide the absolute
>>> path ... but nevertheless, I will look at the code and see if we can
>>> change our search algorithm for the xml files on the command line to
>>> handle relative paths in the old way. In the meanwhile, if you can
>>> just plonk in the absolute path to the file then I'm pretty sure
>>> you'll be on your way quickly (BTW, you did see the porting page? I
>>> know it says jetty-7, but 7 and 8 are the same, with 8 having
>>> additional servlet 3.0 features). Here's the page :
>>> http://wiki.eclipse.org/Jetty/Starting/Porting_to_Jetty_7)
>>>
>>> Oh, and finally, this codehaus list has been superceeded by the
>>> Eclipse lists, as jetty moved to Eclipse from jetty-7 onwards. The new
>>> list locations are here:
>>> http://www.eclipse.org/jetty/mailinglists.php. You'll see more
>>> activity if you join those new lists.
>>>
>>>
>>> cheers,
>>> Jan
>>>
>>>
>>>
>>> On 28 February 2012 17:59, Kirk Pepperdine <[hidden email]> wrote:
>>>> Hi Jan,
>>>>
>>>> I use Jetty in my performance tuning course and as such, it gets installed on what ever and where ever. I use it for a number of different demonstrations and each demo is likely to have a different configuration. All workable with 6.x except that when I went to add in JPDC connection pooling I found bugs in the JNDI lookups which forced the move forward. That migration resulted in logging being the primary bottleneck in the application which was an unwanted side effect (i.e. a nice find by not fixable in the context of the course). Hence the motivation to move to the latest version.
>>>>
>>>> Jetty has worked brilliantly for me over a number of years. It's always been stable across different releases of the JDK from early 1.4.2 right up until 1.6.0_29 and 7.0. It has always responded well to the performance enhancements in each newer version of the JDK and I've never had a problem getting it to work on dozens and dozens of different OS/hardware combinations including a number of juiced up versions of Linux and Windows (think banks and security). My one experience with GlassFish with a group of 140 people was a disaster. Sun talked me into using GF for that event and I'm kicking myself for giving in and not using Jetty as the GF problem never would have happened with Jetty. So, I'm not so happy at the moment with the thought of having to hack about to get something that is pretty simple to work. I was thinking of hacking in a fix to the start.jar but quite frankly, a move to tomcat would be much quicker. It's just that they diddle with java.io.dir which creates other challenges when working with larger groups.
>>>>
>>>> Regards,
>>>> Kirk
>>>>
>>>> On 2012-02-28, at 7:08 AM, Jan Bartel wrote:
>>>>
>>>>> Kirk,
>>>>>
>>>>> Not sure of the problem? Why can't you specify the absolute location
>>>>> of the xml file on the command line, rather than the relative one
>>>>> you've got now?
>>>>>
>>>>> Jan
>>>>>
>>>>> On 28 February 2012 16:46, Kirk Pepperdine <[hidden email]> wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> Thanks for the quick response. I've been looking at documentation but not of it applied to my particular deployment requirements and I hadn't run into these pages so thanks for the links. The later one looks particularly useful.
>>>>>> On 2012-02-28, at 6:27 AM, Jan Bartel wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Having said that, checking the code, if you want to supply the xml
>>>>>>> files on the command line, then they have to be an absolute path, or
>>>>>>> else jetty will try to find the relative path inside $jetty.home. Not
>>>>>>> sure at this point if that's a difference between 6 and 7/8, but it
>>>>>>> seems that is your stumbling block.
>>>>>>
>>>>>> With 6 start.jar read the jetty.xml file supplied without munging in the $jetty.home setting so this is a difference between 6 and 8.
>>>>>>
>>>>>> What forced the move is that 6.1.24 is that I ran into a JNDI bug. Fixed in later version of 6 introduced a bottleneck on access log logging. That motivated the move to 8 but unless I can generate a work-around, this will be a complete show-stopper.
>>>>>>
>>>>>>>
>>>>>>> cheers
>>>>>>> Jan
>>>>>>>
>>>>>>> On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>>>>>>>>
>>>>>>>> Here is the cmd line. (OSX but Linux and Windows will also be used).
>>>>>>>>
>>>>>>>> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
>>>>>>>> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>>>>>>>>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Kirk
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>>>>>>>>
>>>>>>>>> Hi Petr and Jesse,
>>>>>>>>>
>>>>>>>>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>>>>>>>>> requested and assisted us with it.
>>>>>>>>> Here is the bug where the work was done:
>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>>>>>>>>
>>>>>>>>> I am not sure where the import for org.mortbay would come.
>>>>>>>>> Please let us know if we need to change something in the build of
>>>>>>>>> "jetty-all-server" to fix it or accommodate your situation.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Hugues.
>>>>>>>>>
>>>>>>>>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>>>>>>>>> <[hidden email]> wrote:
>>>>>>>>>> if you are close with your approach I don't see it being a bad thing
>>>>>>>>>>
>>>>>>>>>> I had thought the aggregates were 'close' for osgi and were being
>>>>>>>>>> adjusted for supporting that, at least at some point in their history
>>>>>>>>>> they were
>>>>>>>>>>
>>>>>>>>>> since your trying to generate a large bundle of your own then I would
>>>>>>>>>> probably look at using the same sort of dependency setup as the
>>>>>>>>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>>>>>>>>
>>>>>>>>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>>>>>>>>
>>>>>>>>>> cheers,
>>>>>>>>>> jesse
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> jesse mcconnell
>>>>>>>>>> [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>>>>>>>>> Really!
>>>>>>>>>>>
>>>>>>>>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>>>>>>>>> and then add my own bundle it simply works...:)
>>>>>>>>>>>
>>>>>>>>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>>>>>>>>> fails.
>>>>>>>>>>>
>>>>>>>>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>>>>>>>>> for Jetty.
>>>>>>>>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>>>>>>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Kirk Pepperdine
Hi Jan,

Wow, that was quick. I was just about to dig into the start.jar. I might sort out how to build the 8.1.2 myself so I can start testing.

Regards,
Kirk

On 2012-02-29, at 8:51 AM, Jan Bartel wrote:

> Hi Kirk,
>
> I checked the fix in and it will be in 7.6.2 and 8.1.2, both due out
> very soon  - next few days I expect.
>
> Jan
>
> On 29 February 2012 14:52, Kirk Pepperdine <[hidden email]> wrote:
>> Hi Jan,
>>
>> Thanks for looking into this and I'll join the other mailing list.
>>
>> Using absolute paths is difficult because I have to distribute a working bundle to an  unknown machine with an unknown configuration (outside of the bundle) to a variety of operating systems.  To those machines I need to deliver several configurations all of which will be used by the end user as we move from demonstration to demonstration. There are enough things to go wrong already, I wouldn't like to take on more risk by having people change the configurations to match their environment. I could work out scripts to do this but since windows is a target platform and the DOS/NT file system mess is still a mess it's just an opportunity to have to fix things in the field that have never been a problem. I require something that just works and in this case the least fragile way of going is relative pathing.
>>
>> I looked at the classes in startup and was about to hack in a new property called jetty.conf. That would point to a local version of the $JETTY_HOME/etc files while leaving the $JETTY_HOME variable undisturbed. There is also a the property in the config files that I would change to $JETTY_CONF.  By default, $JETTY_CONF = $JETTY_HOME. There might be other problems in there that aren't currently visible but I'll spend a few cycles hacking this up.
>>
>> Regards,
>> Kirk
>>
>> On 2012-02-29, at 12:40 AM, Jan Bartel wrote:
>>
>>> Hi again Kirk,
>>>
>>> I've checked the code and I agree we can add back in the relative path
>>> handling. I've raised the following bug:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=372806
>>>
>>> In the meanwhile, its the absolute path on the command line.
>>>
>>> cheers
>>> Jan
>>>
>>> On 29 February 2012 10:32, Jan Bartel <[hidden email]> wrote:
>>>> Hi Kirk,
>>>>
>>>> Thanks for the praise about jetty, and I'm very glad you've found it
>>>> so useful. I'm sure you'll also find jetty-7/8 useful for you too, I
>>>> just need to get a handle on what exactly is not working for you.
>>>>
>>>> From what I gather, you want to be able to download a jetty distro to
>>>> a location and then run it from outside that directory, at the same
>>>> time passing in the location of some extra xml config files that you
>>>> want used.  All meat-and-potatoes stuff for jetty so far.
>>>>
>>>> Now, it seems that in earlier versions of jetty, those extra xml
>>>> config files on the command line could be specified as a relative
>>>> path, but with jetty-7/8 we now expect them to be an absolute path.
>>>> I'm not really clear on why you're not able to provide the absolute
>>>> path ... but nevertheless, I will look at the code and see if we can
>>>> change our search algorithm for the xml files on the command line to
>>>> handle relative paths in the old way. In the meanwhile, if you can
>>>> just plonk in the absolute path to the file then I'm pretty sure
>>>> you'll be on your way quickly (BTW, you did see the porting page? I
>>>> know it says jetty-7, but 7 and 8 are the same, with 8 having
>>>> additional servlet 3.0 features). Here's the page :
>>>> http://wiki.eclipse.org/Jetty/Starting/Porting_to_Jetty_7)
>>>>
>>>> Oh, and finally, this codehaus list has been superceeded by the
>>>> Eclipse lists, as jetty moved to Eclipse from jetty-7 onwards. The new
>>>> list locations are here:
>>>> http://www.eclipse.org/jetty/mailinglists.php. You'll see more
>>>> activity if you join those new lists.
>>>>
>>>>
>>>> cheers,
>>>> Jan
>>>>
>>>>
>>>>
>>>> On 28 February 2012 17:59, Kirk Pepperdine <[hidden email]> wrote:
>>>>> Hi Jan,
>>>>>
>>>>> I use Jetty in my performance tuning course and as such, it gets installed on what ever and where ever. I use it for a number of different demonstrations and each demo is likely to have a different configuration. All workable with 6.x except that when I went to add in JPDC connection pooling I found bugs in the JNDI lookups which forced the move forward. That migration resulted in logging being the primary bottleneck in the application which was an unwanted side effect (i.e. a nice find by not fixable in the context of the course). Hence the motivation to move to the latest version.
>>>>>
>>>>> Jetty has worked brilliantly for me over a number of years. It's always been stable across different releases of the JDK from early 1.4.2 right up until 1.6.0_29 and 7.0. It has always responded well to the performance enhancements in each newer version of the JDK and I've never had a problem getting it to work on dozens and dozens of different OS/hardware combinations including a number of juiced up versions of Linux and Windows (think banks and security). My one experience with GlassFish with a group of 140 people was a disaster. Sun talked me into using GF for that event and I'm kicking myself for giving in and not using Jetty as the GF problem never would have happened with Jetty. So, I'm not so happy at the moment with the thought of having to hack about to get something that is pretty simple to work. I was thinking of hacking in a fix to the start.jar but quite frankly, a move to tomcat would be much quicker. It's just that they diddle with java.io.dir which creates other challenges when working with larger groups.
>>>>>
>>>>> Regards,
>>>>> Kirk
>>>>>
>>>>> On 2012-02-28, at 7:08 AM, Jan Bartel wrote:
>>>>>
>>>>>> Kirk,
>>>>>>
>>>>>> Not sure of the problem? Why can't you specify the absolute location
>>>>>> of the xml file on the command line, rather than the relative one
>>>>>> you've got now?
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>> On 28 February 2012 16:46, Kirk Pepperdine <[hidden email]> wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> Thanks for the quick response. I've been looking at documentation but not of it applied to my particular deployment requirements and I hadn't run into these pages so thanks for the links. The later one looks particularly useful.
>>>>>>> On 2012-02-28, at 6:27 AM, Jan Bartel wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Having said that, checking the code, if you want to supply the xml
>>>>>>>> files on the command line, then they have to be an absolute path, or
>>>>>>>> else jetty will try to find the relative path inside $jetty.home. Not
>>>>>>>> sure at this point if that's a difference between 6 and 7/8, but it
>>>>>>>> seems that is your stumbling block.
>>>>>>>
>>>>>>> With 6 start.jar read the jetty.xml file supplied without munging in the $jetty.home setting so this is a difference between 6 and 8.
>>>>>>>
>>>>>>> What forced the move is that 6.1.24 is that I ran into a JNDI bug. Fixed in later version of 6 introduced a bottleneck on access log logging. That motivated the move to 8 but unless I can generate a work-around, this will be a complete show-stopper.
>>>>>>>
>>>>>>>>
>>>>>>>> cheers
>>>>>>>> Jan
>>>>>>>>
>>>>>>>> On 28 February 2012 15:18, Kirk Pepperdine <[hidden email]> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm trying to upgrade from Jetty 6.1.28 to the most recent release of 8.0. I've been trying to start the server with same layout as I used with the 6.1.* version where the jetty configuration used it separate from the install. For some reason, Jetty 8 can't find the config file. I'm not seeing anything in the documentation that suggests the startup mechanism has changed so I'm wondering what I'm missing. Hardcoding the path to jetty.xml gets past this issue but isn't an option in the intended deployment environments. Trying to sort out what has changed and what I'm missing.
>>>>>>>>>
>>>>>>>>> Here is the cmd line. (OSX but Linux and Windows will also be used).
>>>>>>>>>
>>>>>>>>> java -Djetty.home=../bin/jetty-distribution-8.1.1.v20120215 -jar ../bin/jetty-distribution-8.1.1.v20120215/start.jar jetty/etc/jetty.xml
>>>>>>>>> java.io.FileNotFoundException: Unable to find XML Config: jetty/etc/jetty.xml
>>>>>>>>>        at org.eclipse.jetty.start.Main.resolveXmlConfig(Main.java:661)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Kirk
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2012-02-28, at 2:46 AM, Hugues Malphettes wrote:
>>>>>>>>>
>>>>>>>>>> Hi Petr and Jesse,
>>>>>>>>>>
>>>>>>>>>> In fact one of the aggregate "jetty-all-server" is OSGi-abled. Dmytro
>>>>>>>>>> requested and assisted us with it.
>>>>>>>>>> Here is the bug where the work was done:
>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317222
>>>>>>>>>>
>>>>>>>>>> I am not sure where the import for org.mortbay would come.
>>>>>>>>>> Please let us know if we need to change something in the build of
>>>>>>>>>> "jetty-all-server" to fix it or accommodate your situation.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Hugues.
>>>>>>>>>>
>>>>>>>>>> On Mon, Feb 27, 2012 at 10:14 PM, Jesse McConnell
>>>>>>>>>> <[hidden email]> wrote:
>>>>>>>>>>> if you are close with your approach I don't see it being a bad thing
>>>>>>>>>>>
>>>>>>>>>>> I had thought the aggregates were 'close' for osgi and were being
>>>>>>>>>>> adjusted for supporting that, at least at some point in their history
>>>>>>>>>>> they were
>>>>>>>>>>>
>>>>>>>>>>> since your trying to generate a large bundle of your own then I would
>>>>>>>>>>> probably look at using the same sort of dependency setup as the
>>>>>>>>>>> aggregate pom and roll your own manifest, no reason that wouldn't work
>>>>>>>>>>>
>>>>>>>>>>> it will be 'un-osgi' but that isn't necessarily a bad thing :)
>>>>>>>>>>>
>>>>>>>>>>> cheers,
>>>>>>>>>>> jesse
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> jesse mcconnell
>>>>>>>>>>> [hidden email]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[hidden email]> wrote:
>>>>>>>>>>>> Really!
>>>>>>>>>>>>
>>>>>>>>>>>> That's odd, if I install the aggregate and a few other bundles into Felix
>>>>>>>>>>>> and then add my own bundle it simply works...:)
>>>>>>>>>>>>
>>>>>>>>>>>> However when putting the jetty bundle + a few others into my own bundle it
>>>>>>>>>>>> fails.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyways I'll drop that track and take a look at the "proper" OSGi bundles
>>>>>>>>>>>> for Jetty.
>>>>>>>>>>>> That's what I get for trying to save time with one big happy binary..:(
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> View this message in context: http://jetty.4.n6.nabble.com/Fail-to-embed-Jetty-in-a-bundle-tp4514503p4514912.html
>>>>>>>>>>>> Sent from the Jetty Support mailing list archive at Nabble.com.
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Kirk Pepperdine
In reply to this post by Jan Bartel-3
Hi,

I've trying to configure 8.1.2 to run with a webapp that I cannot keep in the distribution. I'm using the command line as follows.

java -Dapp.properties=webapp.properties -Djetty.home=../bin/jetty-distribution-8.1.2 -jar ../bin/jetty-distribution-8.1.2/start.jar ./jetty/etc/jetty.xml

The problem is in addition to scanning my webapp and context directories, it is also scanning the $JETTY_HOME/webapps and $JETTY_HOME/contexts first. This causes the script fails with a BindException: address already in use. If I switch ports on my listener then all is well. So the question is, how do I get jetty to not scan the configuration in the distribution. Note that I've gone through jetty-context.xml and jetty-webapps.xml to change the deployment directory to my local directory. Just having difficulty seeing what I've missed.


One other point,  when I run

java -Djetty.home=../bin/jetty-distribution-8.1.2 -jar ../bin/jetty-distribution-8.1.2/start.jar --help

from the same directory as I'm trying to run my webapp from (not the jetty distribution dir) I get the following output:

<loads of good stuff snipped out>

  The current start.ini arguments are:

java.lang.NullPointerException
        at org.eclipse.jetty.start.Main.loadStartIni(Main.java:1053)
        at org.eclipse.jetty.start.Main.usage(Main.java:384)
        at org.eclipse.jetty.start.Main.start(Main.java:517)
        at org.eclipse.jetty.start.Main.main(Main.java:82)

<good stuff snipped out>


Appreciate any pointers.

Kind regards,
Kirk Pepperdine
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jetty 8.0

Jan Bartel-3
Kirk,

Fixed the NPE with the start line:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=375490

Are you sure you haven't got $JETTY_HOME/webapps and
$JETTY_HOME/contexts configured in one of the xml config files?

thanks
Jan

On 24 March 2012 20:43, Kirk Pepperdine <[hidden email]> wrote:

> Hi,
>
> I've trying to configure 8.1.2 to run with a webapp that I cannot keep in the distribution. I'm using the command line as follows.
>
> java -Dapp.properties=webapp.properties -Djetty.home=../bin/jetty-distribution-8.1.2 -jar ../bin/jetty-distribution-8.1.2/start.jar ./jetty/etc/jetty.xml
>
> The problem is in addition to scanning my webapp and context directories, it is also scanning the $JETTY_HOME/webapps and $JETTY_HOME/contexts first. This causes the script fails with a BindException: address already in use. If I switch ports on my listener then all is well. So the question is, how do I get jetty to not scan the configuration in the distribution. Note that I've gone through jetty-context.xml and jetty-webapps.xml to change the deployment directory to my local directory. Just having difficulty seeing what I've missed.
>
>
> One other point,  when I run
>
> java -Djetty.home=../bin/jetty-distribution-8.1.2 -jar ../bin/jetty-distribution-8.1.2/start.jar --help
>
> from the same directory as I'm trying to run my webapp from (not the jetty distribution dir) I get the following output:
>
> <loads of good stuff snipped out>
>
>  The current start.ini arguments are:
>
> java.lang.NullPointerException
>        at org.eclipse.jetty.start.Main.loadStartIni(Main.java:1053)
>        at org.eclipse.jetty.start.Main.usage(Main.java:384)
>        at org.eclipse.jetty.start.Main.start(Main.java:517)
>        at org.eclipse.jetty.start.Main.main(Main.java:82)
>
> <good stuff snipped out>
>
>
> Appreciate any pointers.
>
> Kind regards,
> Kirk Pepperdine
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email