Re: [jetty-user] Jetty 8.0

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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>>>>>> <[email protected]> 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
>>>>>>> [email protected]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Feb 27, 2012 at 08:07, Peter Nerg <[email protected]> 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