[JBoss-dev] Jetty
Title: Help Hello, Can JBoss2.4.7 and Jetty4.0.4 run under Windows 98 ? Thanks and Regards Huimin zhu
Re: [jetty-support] [Fwd: [JBoss-dev] Jetty addListener/removeListenerexception]
Thanks for the report,
this is already fixed in the latest releases of jetty and is in
Jboss 3.0.5 (but that has some other problems).
I recommend 3.0.6 which will be out very soon now.
regards
Jan Bartel wrote:> Fred,
I am forwarding your bug report to the Jetty support list where it
will receive more attention.
regards,
Jan
Original Message
Subject: [JBoss-dev] Jetty addListener/removeListener exception
Date: Tue, 21 Jan 2003 12:12:33 -0500
From: Fred Hartman <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Jboss-Development (E-mail) <[EMAIL PROTECTED]>
Using JBoss/Jetty 3.0.3. I have an MBean that dynamically adds and removes
SocketListeners from Jetty HttpServer.
It looks like there is a problem in
main/org/mortbay/http/SocketListener.java:
public void setHttpServer(HttpServer server)
{
Code.assertTrue(_server==null || _server==server,
"Cannot share listeners");
_server=server;
}
Should be
public void setHttpServer(HttpServer server)
{
Code.assertTrue(server==null || _server==null || _server==server,
"Cannot share listeners _server:"+_server+"
server:"+server);
_server=server;
}
because in main/org/mortbay/http/HttpServer.java addListener sets to a
non-null value, then removeListener sets to null, therefore do addListener
and then removeListener would always cause the assert to fail,
generating an
exception.
public HttpListener addListener(HttpListener listener)
throws IllegalArgumentException
{
listener.setHttpServer(this); //<<<--sets to non-null
_listeners.add(listener);
addComponent(listener);
return listener;
}
public void removeListener(HttpListener listener)
{
[clip]
_listeners.remove(l);
removeComponent(listener);
if (listener.isStarted())
try{listener.stop();}catch(InterruptedException
e){Code.warning(e);}
listener.setHttpServer(null); //<<<--sets back to null
[clip]
}
The same issue can be found in AJP13Listener.java.
Cheers,
Fred
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
For the latest information about Jetty, please see http://jetty.mortbay.org
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[Fwd: [JBoss-dev] Jetty addListener/removeListener exception]
Fred,
I am forwarding your bug report to the Jetty support list where it
will receive more attention.
regards,
Jan
Original Message
Subject: [JBoss-dev] Jetty addListener/removeListener exception
Date: Tue, 21 Jan 2003 12:12:33 -0500
From: Fred Hartman <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Jboss-Development (E-mail) <[EMAIL PROTECTED]>
Using JBoss/Jetty 3.0.3. I have an MBean that dynamically adds and removes
SocketListeners from Jetty HttpServer.
It looks like there is a problem in
main/org/mortbay/http/SocketListener.java:
public void setHttpServer(HttpServer server)
{
Code.assertTrue(_server==null || _server==server,
"Cannot share listeners");
_server=server;
}
Should be
public void setHttpServer(HttpServer server)
{
Code.assertTrue(server==null || _server==null || _server==server,
"Cannot share listeners _server:"+_server+"
server:"+server);
_server=server;
}
because in main/org/mortbay/http/HttpServer.java addListener sets to a
non-null value, then removeListener sets to null, therefore do addListener
and then removeListener would always cause the assert to fail,
generating an
exception.
public HttpListener addListener(HttpListener listener)
throws IllegalArgumentException
{
listener.setHttpServer(this); //<<<--sets to non-null
_listeners.add(listener);
addComponent(listener);
return listener;
}
public void removeListener(HttpListener listener)
{
[clip]
_listeners.remove(l);
removeComponent(listener);
if (listener.isStarted())
try{listener.stop();}catch(InterruptedException
e){Code.warning(e);}
listener.setHttpServer(null); //<<<--sets back to null
[clip]
}
The same issue can be found in AJP13Listener.java.
Cheers,
Fred
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty addListener/removeListener exception
Using JBoss/Jetty 3.0.3. I have an MBean that dynamically adds and removes
SocketListeners from Jetty HttpServer.
It looks like there is a problem in
main/org/mortbay/http/SocketListener.java:
public void setHttpServer(HttpServer server)
{
Code.assertTrue(_server==null || _server==server,
"Cannot share listeners");
_server=server;
}
Should be
public void setHttpServer(HttpServer server)
{
Code.assertTrue(server==null || _server==null || _server==server,
"Cannot share listeners _server:"+_server+"
server:"+server);
_server=server;
}
because in main/org/mortbay/http/HttpServer.java addListener sets to a
non-null value, then removeListener sets to null, therefore do addListener
and then removeListener would always cause the assert to fail, generating an
exception.
public HttpListener addListener(HttpListener listener)
throws IllegalArgumentException
{
listener.setHttpServer(this); //<<<--sets to non-null
_listeners.add(listener);
addComponent(listener);
return listener;
}
public void removeListener(HttpListener listener)
{
[clip]
_listeners.remove(l);
removeComponent(listener);
if (listener.isStarted())
try{listener.stop();}catch(InterruptedException
e){Code.warning(e);}
listener.setHttpServer(null); //<<<--sets back to null
[clip]
}
The same issue can be found in AJP13Listener.java.
Cheers,
Fred
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Greg is in Geneva for the week, but when he gets back, I'll ask him about this, Jules Jason Dillon wrote: Curious, but does the ajp (or whatever the apache connector is called) use many threads? If it does, then would it make sense to use nio there too? --jason On Thursday, November 21, 2002, at 08:33 AM, Greg Wilkins wrote: It's important to remember that the jetty nio implementation is not so much aimed at increasing socket performance - rather it's aim is to reduce the number of threads required by avoiding allocating threads to idle connections. This is more to avoid problems on operating systems that become undstable or non linear with large numbers of threads allocated. To date, the few organizations that have tried nio have eventually gone back to using the normal listener. It has helped while they had other threading issues with their systems. Once the OS/JVM have been patched properly, most big irons don't have too much trouble with large numbers of threads. Do selects over large number of sockets can prove to be more difficult for many OS's - even those with /dev/poll. Note that the nature of the servlet/filter API means that the true promise of NIO will never be realized until the spec is radically changed. Some servers may be able to use NIO to assist with serving static content, but if static content is to be made a special case, then you may as well serve it from a kernal server rather than java. While the servlet spec is in it's current revision, you will never get data streaming directly from a direct memory mapped buffer, out the http socket without touching user space. cheers Jules Gosnell wrote:> Anything is possible. Anyway, the standard Listener works fine in 1.4 and Greg has chosen to keep it on as the default and make a special case of the NIO Listener which, whilst giving better throughput at high volumes may actually be slower at low ones. I would rather stick with standard Jetty's approach, since I have enough branches to maintain already :-( If anyone wants to go this way badly, they can donate a PortableListener which wrap-n-delegates to a dynamically chosen Jetty Listener and I will alter the config to use this instead. Jules James Higginbotham wrote: Jules, Um... I hate to say this, but I think Weblogic works around this - it defaults to nio and backs off to its older non-nio.. They used to call it their "performance pack" before 1.4, and have since just swapped theirs for nio I think.. You said it was a static config, but I don't see why you can't abstract out the strategy, and back off to the default strategy if nio isn't available. Just a thought, and may sound simpler than the impl, not sure.. I haven't looked a the Jetty codebase in a while.. James -Original Message- From: Jules Gosnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:34 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky Peter Fagerlund wrote: torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... 1. Jetty's config is static - I could work around it 2. You would need to build to the LCD (1.3) and then do another build for optional 1.4 components... Or - we just live with it until we can force a move to 1.4, of course then we will have the same problem with 1.5... Software huh ! Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com __ __ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For mor
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Curious, but does the ajp (or whatever the apache connector is called) use many threads? If it does, then would it make sense to use nio there too? --jason On Thursday, November 21, 2002, at 08:33 AM, Greg Wilkins wrote: It's important to remember that the jetty nio implementation is not so much aimed at increasing socket performance - rather it's aim is to reduce the number of threads required by avoiding allocating threads to idle connections. This is more to avoid problems on operating systems that become undstable or non linear with large numbers of threads allocated. To date, the few organizations that have tried nio have eventually gone back to using the normal listener. It has helped while they had other threading issues with their systems. Once the OS/JVM have been patched properly, most big irons don't have too much trouble with large numbers of threads. Do selects over large number of sockets can prove to be more difficult for many OS's - even those with /dev/poll. Note that the nature of the servlet/filter API means that the true promise of NIO will never be realized until the spec is radically changed. Some servers may be able to use NIO to assist with serving static content, but if static content is to be made a special case, then you may as well serve it from a kernal server rather than java. While the servlet spec is in it's current revision, you will never get data streaming directly from a direct memory mapped buffer, out the http socket without touching user space. cheers Jules Gosnell wrote:> Anything is possible. Anyway, the standard Listener works fine in 1.4 and Greg has chosen to keep it on as the default and make a special case of the NIO Listener which, whilst giving better throughput at high volumes may actually be slower at low ones. I would rather stick with standard Jetty's approach, since I have enough branches to maintain already :-( If anyone wants to go this way badly, they can donate a PortableListener which wrap-n-delegates to a dynamically chosen Jetty Listener and I will alter the config to use this instead. Jules James Higginbotham wrote: Jules, Um... I hate to say this, but I think Weblogic works around this - it defaults to nio and backs off to its older non-nio.. They used to call it their "performance pack" before 1.4, and have since just swapped theirs for nio I think.. You said it was a static config, but I don't see why you can't abstract out the strategy, and back off to the default strategy if nio isn't available. Just a thought, and may sound simpler than the impl, not sure.. I haven't looked a the Jetty codebase in a while.. James -Original Message- From: Jules Gosnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:34 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky Peter Fagerlund wrote: torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... 1. Jetty's config is static - I could work around it 2. You would need to build to the LCD (1.3) and then do another build for optional 1.4 components... Or - we just live with it until we can force a move to 1.4, of course then we will have the same problem with 1.5... Software huh ! Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com __ __ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
It's important to remember that the jetty nio implementation is not so much aimed at increasing socket performance - rather it's aim is to reduce the number of threads required by avoiding allocating threads to idle connections. This is more to avoid problems on operating systems that become undstable or non linear with large numbers of threads allocated. To date, the few organizations that have tried nio have eventually gone back to using the normal listener. It has helped while they had other threading issues with their systems. Once the OS/JVM have been patched properly, most big irons don't have too much trouble with large numbers of threads. Do selects over large number of sockets can prove to be more difficult for many OS's - even those with /dev/poll. Note that the nature of the servlet/filter API means that the true promise of NIO will never be realized until the spec is radically changed. Some servers may be able to use NIO to assist with serving static content, but if static content is to be made a special case, then you may as well serve it from a kernal server rather than java. While the servlet spec is in it's current revision, you will never get data streaming directly from a direct memory mapped buffer, out the http socket without touching user space. cheers Jules Gosnell wrote:> Anything is possible. Anyway, the standard Listener works fine in 1.4 and Greg has chosen to keep it on as the default and make a special case of the NIO Listener which, whilst giving better throughput at high volumes may actually be slower at low ones. I would rather stick with standard Jetty's approach, since I have enough branches to maintain already :-( If anyone wants to go this way badly, they can donate a PortableListener which wrap-n-delegates to a dynamically chosen Jetty Listener and I will alter the config to use this instead. Jules James Higginbotham wrote: Jules, Um... I hate to say this, but I think Weblogic works around this - it defaults to nio and backs off to its older non-nio.. They used to call it their "performance pack" before 1.4, and have since just swapped theirs for nio I think.. You said it was a static config, but I don't see why you can't abstract out the strategy, and back off to the default strategy if nio isn't available. Just a thought, and may sound simpler than the impl, not sure.. I haven't looked a the Jetty codebase in a while.. James -Original Message- From: Jules Gosnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:34 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky Peter Fagerlund wrote: torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... 1. Jetty's config is static - I could work around it 2. You would need to build to the LCD (1.3) and then do another build for optional 1.4 components... Or - we just live with it until we can force a move to 1.4, of course then we will have the same problem with 1.5... Software huh ! Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com __ __ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com -- Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com --
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
On 21 Nov, Scott M Stark wrote: > I'll look into what the issues are with building under 1.4 and running with 1.3. >This should > be possible and is something we need to work towards. Great. As for the jaas stuff, I do think that it does not matter if the 1.3 jaas stuff is also build when building for 1.4.1 since jdk 1.4.1 will not use lib/jaas.xml at all, but its own version (exactly the same as the xml stuff - if you do not use the endorsed mechanism). //Peter > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, November 21, 2002 4:47 AM > Subject: Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky > > >> Right, we will always have this problem... is there a solution? I >> think we have to tools, basically interfaces and dynamic class loading >> ala factories... blah. >> >> >> --jason > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Anything is possible. Anyway, the standard Listener works fine in 1.4 and Greg has chosen to keep it on as the default and make a special case of the NIO Listener which, whilst giving better throughput at high volumes may actually be slower at low ones. I would rather stick with standard Jetty's approach, since I have enough branches to maintain already :-( If anyone wants to go this way badly, they can donate a PortableListener which wrap-n-delegates to a dynamically chosen Jetty Listener and I will alter the config to use this instead. Jules James Higginbotham wrote: Jules, Um... I hate to say this, but I think Weblogic works around this - it defaults to nio and backs off to its older non-nio.. They used to call it their "performance pack" before 1.4, and have since just swapped theirs for nio I think.. You said it was a static config, but I don't see why you can't abstract out the strategy, and back off to the default strategy if nio isn't available. Just a thought, and may sound simpler than the impl, not sure.. I haven't looked a the Jetty codebase in a while.. James -Original Message- From: Jules Gosnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:34 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky Peter Fagerlund wrote: torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... 1. Jetty's config is static - I could work around it 2. You would need to build to the LCD (1.3) and then do another build for optional 1.4 components... Or - we just live with it until we can force a move to 1.4, of course then we will have the same problem with 1.5... Software huh ! Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com __ __ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Jules, Um... I hate to say this, but I think Weblogic works around this - it defaults to nio and backs off to its older non-nio.. They used to call it their "performance pack" before 1.4, and have since just swapped theirs for nio I think.. You said it was a static config, but I don't see why you can't abstract out the strategy, and back off to the default strategy if nio isn't available. Just a thought, and may sound simpler than the impl, not sure.. I haven't looked a the Jetty codebase in a while.. James > -Original Message- > From: Jules Gosnell [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 21, 2002 6:34 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky > > > Peter Fagerlund wrote: > > > > > torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: > > > >> Fuck... how can we make one build work for both? > > > > > > Use a runtime switch ... > > 1. Jetty's config is static - I could work around it > 2. You would need to build to the LCD (1.3) and then do another build > for optional 1.4 components... > > > Or - we just live with it until we can force a move to 1.4, of course > then we will have the same problem with 1.5... > > Software huh ! > > Jules > > > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > __ > __ > This email has been scanned for all viruses by the MessageLabs SkyScan > service. For more information on a proactive anti-virus > service working > around the clock, around the globe, visit http://www.messagelabs.com > __ > __ > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
I'll look into what the issues are with building under 1.4 and running with 1.3. This should be possible and is something we need to work towards. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 21, 2002 4:47 AM Subject: Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky > Right, we will always have this problem... is there a solution? I > think we have to tools, basically interfaces and dynamic class loading > ala factories... blah. > > > --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Right, we will always have this problem... is there a solution? I think we have to tools, basically interfaces and dynamic class loading ala factories... blah. --jason On Thursday, November 21, 2002, at 04:34 AM, Jules Gosnell wrote: Peter Fagerlund wrote: torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... 1. Jetty's config is static - I could work around it 2. You would need to build to the LCD (1.3) and then do another build for optional 1.4 components... Or - we just live with it until we can force a move to 1.4, of course then we will have the same problem with 1.5... Software huh ! Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ _ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ___ _ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Um... so the phrase crack smoker comes to mind... anyone else? --jason On Thursday, November 21, 2002, at 04:24 AM, Peter Fagerlund wrote: Fuck... how can we make one build work for both? Use a runtime switch ... in a preprocessor ala xDoclet ? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Peter Fagerlund wrote: torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... 1. Jetty's config is static - I could work around it 2. You would need to build to the LCD (1.3) and then do another build for optional 1.4 components... Or - we just live with it until we can force a move to 1.4, of course then we will have the same problem with 1.5... Software huh ! Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Fuck... how can we make one build work for both? Use a runtime switch ... in a preprocessor ala xDoclet ? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Um ya, but how... if the JVM can not handle it then an app level system must be in place to load the version specific instance based on thr current JV<. Surely someone else has run into this problem and found a usable solution to it... anyone know? Or perhaps we are doomed to build for 1.3 and 1.4? That really seems anit-java i principal. --jason On Thursday, November 21, 2002, at 03:50 AM, Peter Fagerlund wrote: torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Fuck... how can we make one build work for both? --jason On Thursday, November 21, 2002, at 02:29 AM, [EMAIL PROTECTED] wrote: On 21 Nov, Jason Dillon wrote: Bah... this sucks. Can't we get one build to function for both? Or do we have to build a 1.3 and 1.4 version? Blah :( Its the same for jaas. A version build för 1.4 will NOT work on 1.3, because the JAAS classes will be missing! //Peter A side note, any reason why we do not start the nio and ajp (or whatever it is called) by default, then let users remove or uncomment to disabled. This might help catch such problems... note sure. --jason On Thursday, November 21, 2002, at 01:41 AM, Jules Gosnell wrote: Jason Dillon wrote: Looks like the Jetty NIO listener for JBoss 3.0.4 does not work out of the box (ie. simply uncommenting the nio listener def). --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development It is only available in a 1.4 build, and I assume (mother of all f*ck ups) that JBoss is built on a 1.3 JVM. Pull down a copy of Jetty-4.2.2 from SF and substitute the jars in your jbossweb.sar with the ones in this distro - It is built on 1.4 I'll put a comment in the jboss-service.xml about this - Thanks. Jules P.S. Building your own JBoss on 1.4 will not currently help, as I have not checked in the 1.4 code. _ __ _ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com _ __ _ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Jason Dillon wrote: The point is that you can't build OR run the NIO Listener under 1.3, since it uses stuff that doesn't appear until 1.4, so until JBoss moves to JVM>=1.4, it will have to remain commented out. As for the AJP Listener, this is shipped uncommented, isn't it? Jules Wait, do you mean that if built with 1.4 that it will function, and that 1.3 will behave. I think we need to get the system in such a state that we can build with the latest supported VM and produce a binary compatible with older releases... not sure what the details are involved though. Bah, fucking Java... write once, package a billion times --jason On Thursday, November 21, 2002, at 01:41 AM, Jules Gosnell wrote: Jason Dillon wrote: Looks like the Jetty NIO listener for JBoss 3.0.4 does not work out of the box (ie. simply uncommenting the nio listener def). --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development It is only available in a 1.4 build, and I assume (mother of all f*ck ups) that JBoss is built on a 1.3 JVM. Pull down a copy of Jetty-4.2.2 from SF and substitute the jars in your jbossweb.sar with the ones in this distro - It is built on 1.4 I'll put a comment in the jboss-service.xml about this - Thanks. Jules P.S. Building your own JBoss on 1.4 will not currently help, as I have not checked in the 1.4 code. ___ _ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ___ _ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
On 21 Nov, Jason Dillon wrote: > Bah... this sucks. Can't we get one build to function for both? Or do > we have to build a 1.3 and 1.4 version? Blah :( Its the same for jaas. A version build för 1.4 will NOT work on 1.3, because the JAAS classes will be missing! //Peter > > A side note, any reason why we do not start the nio and ajp (or > whatever it is called) by default, then let users remove or uncomment > to disabled. This might help catch such problems... note sure. > > --jason > > > On Thursday, November 21, 2002, at 01:41 AM, Jules Gosnell wrote: > >> Jason Dillon wrote: >> >>> Looks like the Jetty NIO listener for JBoss 3.0.4 does not work out >>> of the box (ie. simply uncommenting the nio listener def). >>> >>> --jason >>> >>> >>> >>> --- >>> This sf.net email is sponsored by:ThinkGeek >>> Welcome to geek heaven. >>> http://thinkgeek.com/sf >>> ___ >>> Jboss-development mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> It is only available in a 1.4 build, and I assume (mother of all f*ck >> ups) that JBoss is built on a 1.3 JVM. >> >> Pull down a copy of Jetty-4.2.2 from SF and substitute the jars in >> your jbossweb.sar with the ones in this distro - It is built on 1.4 >> >> I'll put a comment in the jboss-service.xml about this - Thanks. >> >> >> Jules >> >> P.S. >> >> Building your own JBoss on 1.4 will not currently help, as I have not >> checked in the 1.4 code. >> >> >> >> ___ >> _ >> This email has been scanned for all viruses by the MessageLabs SkyScan >> service. For more information on a proactive anti-virus service working >> around the clock, around the globe, visit http://www.messagelabs.com >> ___ >> _ >> >> >> --- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Wait, do you mean that if built with 1.4 that it will function, and that 1.3 will behave. I think we need to get the system in such a state that we can build with the latest supported VM and produce a binary compatible with older releases... not sure what the details are involved though. Bah, fucking Java... write once, package a billion times --jason On Thursday, November 21, 2002, at 01:41 AM, Jules Gosnell wrote: Jason Dillon wrote: Looks like the Jetty NIO listener for JBoss 3.0.4 does not work out of the box (ie. simply uncommenting the nio listener def). --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development It is only available in a 1.4 build, and I assume (mother of all f*ck ups) that JBoss is built on a 1.3 JVM. Pull down a copy of Jetty-4.2.2 from SF and substitute the jars in your jbossweb.sar with the ones in this distro - It is built on 1.4 I'll put a comment in the jboss-service.xml about this - Thanks. Jules P.S. Building your own JBoss on 1.4 will not currently help, as I have not checked in the 1.4 code. ___ _ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ___ _ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Bah... this sucks. Can't we get one build to function for both? Or do we have to build a 1.3 and 1.4 version? Blah :( A side note, any reason why we do not start the nio and ajp (or whatever it is called) by default, then let users remove or uncomment to disabled. This might help catch such problems... note sure. --jason On Thursday, November 21, 2002, at 01:41 AM, Jules Gosnell wrote: Jason Dillon wrote: Looks like the Jetty NIO listener for JBoss 3.0.4 does not work out of the box (ie. simply uncommenting the nio listener def). --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development It is only available in a 1.4 build, and I assume (mother of all f*ck ups) that JBoss is built on a 1.3 JVM. Pull down a copy of Jetty-4.2.2 from SF and substitute the jars in your jbossweb.sar with the ones in this distro - It is built on 1.4 I'll put a comment in the jboss-service.xml about this - Thanks. Jules P.S. Building your own JBoss on 1.4 will not currently help, as I have not checked in the 1.4 code. ___ _ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ___ _ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Jason Dillon wrote: Looks like the Jetty NIO listener for JBoss 3.0.4 does not work out of the box (ie. simply uncommenting the nio listener def). --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development It is only available in a 1.4 build, and I assume (mother of all f*ck ups) that JBoss is built on a 1.3 JVM. Pull down a copy of Jetty-4.2.2 from SF and substitute the jars in your jbossweb.sar with the ones in this distro - It is built on 1.4 I'll put a comment in the jboss-service.xml about this - Thanks. Jules P.S. Building your own JBoss on 1.4 will not currently help, as I have not checked in the 1.4 code. This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Looks like the Jetty NIO listener for JBoss 3.0.4 does not work out of the box (ie. simply uncommenting the nio listener def). --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty bug rear's it's head again
Ah .. With the old version of jetty you did not have to prefix the form-login-page with a '/'. If you include the slash it works. On Wed, 2002-10-30 at 14:56, Scott M Stark wrote: > You will have to be more specific because when I add this the following > to the jmx-console/WEB-INF/web.xml descriptor FORM based auth > works fine. > > > > HtmlAdaptor > An example security config that only allows users with the > role JBossAdmin to access the HTML JMX console web application > > /* > GET > POST > > > JBossAdmin > > > > > FORM > JBoss JMX Console > > /login.jsp > /loginFailed.jsp > > > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Dave Smith" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, October 29, 2002 6:07 PM > Subject: Re: [JBoss-dev] Jetty bug rear's it's head again > > > > Throw Form based authentication on the jmx-console in the default jboss > > setup. > > I'm sure you know the syntax ;-) > > > > > > > > --- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty bug rear's it's head again
You will have to be more specific because when I add this the following to the jmx-console/WEB-INF/web.xml descriptor FORM based auth works fine. HtmlAdaptor An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application /* GET POST JBossAdmin FORM JBoss JMX Console /login.jsp /loginFailed.jsp Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Dave Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 29, 2002 6:07 PM Subject: Re: [JBoss-dev] Jetty bug rear's it's head again > Throw Form based authentication on the jmx-console in the default jboss > setup. > I'm sure you know the syntax ;-) > > --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty bug rear's it's head again
Throw Form based authentication on the jmx-console in the default jboss setup. I'm sure you know the syntax ;-) Jules Gosnell wrote: Dave Smith wrote: JBOss 3.2 beta (CVS) If you are doing form based authenication you get a redirection error. ie when jetty goes to load the form page it thinks it need's to authorize this page .. goes into an endless loop and then you get an htp error. Jules? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development mail me a simple testcase and I'll sort it out. Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty bug rear's it's head again
Dave Smith wrote: JBOss 3.2 beta (CVS) If you are doing form based authenication you get a redirection error. ie when jetty goes to load the form page it thinks it need's to authorize this page .. goes into an endless loop and then you get an htp error. Jules? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development mail me a simple testcase and I'll sort it out. Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty bug rear's it's head again
JBOss 3.2 beta (CVS) If you are doing form based authenication you get a redirection error. ie when jetty goes to load the form page it thinks it need's to authorize this page .. goes into an endless loop and then you get an htp error. Jules? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty Integration
I just switched from using Tomcat to Jetty with all work (JBoss3.0.2 on w2k). I have noticed that hot deployments no longer work of webapps! Here's the error that I get: HTTP ERROR: 500 jzentry == 0, jzfile = 199988168, total = 56, name = C:\Documents and Settings\\Local Settings\Temp\Jetty__8080___\webapp\WEB-INF\lib\.jar, i = 45, message = invalid LOC header (bad signature) RequestURI=/request-authorization.jsp;jsessionid=h3pa6843hiot1 It appears that Jetty or maybe the Deployer is reusing the same directory in the temp dir and windows is not letting it delete the file. When i first noticed this problem my temp dir had like 20,000 files in it. Thus i'd assume that Tomcat used a different directory for each deployment. This seams like a much better approach then reusing the same dir, considering the problem with windows and deleting an inuse file. To solve this, I have tried deleting my ear instead of replacing it, but this didn't seam to help, as undeployments do not result in the temp directory getting cleaned up, or the app server releasing the lock on the file. I'm a bit of a hyper-deployer - I used to be able to run jboss for days straight in development. In the last day i've restarted about 40-50 times... Is this a bug that needs to be fixed? Or is there a confiruration change that I need to make? Any ideas? thanks. .peter **PLEASE NOTE: EFFECTIVE SEPTEMBER 2, 2002, OUR NEW MILWAUKEE OFFICE ADDRESS IS 3600 SOUTH LAKE DRIVE, ST. FRANCIS, WI 53235 AND OUR NEW MAIN PHONE NUMBER IS 414.294.7000** This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us.
Re: [JBoss-dev] Jetty won't start in current 3.0 build
Standalone Jetty has jar dependencies wired into it's MANIFEST.MFs.
These are not applicable to JBoss/Jetty
On my JVM simply altering 'Class-Path' to
'MortBay-StandAlone-ClasspPath' effectively commented these out in the
build process, preventing The JBoss ClassLoader moaning about unresolved
dependencies when it loaded the Jetty jars
Why this 'replace' task seems to be doing the replacement recursively, I
don't know - it doesn't happen to me. I built and ran the result on
RedHat/Sun-1.4 Branch_3_0/3_2 and HEAD before checking in.
I will revisit this.
Sorry for the inconvenience caused.
Jules
Scott M Stark wrote:
> I have tracked this down to an invalidate manifest header in the
>org.mortbay.jetty.jar:
>
> Manifest-Version: 1.0
> MortBay-StandAlone-MortBay-StandAlone-MortBay-StandAlone-MortBay-Stand
> Alone-Class-Path: javax.servlet.jar org.apache.jasper.jar ../ext/com.
> sun.net.ssl.jar
> Sealed: true
>
> I am seeing this bad header generated on Windows XP, but not Windows 2000. Apparently
> the token replacement is being done multiple times. Why is this needed? If I remove
>the
>
>
>
> line from the jetty/build.xml file the manifests are fine with the Class-Path
>attribute and
> the service starts up fine. I have commented this out from the build file for now.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
> - Original Message -
> From: "Scott M Stark" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, August 31, 2002 8:15 AM
> Subject: [JBoss-dev] Jetty won't start in current 3.0 build
>
>
>
>>Running the default config in a clean build of the 3.0 branch fails to start Jetty.
>Please
>>fix this:
>>
>>bin 257>run.sh
>>
>>
>>
>> JBoss Bootstrap Environment
>>
>> JBOSS_HOME: C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1
>>
>> JAVA: /usr/local/Java/jdk1.3.1_04/bin/java
>>
>> JAVA_OPTS: -server -Dprogram.name=run.sh
>>
>> CLASSPATH: C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1\bin\run.jar;C
>>:\usr\local\Java\jdk1.3.1_04\lib\tools.jar
>>
>>
>>
>>
>>08:03:26,493 INFO [Server] JBoss Release: JBoss-3.0.3RC1 CVSTag=Branch_3_0
>>08:03:26,503 INFO [Server] Home Dir:
>C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1
>>...
>>08:03:32,091 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/
>>Boss3.0/jboss-all/build/output/jboss-3.0.3RC1/server/default/deploy/jbossweb.sa/
>>08:03:32,562 ERROR [URLDeploymentScanner] Failed to deploy: org.jboss.deploymen
>>.scanner.URLDeploymentScanner$DeployedURL@b65d1a72{
>>url=file:/C:/usr/JBoss3.0/joss-all/build/output/jboss-3.0.3RC1/server/default/deploy/jbossweb.sar/,
> deploydLastModified=0 }
>>org.jboss.deployment.DeploymentException: instantiating org.jboss.jetty.JettySe
>>vice failed: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException; -
>>nested throwable: (RuntimeErrorException: instantiating org.jboss.jetty.JettySe
>>vice failed: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException
>>Cause: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException)
>>at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.jav:155)
>>at org.jboss.system.ServiceController.install(ServiceController.java:22)
>>at java.lang.reflect.Method.invoke(Native Method)
>>at
>org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBenDispatcher.java:284)
>>at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
>>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
>
>
>
>
>
> ---
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone? Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty won't start in current 3.0 build
I have tracked this down to an invalidate manifest header in the org.mortbay.jetty.jar:
Manifest-Version: 1.0
MortBay-StandAlone-MortBay-StandAlone-MortBay-StandAlone-MortBay-Stand
Alone-Class-Path: javax.servlet.jar org.apache.jasper.jar ../ext/com.
sun.net.ssl.jar
Sealed: true
I am seeing this bad header generated on Windows XP, but not Windows 2000. Apparently
the token replacement is being done multiple times. Why is this needed? If I remove the
line from the jetty/build.xml file the manifests are fine with the Class-Path
attribute and
the service starts up fine. I have commented this out from the build file for now.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Scott M Stark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 31, 2002 8:15 AM
Subject: [JBoss-dev] Jetty won't start in current 3.0 build
> Running the default config in a clean build of the 3.0 branch fails to start Jetty.
>Please
> fix this:
>
> bin 257>run.sh
>
>
>
> JBoss Bootstrap Environment
>
> JBOSS_HOME: C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1
>
> JAVA: /usr/local/Java/jdk1.3.1_04/bin/java
>
> JAVA_OPTS: -server -Dprogram.name=run.sh
>
> CLASSPATH: C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1\bin\run.jar;C
> :\usr\local\Java\jdk1.3.1_04\lib\tools.jar
>
>
>
>
> 08:03:26,493 INFO [Server] JBoss Release: JBoss-3.0.3RC1 CVSTag=Branch_3_0
> 08:03:26,503 INFO [Server] Home Dir:
>C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1
> ...
> 08:03:32,091 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/
> Boss3.0/jboss-all/build/output/jboss-3.0.3RC1/server/default/deploy/jbossweb.sa/
> 08:03:32,562 ERROR [URLDeploymentScanner] Failed to deploy: org.jboss.deploymen
> .scanner.URLDeploymentScanner$DeployedURL@b65d1a72{
>
>url=file:/C:/usr/JBoss3.0/joss-all/build/output/jboss-3.0.3RC1/server/default/deploy/jbossweb.sar/,
> deploydLastModified=0 }
> org.jboss.deployment.DeploymentException: instantiating org.jboss.jetty.JettySe
> vice failed: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException; -
> nested throwable: (RuntimeErrorException: instantiating org.jboss.jetty.JettySe
> vice failed: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException
> Cause: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException)
> at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.jav:155)
> at org.jboss.system.ServiceController.install(ServiceController.java:22)
> at java.lang.reflect.Method.invoke(Native Method)
> at
>org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBenDispatcher.java:284)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
> at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty won't start in current 3.0 build
Running the default config in a clean build of the 3.0 branch fails to start Jetty.
Please
fix this:
bin 257>run.sh
JBoss Bootstrap Environment
JBOSS_HOME: C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1
JAVA: /usr/local/Java/jdk1.3.1_04/bin/java
JAVA_OPTS: -server -Dprogram.name=run.sh
CLASSPATH: C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1\bin\run.jar;C
:\usr\local\Java\jdk1.3.1_04\lib\tools.jar
08:03:26,493 INFO [Server] JBoss Release: JBoss-3.0.3RC1 CVSTag=Branch_3_0
08:03:26,503 INFO [Server] Home Dir:
C:\usr\JBoss3.0\jboss-all\build\output\jboss-3.0.3RC1
...
08:03:32,091 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/
Boss3.0/jboss-all/build/output/jboss-3.0.3RC1/server/default/deploy/jbossweb.sa/
08:03:32,562 ERROR [URLDeploymentScanner] Failed to deploy: org.jboss.deploymen
.scanner.URLDeploymentScanner$DeployedURL@b65d1a72{
url=file:/C:/usr/JBoss3.0/joss-all/build/output/jboss-3.0.3RC1/server/default/deploy/jbossweb.sar/,
deploydLastModified=0 }
org.jboss.deployment.DeploymentException: instantiating org.jboss.jetty.JettySe
vice failed: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException; -
nested throwable: (RuntimeErrorException: instantiating org.jboss.jetty.JettySe
vice failed: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException
Cause: java.lang.NoClassDefFoundError: org/mortbay/util/MultiException)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.jav:155)
at org.jboss.system.ServiceController.install(ServiceController.java:22)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBenDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy3.install(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:209)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:755)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:615)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBenDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy4.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymetScanner.java:427)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDploymentScanner.java:648)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentcanner.java:499)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(bstractDeploymentScanner.java:261)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:64)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBenDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControler.java:967)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:396)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBenDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy3.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:249)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:802)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:564)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBenDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:221)
at org.jboss.Main.boot(Main.java:142)
at org.jboss.Main$1.run(Main.java:375)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
RuntimeErrorException: in
[JBoss-dev] Jetty packaging...
Jason, I've tried various deployment configurations with HEAD and Branch_3_0. The only one that I can get to work is the current one (packed or unpacked). If cfg and impl are not living in the same place, then I really don't care how Jetty is deployed. If you do, then you have my blessing - go in and do what you will. The changes that you will need to make are all in build/build.xml (not in the jetty tree) anyway - So I would rather you did it. Jules ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty jar file
exactly what is the problem ? have you mailed Greg/jetty-discuss ? have you tried the same code on Tomcat ? Jules lsanders wrote: >>Is there a particular issue that you are trying to resolve, or are you >>just a compulsive neophile :-) ? > > > Well, that and the fact that I am having problems with > request.getContextPath() that I'm hoping the latest Jetty fixes. It now > appears that it did not - oh well. > > > ___ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty jar file
> Is there a particular issue that you are trying to resolve, or are you > just a compulsive neophile :-) ? Well, that and the fact that I am having problems with request.getContextPath() that I'm hoping the latest Jetty fixes. It now appears that it did not - oh well. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty jar file
I just realised that my last posting was ambiguous It should have said - there are no issues - as far as I know... Jules lsanders wrote: > Is the org.mortbay.jetty.jar file swappable with the latest cvs builds > from mortbay? It seems to work for me, but I was wondering if there are > any known issues. > > > > Thanks > > > > -Larry > ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty jar file
Not as far as I know. Is there a particular issue that you are trying to resolve, or are you just a compulsive neophile :-) ? Jules lsanders wrote: > Is the org.mortbay.jetty.jar file swappable with the latest cvs builds > from mortbay? It seems to work for me, but I was wondering if there are > any known issues. > > > > Thanks > > > > -Larry > ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty jar file
Is the org.mortbay.jetty.jar file swappable with the latest cvs builds from mortbay? It seems to work for me, but I was wondering if there are any known issues. Thanks -Larry
Re: [jetty-discuss] Re: [JBoss-dev] Jetty NPE on undeployment ofjbosstest-web
I have added in CVS head support for the graceful shutdown of a context. If stats are on for a context (so that active sessions are being traced) and stop(true) is called instead of stop(), then the context immediately starts rejecting new requests but the stop call waits until all requests have completed before sending notifications to the context and returning. This is not yet the default behaivour, but you will be able test it out and see how it goes. You could make it the default for the jboss integeration. JMX MBeans have been updated accordingly. Jules Gosnell wrote: > Scott, > > This appears to be caused by a race between Jetty responding to the > request to the JSP and the testsuite undeploying it. > > Looking at my request and server logs I can see that a request was made > for include_ejb.jsp during the second before the call to undeploy > jbosstest-web.ear. > > It looks like, by the time Jetty has got the JSP compiled and tries to > run it, it has been undeployed. > > Jetty could handle this more gracefully - agreed (and we are thinking > about it). > > Is it possible that the testsuite is making it's requests asynchronously > and undeploying it's ear before all requests have finished ? > > > Jules > > > Scott M Stark wrote: > >>When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run against >>the 3.0 branch the undeployment of the war is causing the NPE shown here: >> >>17:38:01,062 INFO [MainDeployer] Undeployed >>file:/D:/usr/local/src/cvsroot/JBos >>s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear >>17:38:02,656 ERROR [STDERR] java.lang.NullPointerException >>17:38:02,656 ERROR [STDERR] at >>org.mortbay.jetty.servlet.ServletHandler$Cont >>ext.getResource(ServletHandler.java:910) >>17:38:02,671 ERROR [STDERR] at >>org.apache.jasper.JspEngineContext.getResourc >>e(JspEngineContext.java:366) >>17:38:02,671 ERROR [STDERR] at >>org.apache.jasper.compiler.JspCompiler.isOutD >>ated(JspCompiler.java:179) >>17:38:02,687 ERROR [STDERR] at >>org.apache.jasper.compiler.Compiler.compile(C >>ompiler.java:121) >>17:38:02,687 ERROR [STDERR] at >>org.apache.jasper.servlet.JspServlet.loadJSP( >>JspServlet.java:557) >>17:38:02,687 ERROR [STDERR] at >>org.apache.jasper.servlet.JspServlet$JspServl >>etWrapper.loadIfNecessary(JspServlet.java:177) >>17:38:02,703 ERROR [STDERR] at >>org.apache.jasper.servlet.JspServlet$JspServl >>etWrapper.service(JspServlet.java:189) >>17:38:02,703 ERROR [STDERR] at >>org.apache.jasper.servlet.JspServlet.serviceJ >>spFile(JspServlet.java:382) >>17:38:02,703 ERROR [STDERR] at >>org.apache.jasper.servlet.JspServlet.service( >>JspServlet.java:474) >>17:38:02,703 ERROR [STDERR] at >>javax.servlet.http.HttpServlet.service(HttpSe >>rvlet.java:853) >>17:38:02,703 ERROR [STDERR] at >>org.mortbay.jetty.servlet.ServletHolder.handl >>e(ServletHolder.java:326) >>17:38:02,718 ERROR [STDERR] at >>org.mortbay.jetty.servlet.Dispatcher.dispatch >>(Dispatcher.java:259) >>17:38:02,718 ERROR [STDERR] at >>org.mortbay.jetty.servlet.Dispatcher.include( >>Dispatcher.java:171) >>17:38:02,718 ERROR [STDERR] at >>org.apache.jasper.runtime.JspRuntimeLibrary.i >>nclude(JspRuntimeLibrary.java:820) >>17:38:02,718 ERROR [STDERR] at >>org.apache.jsp.include_0005fejb$jsp._jspServi >>ce(include_0005fejb$jsp.java:61) >>17:38:02,718 ERROR [STDERR] at >>org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) >>17:38:02,718 ERROR [STDERR] at >>javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >>17:38:02,734 ERROR [STDERR] at >>org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja >>va:202) >>17:38:02,734 ERROR [STDERR] at >>org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) >>17:38:02,734 ERROR [STDERR] at >>org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) >>17:38:02,734 ERROR [STDERR] at >>javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >>17:38:02,734 ERROR [STDERR] at >>org.mortbay.jetty.servlet.ServletHolder.handleServletHolder.java:326) >>17:38:02,750 ERROR [STDERR] at >>org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:595) >>17:38:02,750 ERROR [STDERR] at >>org.mortbay.http.HttpContext.handle(HttpContext.java:1357) >>17:38:02,750 ERROR [STDERR] at >>org.mortbay.http.HttpContext.handle(HttpContext.java:1309) >>17:38:02,750 ERROR [STDERR] at >>org.mortbay.http.HttpServer.service(HttpServer.java:744) >>17:38:02,750 ERROR [STDERR] at >>org.jboss.jetty.Jetty.service(Jetty.java:525) >>17:38:02,750 ERROR [STDERR] at >>org.mortbay.http.HttpConnection.service(HttpConnection.java:743) >>17:38:02,765 ERROR [STDERR] at >>org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) >>17:38:02,765 ERROR [STDERR] at >>org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) >>17:38:02,765 ERROR [STDERR] at >>org.mortbay.http.SocketListe
Re: [JBoss-dev] Jetty NPE on undeployment of jbosstest-web
Cheers, Scott, Jules Scott M Stark wrote: > The tests are at least reading the reply headers so maybe it is a race > between finishing writing the body. I'll make sure the testsuite does > read the complete reply and if that does not fix it reopen the subject. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Jules Gosnell" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Monday, May 20, 2002 6:42 AM > Subject: Re: [JBoss-dev] Jetty NPE on undeployment of jbosstest-web > > > >>I stuck a sleep() in before the undeploy and this seems to have >>worked-around the problem and thus confirmed my suspicion. >> >>It is showing up a further problem - though not in Jetty: >> >>13:30:14,538 INFO [EjbModule] Destroying >>13:30:14,600 ERROR [Log4jService$ThrowableListenerLoggingAdapter] >>unhandled throwable >>java.lang.NullPointerException >>at >> > > org.jboss.ejb.plugins.EntityInstanceCache.freeContext(EntityInstanceCache.ja > va:120) > >>at >> > > org.jboss.ejb.plugins.AbstractInstanceCache$1.execute(AbstractInstanceCache. > java:617) > >>at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:206) >>at java.lang.Thread.run(Thread.java:479) >>13:30:14,604 INFO [EjbModule] Remove JSR-77 EJB Module: >> > > jboss.management.single:J2EEApplication=jbosstest-web.ear,J2EEServer=Single, > j2eeType=EJBModule,name=cts.jar > >>13:30:14,605 INFO [EJBModule] Stopping >>13:30:14,605 INFO [EJBModule] Stopped >>13:30:14,605 INFO [EjbModule] Destroyed >> >> >>A sleep() is obviously not a decent solution. >> >> >>We can alter Jetty or alter the testsuite. >> >>Bearing in mind that modifying Jetty to finish up all requests before >>undeploying is a feature that we are looking at (along with holding up >>requests during a redeploy), but is not a quick bugfix I think that we >>should make a mental to explicitly test >>undeployment-whilst-processing-request at a later date and fix the >>testsuite to wait for all requests to return before undeploying. >> >>What are your thoughts ? >> >> >>Jules >> >> >> >> >>Jules Gosnell wrote: >> >>>Scott, >>> >>>This appears to be caused by a race between Jetty responding to the >>>request to the JSP and the testsuite undeploying it. >>> >>>Looking at my request and server logs I can see that a request was made >>>for include_ejb.jsp during the second before the call to undeploy >>>jbosstest-web.ear. >>> >>>It looks like, by the time Jetty has got the JSP compiled and tries to >>>run it, it has been undeployed. >>> >>>Jetty could handle this more gracefully - agreed (and we are thinking >>>about it). >>> >>>Is it possible that the testsuite is making it's requests asynchronously >>>and undeploying it's ear before all requests have finished ? >>> >>> >>>Jules >>> >>> >>>Scott M Stark wrote: >>> >>> >>>>When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run >>>>against >>>>the 3.0 branch the undeployment of the war is causing the NPE shown >>> > here: > >>>>17:38:01,062 INFO [MainDeployer] Undeployed >>>>file:/D:/usr/local/src/cvsroot/JBos >>>>s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear >>>>17:38:02,656 ERROR [STDERR] java.lang.NullPointerException >>>>17:38:02,656 ERROR [STDERR] at >>>>org.mortbay.jetty.servlet.ServletHandler$Cont >>>>ext.getResource(ServletHandler.java:910) >>>>17:38:02,671 ERROR [STDERR] at >>>>org.apache.jasper.JspEngineContext.getResourc >>>>e(JspEngineContext.java:366) >>>>17:38:02,671 ERROR [STDERR] at >>>>org.apache.jasper.compiler.JspCompiler.isOutD >>>>ated(JspCompiler.java:179) >>>>17:38:02,687 ERROR [STDERR] at >>>>org.apache.jasper.compiler.Compiler.compile(C >>>>ompiler.java:121) >>>>17:38:02,687 ERROR [STDERR] at >>>>org.apache.jasper.servlet.JspServlet.loadJSP( >>>>JspServlet.java:557) >>>>17:38:02,687 ERROR [STDERR] at >>>>org.apache.jasper.servlet.JspServlet$JspServl >>>>etWrapper.loadIfNecessary(JspServlet.java:177) >>>>17:38:02
Re: [JBoss-dev] Jetty NPE on undeployment of jbosstest-web
The tests are at least reading the reply headers so maybe it is a race between finishing writing the body. I'll make sure the testsuite does read the complete reply and if that does not fix it reopen the subject. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jules Gosnell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, May 20, 2002 6:42 AM Subject: Re: [JBoss-dev] Jetty NPE on undeployment of jbosstest-web > I stuck a sleep() in before the undeploy and this seems to have > worked-around the problem and thus confirmed my suspicion. > > It is showing up a further problem - though not in Jetty: > > 13:30:14,538 INFO [EjbModule] Destroying > 13:30:14,600 ERROR [Log4jService$ThrowableListenerLoggingAdapter] > unhandled throwable > java.lang.NullPointerException > at > org.jboss.ejb.plugins.EntityInstanceCache.freeContext(EntityInstanceCache.ja va:120) > at > org.jboss.ejb.plugins.AbstractInstanceCache$1.execute(AbstractInstanceCache. java:617) > at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:206) > at java.lang.Thread.run(Thread.java:479) > 13:30:14,604 INFO [EjbModule] Remove JSR-77 EJB Module: > jboss.management.single:J2EEApplication=jbosstest-web.ear,J2EEServer=Single, j2eeType=EJBModule,name=cts.jar > 13:30:14,605 INFO [EJBModule] Stopping > 13:30:14,605 INFO [EJBModule] Stopped > 13:30:14,605 INFO [EjbModule] Destroyed > > > A sleep() is obviously not a decent solution. > > > We can alter Jetty or alter the testsuite. > > Bearing in mind that modifying Jetty to finish up all requests before > undeploying is a feature that we are looking at (along with holding up > requests during a redeploy), but is not a quick bugfix I think that we > should make a mental to explicitly test > undeployment-whilst-processing-request at a later date and fix the > testsuite to wait for all requests to return before undeploying. > > What are your thoughts ? > > > Jules > > > > > Jules Gosnell wrote: > > Scott, > > > > This appears to be caused by a race between Jetty responding to the > > request to the JSP and the testsuite undeploying it. > > > > Looking at my request and server logs I can see that a request was made > > for include_ejb.jsp during the second before the call to undeploy > > jbosstest-web.ear. > > > > It looks like, by the time Jetty has got the JSP compiled and tries to > > run it, it has been undeployed. > > > > Jetty could handle this more gracefully - agreed (and we are thinking > > about it). > > > > Is it possible that the testsuite is making it's requests asynchronously > > and undeploying it's ear before all requests have finished ? > > > > > > Jules > > > > > > Scott M Stark wrote: > > > >> When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run > >> against > >> the 3.0 branch the undeployment of the war is causing the NPE shown here: > >> > >> 17:38:01,062 INFO [MainDeployer] Undeployed > >> file:/D:/usr/local/src/cvsroot/JBos > >> s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear > >> 17:38:02,656 ERROR [STDERR] java.lang.NullPointerException > >> 17:38:02,656 ERROR [STDERR] at > >> org.mortbay.jetty.servlet.ServletHandler$Cont > >> ext.getResource(ServletHandler.java:910) > >> 17:38:02,671 ERROR [STDERR] at > >> org.apache.jasper.JspEngineContext.getResourc > >> e(JspEngineContext.java:366) > >> 17:38:02,671 ERROR [STDERR] at > >> org.apache.jasper.compiler.JspCompiler.isOutD > >> ated(JspCompiler.java:179) > >> 17:38:02,687 ERROR [STDERR] at > >> org.apache.jasper.compiler.Compiler.compile(C > >> ompiler.java:121) > >> 17:38:02,687 ERROR [STDERR] at > >> org.apache.jasper.servlet.JspServlet.loadJSP( > >> JspServlet.java:557) > >> 17:38:02,687 ERROR [STDERR] at > >> org.apache.jasper.servlet.JspServlet$JspServl > >> etWrapper.loadIfNecessary(JspServlet.java:177) > >> 17:38:02,703 ERROR [STDERR] at > >> org.apache.jasper.servlet.JspServlet$JspServl > >> etWrapper.service(JspServlet.java:189) > >> 17:38:02,703 ERROR [STDERR] at > >> org.apache.jasper.servlet.JspServlet.serviceJ > >> spFile(JspServlet.java:382) > >> 17:38:02,703 ERROR [STDERR] at > >> org.apache.jasper.servlet.JspServlet.service( > >> JspServlet.java:474) > >> 17:38:02,703 ERROR [STDERR] at
Re: [JBoss-dev] Jetty NPE on undeployment of jbosstest-web
I stuck a sleep() in before the undeploy and this seems to have worked-around the problem and thus confirmed my suspicion. It is showing up a further problem - though not in Jetty: 13:30:14,538 INFO [EjbModule] Destroying 13:30:14,600 ERROR [Log4jService$ThrowableListenerLoggingAdapter] unhandled throwable java.lang.NullPointerException at org.jboss.ejb.plugins.EntityInstanceCache.freeContext(EntityInstanceCache.java:120) at org.jboss.ejb.plugins.AbstractInstanceCache$1.execute(AbstractInstanceCache.java:617) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:206) at java.lang.Thread.run(Thread.java:479) 13:30:14,604 INFO [EjbModule] Remove JSR-77 EJB Module: jboss.management.single:J2EEApplication=jbosstest-web.ear,J2EEServer=Single,j2eeType=EJBModule,name=cts.jar 13:30:14,605 INFO [EJBModule] Stopping 13:30:14,605 INFO [EJBModule] Stopped 13:30:14,605 INFO [EjbModule] Destroyed A sleep() is obviously not a decent solution. We can alter Jetty or alter the testsuite. Bearing in mind that modifying Jetty to finish up all requests before undeploying is a feature that we are looking at (along with holding up requests during a redeploy), but is not a quick bugfix I think that we should make a mental to explicitly test undeployment-whilst-processing-request at a later date and fix the testsuite to wait for all requests to return before undeploying. What are your thoughts ? Jules Jules Gosnell wrote: > Scott, > > This appears to be caused by a race between Jetty responding to the > request to the JSP and the testsuite undeploying it. > > Looking at my request and server logs I can see that a request was made > for include_ejb.jsp during the second before the call to undeploy > jbosstest-web.ear. > > It looks like, by the time Jetty has got the JSP compiled and tries to > run it, it has been undeployed. > > Jetty could handle this more gracefully - agreed (and we are thinking > about it). > > Is it possible that the testsuite is making it's requests asynchronously > and undeploying it's ear before all requests have finished ? > > > Jules > > > Scott M Stark wrote: > >> When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run >> against >> the 3.0 branch the undeployment of the war is causing the NPE shown here: >> >> 17:38:01,062 INFO [MainDeployer] Undeployed >> file:/D:/usr/local/src/cvsroot/JBos >> s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear >> 17:38:02,656 ERROR [STDERR] java.lang.NullPointerException >> 17:38:02,656 ERROR [STDERR] at >> org.mortbay.jetty.servlet.ServletHandler$Cont >> ext.getResource(ServletHandler.java:910) >> 17:38:02,671 ERROR [STDERR] at >> org.apache.jasper.JspEngineContext.getResourc >> e(JspEngineContext.java:366) >> 17:38:02,671 ERROR [STDERR] at >> org.apache.jasper.compiler.JspCompiler.isOutD >> ated(JspCompiler.java:179) >> 17:38:02,687 ERROR [STDERR] at >> org.apache.jasper.compiler.Compiler.compile(C >> ompiler.java:121) >> 17:38:02,687 ERROR [STDERR] at >> org.apache.jasper.servlet.JspServlet.loadJSP( >> JspServlet.java:557) >> 17:38:02,687 ERROR [STDERR] at >> org.apache.jasper.servlet.JspServlet$JspServl >> etWrapper.loadIfNecessary(JspServlet.java:177) >> 17:38:02,703 ERROR [STDERR] at >> org.apache.jasper.servlet.JspServlet$JspServl >> etWrapper.service(JspServlet.java:189) >> 17:38:02,703 ERROR [STDERR] at >> org.apache.jasper.servlet.JspServlet.serviceJ >> spFile(JspServlet.java:382) >> 17:38:02,703 ERROR [STDERR] at >> org.apache.jasper.servlet.JspServlet.service( >> JspServlet.java:474) >> 17:38:02,703 ERROR [STDERR] at >> javax.servlet.http.HttpServlet.service(HttpSe >> rvlet.java:853) >> 17:38:02,703 ERROR [STDERR] at >> org.mortbay.jetty.servlet.ServletHolder.handl >> e(ServletHolder.java:326) >> 17:38:02,718 ERROR [STDERR] at >> org.mortbay.jetty.servlet.Dispatcher.dispatch >> (Dispatcher.java:259) >> 17:38:02,718 ERROR [STDERR] at >> org.mortbay.jetty.servlet.Dispatcher.include( >> Dispatcher.java:171) >> 17:38:02,718 ERROR [STDERR] at >> org.apache.jasper.runtime.JspRuntimeLibrary.i >> nclude(JspRuntimeLibrary.java:820) >> 17:38:02,718 ERROR [STDERR] at >> org.apache.jsp.include_0005fejb$jsp._jspServi >> ce(include_0005fejb$jsp.java:61) >> 17:38:02,718 ERROR [STDERR] at >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) >> 17:38:02,718 ERROR [STDERR] at >> javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >> 17:38:02,734 ERROR [STDERR] at >> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja >> >> va:202) >> 17:38:02,734 ERROR [STDERR] at >> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) >> 17:38:02,734 ERROR [STDERR] at >> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) >> 17:38:02,734 ERROR [STDERR] at >> javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >> 17:
Re: [JBoss-dev] Jetty NPE on undeployment of jbosstest-web
Scott, This appears to be caused by a race between Jetty responding to the request to the JSP and the testsuite undeploying it. Looking at my request and server logs I can see that a request was made for include_ejb.jsp during the second before the call to undeploy jbosstest-web.ear. It looks like, by the time Jetty has got the JSP compiled and tries to run it, it has been undeployed. Jetty could handle this more gracefully - agreed (and we are thinking about it). Is it possible that the testsuite is making it's requests asynchronously and undeploying it's ear before all requests have finished ? Jules Scott M Stark wrote: > When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run against > the 3.0 branch the undeployment of the war is causing the NPE shown here: > > 17:38:01,062 INFO [MainDeployer] Undeployed > file:/D:/usr/local/src/cvsroot/JBos > s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear > 17:38:02,656 ERROR [STDERR] java.lang.NullPointerException > 17:38:02,656 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHandler$Cont > ext.getResource(ServletHandler.java:910) > 17:38:02,671 ERROR [STDERR] at > org.apache.jasper.JspEngineContext.getResourc > e(JspEngineContext.java:366) > 17:38:02,671 ERROR [STDERR] at > org.apache.jasper.compiler.JspCompiler.isOutD > ated(JspCompiler.java:179) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.compiler.Compiler.compile(C > ompiler.java:121) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.loadJSP( > JspServlet.java:557) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServl > etWrapper.loadIfNecessary(JspServlet.java:177) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServl > etWrapper.service(JspServlet.java:189) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.serviceJ > spFile(JspServlet.java:382) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.service( > JspServlet.java:474) > 17:38:02,703 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpSe > rvlet.java:853) > 17:38:02,703 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHolder.handl > e(ServletHolder.java:326) > 17:38:02,718 ERROR [STDERR] at > org.mortbay.jetty.servlet.Dispatcher.dispatch > (Dispatcher.java:259) > 17:38:02,718 ERROR [STDERR] at > org.mortbay.jetty.servlet.Dispatcher.include( > Dispatcher.java:171) > 17:38:02,718 ERROR [STDERR] at > org.apache.jasper.runtime.JspRuntimeLibrary.i > nclude(JspRuntimeLibrary.java:820) > 17:38:02,718 ERROR [STDERR] at > org.apache.jsp.include_0005fejb$jsp._jspServi > ce(include_0005fejb$jsp.java:61) > 17:38:02,718 ERROR [STDERR] at > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) > 17:38:02,718 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja > va:202) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) > 17:38:02,734 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > 17:38:02,734 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHolder.handleServletHolder.java:326) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:595) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpContext.handle(HttpContext.java:1357) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpContext.handle(HttpContext.java:1309) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpServer.service(HttpServer.java:744) > 17:38:02,750 ERROR [STDERR] at > org.jboss.jetty.Jetty.service(Jetty.java:525) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpConnection.service(HttpConnection.java:743) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) > 17:38:02,765 ERROR [STDERR] at java.lang.Thread.run(Thread.java:479) > 17:38:02,781 WARN [Jetty] WARNING: Servlet Exception for > /jbosstest/restricted/ > include_ejb.jsp > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > ___ > Hundreds of nodes
Re: [JBoss-dev] Jetty NPE on undeployment of jbosstest-web
I'll look at this tomorrow. Jules Scott M Stark wrote: > When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run against > the 3.0 branch the undeployment of the war is causing the NPE shown here: > > 17:38:01,062 INFO [MainDeployer] Undeployed > file:/D:/usr/local/src/cvsroot/JBos > s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear > 17:38:02,656 ERROR [STDERR] java.lang.NullPointerException > 17:38:02,656 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHandler$Cont > ext.getResource(ServletHandler.java:910) > 17:38:02,671 ERROR [STDERR] at > org.apache.jasper.JspEngineContext.getResourc > e(JspEngineContext.java:366) > 17:38:02,671 ERROR [STDERR] at > org.apache.jasper.compiler.JspCompiler.isOutD > ated(JspCompiler.java:179) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.compiler.Compiler.compile(C > ompiler.java:121) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.loadJSP( > JspServlet.java:557) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServl > etWrapper.loadIfNecessary(JspServlet.java:177) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServl > etWrapper.service(JspServlet.java:189) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.serviceJ > spFile(JspServlet.java:382) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.service( > JspServlet.java:474) > 17:38:02,703 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpSe > rvlet.java:853) > 17:38:02,703 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHolder.handl > e(ServletHolder.java:326) > 17:38:02,718 ERROR [STDERR] at > org.mortbay.jetty.servlet.Dispatcher.dispatch > (Dispatcher.java:259) > 17:38:02,718 ERROR [STDERR] at > org.mortbay.jetty.servlet.Dispatcher.include( > Dispatcher.java:171) > 17:38:02,718 ERROR [STDERR] at > org.apache.jasper.runtime.JspRuntimeLibrary.i > nclude(JspRuntimeLibrary.java:820) > 17:38:02,718 ERROR [STDERR] at > org.apache.jsp.include_0005fejb$jsp._jspServi > ce(include_0005fejb$jsp.java:61) > 17:38:02,718 ERROR [STDERR] at > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) > 17:38:02,718 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja > va:202) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) > 17:38:02,734 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > 17:38:02,734 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHolder.handleServletHolder.java:326) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:595) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpContext.handle(HttpContext.java:1357) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpContext.handle(HttpContext.java:1309) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpServer.service(HttpServer.java:744) > 17:38:02,750 ERROR [STDERR] at > org.jboss.jetty.Jetty.service(Jetty.java:525) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpConnection.service(HttpConnection.java:743) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) > 17:38:02,765 ERROR [STDERR] at java.lang.Thread.run(Thread.java:479) > 17:38:02,781 WARN [Jetty] WARNING: Servlet Exception for > /jbosstest/restricted/ > include_ejb.jsp > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > ___ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.n
[JBoss-dev] Jetty NPE on undeployment of jbosstest-web
When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run against the 3.0 branch the undeployment of the war is causing the NPE shown here: 17:38:01,062 INFO [MainDeployer] Undeployed file:/D:/usr/local/src/cvsroot/JBos s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear 17:38:02,656 ERROR [STDERR] java.lang.NullPointerException 17:38:02,656 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHandler$Cont ext.getResource(ServletHandler.java:910) 17:38:02,671 ERROR [STDERR] at org.apache.jasper.JspEngineContext.getResourc e(JspEngineContext.java:366) 17:38:02,671 ERROR [STDERR] at org.apache.jasper.compiler.JspCompiler.isOutD ated(JspCompiler.java:179) 17:38:02,687 ERROR [STDERR] at org.apache.jasper.compiler.Compiler.compile(C ompiler.java:121) 17:38:02,687 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.loadJSP( JspServlet.java:557) 17:38:02,687 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet$JspServl etWrapper.loadIfNecessary(JspServlet.java:177) 17:38:02,703 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet$JspServl etWrapper.service(JspServlet.java:189) 17:38:02,703 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.serviceJ spFile(JspServlet.java:382) 17:38:02,703 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.service( JspServlet.java:474) 17:38:02,703 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpSe rvlet.java:853) 17:38:02,703 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHolder.handl e(ServletHolder.java:326) 17:38:02,718 ERROR [STDERR] at org.mortbay.jetty.servlet.Dispatcher.dispatch (Dispatcher.java:259) 17:38:02,718 ERROR [STDERR] at org.mortbay.jetty.servlet.Dispatcher.include( Dispatcher.java:171) 17:38:02,718 ERROR [STDERR] at org.apache.jasper.runtime.JspRuntimeLibrary.i nclude(JspRuntimeLibrary.java:820) 17:38:02,718 ERROR [STDERR] at org.apache.jsp.include_0005fejb$jsp._jspServi ce(include_0005fejb$jsp.java:61) 17:38:02,718 ERROR [STDERR] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) 17:38:02,718 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 17:38:02,734 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:202) 17:38:02,734 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) 17:38:02,734 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) 17:38:02,734 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 17:38:02,734 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHolder.handleServletHolder.java:326) 17:38:02,750 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:595) 17:38:02,750 ERROR [STDERR] at org.mortbay.http.HttpContext.handle(HttpContext.java:1357) 17:38:02,750 ERROR [STDERR] at org.mortbay.http.HttpContext.handle(HttpContext.java:1309) 17:38:02,750 ERROR [STDERR] at org.mortbay.http.HttpServer.service(HttpServer.java:744) 17:38:02,750 ERROR [STDERR] at org.jboss.jetty.Jetty.service(Jetty.java:525) 17:38:02,750 ERROR [STDERR] at org.mortbay.http.HttpConnection.service(HttpConnection.java:743) 17:38:02,765 ERROR [STDERR] at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) 17:38:02,765 ERROR [STDERR] at org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) 17:38:02,765 ERROR [STDERR] at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145) 17:38:02,765 ERROR [STDERR] at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) 17:38:02,765 ERROR [STDERR] at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) 17:38:02,765 ERROR [STDERR] at java.lang.Thread.run(Thread.java:479) 17:38:02,781 WARN [Jetty] WARNING: Servlet Exception for /jbosstest/restricted/ include_ejb.jsp Scott Stark Chief Technology Officer JBoss Group, LLC ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty/JSP problem with struts templates
I know this is a touchy subject and we all hate JSPs, but are there any known problems with JBoss3/Jetty these days. I have a small application which uses struts templates and Jetty seems to be choking on it (with the current HEAD version): java.lang.NullPointerException at org.apache.jsp.tradeTemplate$jsp._jspService(tradeTemplate$jsp.java:82) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:326) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:171) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:820) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:391) at Sorry, An Unexpected Error Occurred. JSP Exception: null The RC1 version of JBoss 3 just comes back with: HTTP ERROR: 500 Internal Server Error RequestURI=/customsec/trading/index.jsp Nothing in the logs or console. The application manages to display pages OK (though it has other problems :) in the current Tomcat versions. I just switched to using JDK 1.4, but have had similar Jetty problems in the past. It seems to be OK with non-templated pages. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [JBoss-dev] Jetty, Servlet Filters & url-pattern="/*" (fwd)
Really... that is odd. Are you testing on your latest CVS? I have been using the version in JBoss CVS HEAD using the SiteMesh filter (http://www.opensymphony.com/sitemesh/) and I could only get it to apply the decorator to http://localhost:8080/index.jsp it would show the raw content page for http://localhost:8080 I tested this over and over... though it is possible that I am insane after all this mudling... but another user on jboss dev confirmed the odd behavior. I am moving forward with my work on the site, using index.jsp to send a redirect to default.jsp which seems to work. If you still can not reproduce, perhaps it is fixed in the latest... otherwise once the new site is setup using these filters you can use that to test (copying default.jsp to index.jsp). Or I could mail you a test war... yes perhaps that is best. I tried enabling debug with the jboss.web:Jetty=Debug MBean but it did not produce any useful output: [SocketListener-4/0]javax.servlet.GenericServlet.init(GenericServlet.java:257) Perhaps it still does not work? I don't know. --jason Quoting Greg Wilkins <[EMAIL PROTECTED]>: > Jason, > > I just did a quick test on raw jetty, and a filter at /* certainly is > getting applied to a webapp that is registered at / > > If I register the webapp at /blah then the filter also gets called > for http://localhost:8080/blah requests. > > Can you use the JMX interface to turn on Jetty debugging and see what > is happening within the filter handler (Jules/Jan the debug MBean is > work now right) > > cheers > > > -- > Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 > Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 > http://www.mortbay.com AU Phone: +61-(0)2 98107029 > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [JBoss-dev] Jetty, Servlet Filters & url-pattern="/*"(fwd)
Jason, I just did a quick test on raw jetty, and a filter at /* certainly is getting applied to a webapp that is registered at / If I register the webapp at /blah then the filter also gets called for http://localhost:8080/blah requests. Can you use the JMX interface to turn on Jetty debugging and see what is happening within the filter handler (Jules/Jan the debug MBean is work now right) cheers -- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty, Servlet Filters & url-pattern="/*"
Hey, I am not sure if this is a real problem or if I just have my webapp misconfigured... but it looks like there is a problem outside of my config. I have been trying to setup a test environemnt for SiteMesh. SiteMesh uses servlet filters to apply the decorator pattern to jsp pages... which is very, very cool. But, I am having throuble getting it to work on urls like http://localhost:8080, though it works fine when you go to http://localhost:8080. It looks like Jetty (or some component working with jetty) is not applying the filter that I have set using the following: sitemesh /* I have also tried addind an explicit filter for root: sitemesh / But it still does not work. So I checked the 2.3 spec, section 6.2.4 refernces this text: [the filter]... is applied to all the servlets and static content pages in the web application, because every request URI matches the /* URL pattern. So it seems to me that this '/*' pattern should also be applied to http://localhost:8080/. Or am I wrong? Does anyone know if this is easy to fix inside of the Jetty compnents and/or if there is a short-term fix to avoid this bug? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13857 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jetty, web-app & doctype
> > >I assume your getting an error, what is the trace. Most likely >the parser of the web.xml has validation turned on. If you >include the full dtd it does not need to be available as we have >local entity resolvers for all of the standard dtds. > Here is one: 18:53:57,838 INFO [Jetty] Registered jboss.web:Jetty=0,JBossWebApplicationContext=4,context=/j2ee/dtd 18:53:57,938 INFO [Jetty] Delete existing temp dir c:\DOCUME~1\jason\LOCALS~1\Temp\Jetty__8080___j2ee_dtd for WebApplicationContext[/j2ee/dtd,jar:njar:file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/dtds.ear/80.dtds.ear^/dtds.war!/] 18:53:57,948 INFO [Jetty] Created temp dir c:\DOCUME~1\jason\LOCALS~1\Temp\Jetty__8080___j2ee_dtd for WebApplicationContext[/j2ee/dtd,jar:njar:file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/dtds.ear/80.dtds.ear^/dtds.war!/] 18:53:57,958 INFO [Jetty] Extract jar:njar:file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/dtds.ear/80.dtds.ear^/dtds.war!/ to c:\DOCUME~1\jason\LOCALS~1\Temp\Jetty__8080___j2ee_dtd\webapp 18:53:58,138 WARN [Jetty] WARNING: ERROR@file:/C:/Documents and Settings/jason/Local Settings/Temp/Jetty__8080___j2ee_dtd/webapp/WEB-INF/web.xml line:6 col:-1 : org.xml.sax.SAXParseException: Element type "web-app" is not declared. 18:53:58,138 WARN [Jetty] WARNING: ERROR@file:/C:/Documents and Settings/jason/Local Settings/Temp/Jetty__8080___j2ee_dtd/webapp/WEB-INF/web.xml line:7 col:-1 : org.xml.sax.SAXParseException: Element type "display-name" is not declared. 18:53:58,138 WARN [Jetty] WARNING: Configuration error jar:njar:file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/dtds.ear/80.dtds.ear^/dtds.war!/ org.xml.sax.SAXParseException: Element type "web-app" is not declared. at org.apache.crimson.parser.Parser2.error(Parser2.java:3086) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1316) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:500) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at javax.xml.parsers.SAXParser.parse(SAXParser.java:357) at org.mortbay.xml.XmlParser.parse(XmlParser.java:123) at org.mortbay.xml.XmlParser.parse(XmlParser.java:138) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:336) at org.jboss.jetty.Jetty.deploy(Jetty.java:405) at org.jboss.jetty.JettyService.performDeploy(JettyService.java:244) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:405) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:665) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:658) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:507) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:350) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:460) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:202) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:191) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jetty, web-app & doctype
Yes, I am getting an error... though I don't have the trace handy at the moment. I can reproduce shortly... should have included trace before, my bad. --jason Scott M Stark wrote: >I assume your getting an error, what is the trace. Most likely >the parser of the web.xml has validation turned on. If you >include the full dtd it does not need to be available as we have >local entity resolvers for all of the standard dtds. > > >Scott Stark >Chief Technology Officer >JBoss Group, LLC > >- Original Message - >From: "Jason Dillon" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, April 17, 2002 4:33 PM >Subject: [JBoss-dev] jetty, web-app & doctype > > >>Why does a web.xml file have to explictily list the full DOCTYPE to work >>correctly? >> >> used to work, but now needs to be more like: >> >>>2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";> >> >>Does this mean that it will fail to deploy when this URL is not available? >> >>--jason >> >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jetty, web-app & doctype
I assume your getting an error, what is the trace. Most likely the parser of the web.xml has validation turned on. If you include the full dtd it does not need to be available as we have local entity resolvers for all of the standard dtds. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 17, 2002 4:33 PM Subject: [JBoss-dev] jetty, web-app & doctype > Why does a web.xml file have to explictily list the full DOCTYPE to work > correctly? > > used to work, but now needs to be more like: > > 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";> > > Does this mean that it will fail to deploy when this URL is not available? > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jetty, web-app & doctype
Why does a web.xml file have to explictily list the full DOCTYPE to work correctly? used to work, but now needs to be more like: http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";> Does this mean that it will fail to deploy when this URL is not available? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty Version in upcoming 2.4.5 release
All, are there already any plans about which version og Jetty will be delivered with the upcoming 2.4.5 release of JBoss. We are currently using JBoss2.4.5-Jetty3.1.7-1 but I know the Jules fixed something for us in the current Jetty branch for JBoss3. It would be nice if that could be integrated in the planned 2.4.5 version. Thanks, --Marcus ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
If a web app context has a WEB-INF/classes or non-empty WEB-INF/lib, then we create a mortbay class loader as the thread context class loader. Otherwise, we use the parent class loader as the thread context class loader, which in the case of JBoss will be an MBeanClassLoader. Jan Jason Dillon wrote: > I don't understand how this is the cause of the ClassCastException? > > Can you explain that please. > > --jason > > > Jan Bartel wrote: > >> Jason, >> >> Okay, I'm not perplexed anymore! :-) Jetty expects to find at least >> either a WEB-INF/classes directory, or a WEB-INF/lib (with at least one >> jar in it) in the webapp directory - so the short term fix is for you >> to create an empty WEB-INF/classes directory, and all should be well. >> >> In the slightly longer term, the fix is for us to deal with non-existant >> WEB-INF directories in a slightly more flexible manner. ;-) >> >> [snip] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
|I don't know what web context is being started here as there really |is not one. Its probably some default setup that is irrelevant but |the Jetty guys will have to determine if that is the case. If need be |an empty URLClassLoader can be created for the startService |context. OK I see, a Unified CLassloader is what it needs marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
Unified is a URLCl, however I don't understand 1- the problem 2- the analysis so I am not going to make guess work on this marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
|JBossMX remembers the |context classloader from the MBean's registration and |uses it again during MBean invocation. It has to be |something to do with that. it should be using UnifiedCL... marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
|But (I think) with JBossMX jasper gets the apps |UnifiedClassLoader instead of JettyService's MBeanClassLoader. that would be the best actually, wrong guess work marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
|Anyways, I am seeing consistent ClassCastExceptions for |MBeanClassLoader... which is not a URLClassLoader. My guess is that |MBeanClassLoader could be a URLClassLoader, but that seems a bit |artificial. MBeanCL might be going away marcf | |Anybody know what is up with this? | |--jason | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
I don't understand how this is the cause of the ClassCastException? Can you explain that please. --jason Jan Bartel wrote: > Jason, > > Okay, I'm not perplexed anymore! :-) Jetty expects to find at least > either a WEB-INF/classes directory, or a WEB-INF/lib (with at least one > jar in it) in the webapp directory - so the short term fix is for you > to create an empty WEB-INF/classes directory, and all should be well. > > In the slightly longer term, the fix is for us to deal with non-existant > WEB-INF directories in a slightly more flexible manner. ;-) > > Jan > > >>> Can you please post some more details on your exact scenario, viz: >> >> >> >> >> Will try. >> >>> + is this a hot redeploy of Jetty, especially is it a hot redeploy >>>when some webapps were already deployed? >> >> >> >> Not a redeploy. >> >>> + have you modified your jetty jboss-service.xml file to include a >>> webapp (long shot, but I have to ask)? >> >> >> >> Yes, before there is >> >> >>/ >> >> >> >>> + what code base are you running off? >> >> >> >> JBoss HEAD >> >>> + what kind of log trace do you see? >> >> >> >> I mailed that already but here you go again: >> >> 23:56:35,547 INFO [Jetty] ResourceHandler started in >> file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.0.0beta2/ >> >> 23:56:35,547 INFO [Jetty] Started ResourceHandler in >> >WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] > >> >> 23:56:35,547 INFO [Jetty] Started NotFoundHandler in >> >WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] > >> >> 23:56:35,567 INFO [Jetty] Started SocketListener on 0.0.0.0:8080 >> 23:56:35,567 ERROR [JettyService] multipule exceptions... >> 23:56:35,577 ERROR [JettyService] exception >> java.lang.ClassCastException: org.jboss.system.MBeanClassLoader >>at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) >>at >> org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) >>at >> org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) >>at >> org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) >>at >> org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) >>at org.mortbay.http.HttpContext.start(HttpContext.java:1420) >>at >> >org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:365) >> >>at org.mortbay.http.HttpServer.start(HttpServer.java:186) >>at >> org.jboss.jetty.JettyService.startService(JettyService.java:236) >>at >> org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >> org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) >> >>at $Proxy0.start(Unknown Source) >>at >> org.jboss.system.ServiceController.start(ServiceController.java:343) >>at java.lang.reflect.Method.invoke(Native Method) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy3.start(Unknown Source) >>at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) >>at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) >>at >> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) >>at >> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) >>at >> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) >>at java.lang.reflect.Method.invoke(Native Method) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy2.deploy(Unknown Source) >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDeploymentScanner.java:176) > >> >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploymentScanner.java:138) > >> >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(DirectoryDeploymentScanner.java:607) > >> >>at >> org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBean
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
Jason, Okay, I'm not perplexed anymore! :-) Jetty expects to find at least either a WEB-INF/classes directory, or a WEB-INF/lib (with at least one jar in it) in the webapp directory - so the short term fix is for you to create an empty WEB-INF/classes directory, and all should be well. In the slightly longer term, the fix is for us to deal with non-existant WEB-INF directories in a slightly more flexible manner. ;-) Jan >> Can you please post some more details on your exact scenario, viz: > > > > Will try. > >> + is this a hot redeploy of Jetty, especially is it a hot redeploy >>when some webapps were already deployed? > > > Not a redeploy. > >> + have you modified your jetty jboss-service.xml file to include a >> webapp (long shot, but I have to ask)? > > > Yes, before there is > > >/ > > > >> + what code base are you running off? > > > JBoss HEAD > >> + what kind of log trace do you see? > > > I mailed that already but here you go again: > > 23:56:35,547 INFO [Jetty] ResourceHandler started in > file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.0.0beta2/ > > 23:56:35,547 INFO [Jetty] Started ResourceHandler in > >WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] > > > 23:56:35,547 INFO [Jetty] Started NotFoundHandler in > >WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] > > > 23:56:35,567 INFO [Jetty] Started SocketListener on 0.0.0.0:8080 > 23:56:35,567 ERROR [JettyService] multipule exceptions... > 23:56:35,577 ERROR [JettyService] exception > java.lang.ClassCastException: org.jboss.system.MBeanClassLoader >at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) >at > org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) >at > org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) >at > org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) >at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) >at org.mortbay.http.HttpContext.start(HttpContext.java:1420) >at > >org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:365) > >at org.mortbay.http.HttpServer.start(HttpServer.java:186) >at org.jboss.jetty.JettyService.startService(JettyService.java:236) >at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >at java.lang.reflect.Method.invoke(Native Method) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) > >at $Proxy0.start(Unknown Source) >at > org.jboss.system.ServiceController.start(ServiceController.java:343) >at java.lang.reflect.Method.invoke(Native Method) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >at $Proxy3.start(Unknown Source) >at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) >at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) >at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) >at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) >at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) >at java.lang.reflect.Method.invoke(Native Method) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >at $Proxy2.deploy(Unknown Source) >at > >org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDeploymentScanner.java:176) > > >at > >org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploymentScanner.java:138) > > >at > >org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(DirectoryDeploymentScanner.java:607) > > >at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >at java.lang.reflect.Method.invoke(Native Method) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) > >at $Proxy0.start(Unknown Source) >at > org.jboss.system.ServiceController.start(ServiceController.java:343) >at > or
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
> Can you please post some more details on your exact scenario, viz: Will try. > + is this a hot redeploy of Jetty, especially is it a hot redeploy >when some webapps were already deployed? Not a redeploy. > + have you modified your jetty jboss-service.xml file to include a > webapp (long shot, but I have to ask)? Yes, before there is / > + what code base are you running off? JBoss HEAD > + what kind of log trace do you see? I mailed that already but here you go again: 23:56:35,547 INFO [Jetty] ResourceHandler started in file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.0.0beta2/ 23:56:35,547 INFO [Jetty] Started ResourceHandler in WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] 23:56:35,547 INFO [Jetty] Started NotFoundHandler in WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] 23:56:35,567 INFO [Jetty] Started SocketListener on 0.0.0.0:8080 23:56:35,567 ERROR [JettyService] multipule exceptions... 23:56:35,577 ERROR [JettyService] exception java.lang.ClassCastException: org.jboss.system.MBeanClassLoader at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) at org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) at org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) at org.mortbay.http.HttpContext.start(HttpContext.java:1420) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:365) at org.mortbay.http.HttpServer.start(HttpServer.java:186) at org.jboss.jetty.JettyService.startService(JettyService.java:236) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:343) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy2.deploy(Unknown Source) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDeploymentScanner.java:176) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploymentScanner.java:138) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(DirectoryDeploymentScanner.java:607) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:343) at org.jboss.system.ServiceController.start(ServiceController.java:360) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:331) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:211) at org.jboss.Main.boot(Main.java:127) at org.jboss.Main$1.run(Main.java:335) at java.lang.Thread.run(Thread.java:484) 23:56:35,577 INFO [JettyService] Started 23:56:35,577 INFO [MainDep
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
Jason, Can you please post some more details on your exact scenario, viz: + is this a hot redeploy of Jetty, especially is it a hot redeploy when some webapps were already deployed? + have you modified your jetty jboss-service.xml file to include a webapp (long shot, but I have to ask)? + what code base are you running off? + what kind of log trace do you see? Jetty does not do anything with JSP unless we have got webapp contexts already registered when we receive a start. This could occur, for example, if you deployed Jetty, deployed some webapps, did a stop and restart on the Jetty service using JMX. Jan Scott M Stark wrote: > This is the start of the JettyService which is a subclass of > AbstractWebContainer. This is before the web app URLClassLoader > has been created. This does not occur until the > performDeploy(String path, String warUrl, WebDescriptorParser parser) > call. Apparently Jetty initializes the JSP servlet before this call > and its integration API expects a URLClassLoader. > > I don't know what web context is being started here as there really > is not one. Its probably some default setup that is irrelevant but > the Jetty guys will have to determine if that is the case. If need be > an empty URLClassLoader can be created for the startService > context. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: "Scott M Stark" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, March 01, 2002 6:24 PM > Subject: Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and > MBeanClassLoader > > > >>java.lang.ClassCastException: org.jboss.system.MBeanClassLoader >>at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) >>at >>org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) >>at >>org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) >>at >>org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) >>at >> > org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) > >>at org.mortbay.http.HttpContext.start(HttpContext.java:1420) >>at >> >> > org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. > java:365) > >>at org.mortbay.http.HttpServer.start(HttpServer.java:186) >>at >> > org.jboss.jetty.JettyService.startService(JettyService.java:236) > >>at >>org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >> >> > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav > a:779) > >>at $Proxy0.start(Unknown Source) >>at >>org.jboss.system.ServiceController.start(ServiceController.java:343) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy3.start(Unknown Source) >>at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) >>at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy2.deploy(Unknown Source) >>at >> >> > org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDepl > oymentScanner.java:176) > >>at >> >> > org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploy > mentScanner.java:138) > >>at >> >> > org.jboss.deplo
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
To reproduce, add the following into the jetty jboss-service.xml: / I did not test that this happens on deployment. I copied jetty-plugin.sar to lib/jetty-plugin.jar and copied jboss-service.xml to jetty-service.xml. --jason Scott M Stark wrote: >This is the start of the JettyService which is a subclass of >AbstractWebContainer. This is before the web app URLClassLoader >has been created. This does not occur until the >performDeploy(String path, String warUrl, WebDescriptorParser parser) >call. Apparently Jetty initializes the JSP servlet before this call >and its integration API expects a URLClassLoader. > >I don't know what web context is being started here as there really >is not one. Its probably some default setup that is irrelevant but >the Jetty guys will have to determine if that is the case. If need be >an empty URLClassLoader can be created for the startService >context. > > >Scott Stark >Chief Technology Officer >JBoss Group, LLC > >- Original Message - >From: "Jason Dillon" <[EMAIL PROTECTED]> >To: "Scott M Stark" <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Friday, March 01, 2002 6:24 PM >Subject: Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and >MBeanClassLoader > > >>java.lang.ClassCastException: org.jboss.system.MBeanClassLoader >>at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) >>at >>org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) >>at >>org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) >>at >>org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) >>at >> >org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) > >>at org.mortbay.http.HttpContext.start(HttpContext.java:1420) >>at >> >org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. >java:365) > >>at org.mortbay.http.HttpServer.start(HttpServer.java:186) >>at >> >org.jboss.jetty.JettyService.startService(JettyService.java:236) > >>at >>org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >> >org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav >a:779) > >>at $Proxy0.start(Unknown Source) >>at >>org.jboss.system.ServiceController.start(ServiceController.java:343) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy3.start(Unknown Source) >>at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) >>at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy2.deploy(Unknown Source) >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDepl >oymentScanner.java:176) > >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploy >mentScanner.java:138) > >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(Directo >ryDeploymentScanner.java:607) > >>at >>org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
This is the start of the JettyService which is a subclass of AbstractWebContainer. This is before the web app URLClassLoader has been created. This does not occur until the performDeploy(String path, String warUrl, WebDescriptorParser parser) call. Apparently Jetty initializes the JSP servlet before this call and its integration API expects a URLClassLoader. I don't know what web context is being started here as there really is not one. Its probably some default setup that is irrelevant but the Jetty guys will have to determine if that is the case. If need be an empty URLClassLoader can be created for the startService context. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 6:24 PM Subject: Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader > java.lang.ClassCastException: org.jboss.system.MBeanClassLoader > at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) > at > org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) > at > org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) > at > org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) > at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) > at org.mortbay.http.HttpContext.start(HttpContext.java:1420) > at > org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. java:365) > at org.mortbay.http.HttpServer.start(HttpServer.java:186) > at org.jboss.jetty.JettyService.startService(JettyService.java:236) > at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:779) > at $Proxy0.start(Unknown Source) > at > org.jboss.system.ServiceController.start(ServiceController.java:343) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) > at $Proxy3.start(Unknown Source) > at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) > at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) > at $Proxy2.deploy(Unknown Source) > at > org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDepl oymentScanner.java:176) > at > org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploy mentScanner.java:138) > at > org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(Directo ryDeploymentScanner.java:607) > at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:779) > at $Proxy0.start(Unknown Source) > at > org.jboss.system.ServiceController.start(ServiceController.java:343) > at > org.jboss.system.ServiceController.start(ServiceController.java:360) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at org.jboss.system.server.ServerImpl.doStart
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
java.lang.ClassCastException: org.jboss.system.MBeanClassLoader at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) at org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) at org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) at org.mortbay.http.HttpContext.start(HttpContext.java:1420) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:365) at org.mortbay.http.HttpServer.start(HttpServer.java:186) at org.jboss.jetty.JettyService.startService(JettyService.java:236) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:343) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy2.deploy(Unknown Source) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDeploymentScanner.java:176) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploymentScanner.java:138) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(DirectoryDeploymentScanner.java:607) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:343) at org.jboss.system.ServiceController.start(ServiceController.java:360) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:331) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:211) at org.jboss.Main.boot(Main.java:127) at org.jboss.Main$1.run(Main.java:335) at java.lang.Thread.run(Thread.java:484) --jason Scott M Stark wrote: >Show the stack trace for the cast. The parent class loader of >every web context and request should be a URLClassLoader >as this is created by the AbstractWebContainer to establish >a unique ENC namespace. > > >Scott Stark >Chief Technology Officer >JBoss Group, LLC > >- Original Message - >From: "Jason Dillon" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, March 01, 2002 5:08 PM >Subject: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and >MBeanClassLoader > > >>Does anyone know why the Jasper JspSevlet thinks that its TCL is always >>a URLClassLoader? It takes the value from >>Thread.currentThread().getContextClassLoader() and casts it with out a >>care... does the same for getClass().getClassLoader()... >> >>It is assigning the value parentClassLoader, which is of type >>URLClassLoader... but then they have checks for if (parentClassLoader >>instanceof URLClassLoader). >> >>This is garbage... >> >>Anyways,
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
Hopefully you can find something simple to fix this... Perhaps we can simply make a UCL and set the TCL inside JettyService: /** * The JSP engine (a.k.a Jasper)! * * The servlet container is responsible for providing a * URLClassLoader for the web application context Jasper * is being used in. Jasper will try get the Tomcat * ServletContext attribute for its ServletContext class * loader, if that fails, it uses the parent class loader. * In either case, it must be a URLClassLoader. * * @author Anil K. Vijendran * @author Harish Prabandham */ Is this spec that it must be a URLClassLoader? --jason Adrian Brock wrote: >No, I'm obviously talking rubbish again. > >I think I need to look at how Jetty does the >classloaders to figure this one out. > >At Scott's suggestion, JBossMX remembers the >context classloader from the MBean's registration and >uses it again during MBean invocation. It has to be >something to do with that. > >Regards, >Adrian > >>I can't speak for apache/jasper. >> >>But (I think) with JBossMX jasper gets the apps >>UnifiedClassLoader instead of JettyService's >>MBeanClassLoader. >> >>The "I think" is because I haven't actually verified >>this. >>I do know the WebIntegration tests don't have the JSP >>problems running under JBossMX that it does with the >>RI. >> >>Regards, >>Adrian >> >>>Does anyone know why the Jasper JspSevlet thinks >>> >>that >> >>>its TCL is always >>>a URLClassLoader? It takes the value from >>>Thread.currentThread().getContextClassLoader() and >>>casts it with out a >>>care... does the same for >>>getClass().getClassLoader()... >>> >>>It is assigning the value parentClassLoader, which >>> >>is >> >>>of type >>>URLClassLoader... but then they have checks for if >>>(parentClassLoader >>>instanceof URLClassLoader). >>> >>>This is garbage... >>> >>>Anyways, I am seeing consistent >>> >>ClassCastExceptions >> >>>for >>>MBeanClassLoader... which is not a URLClassLoader. >>> My guess is that >>>MBeanClassLoader could be a URLClassLoader, but >>> >>that >> >>>seems a bit artificial. >>> >>>Anybody know what is up with this? >>> >>>--jason >>> >>> >>>___ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>> >>https://lists.sourceforge.net/lists/listinfo/jboss-dev >> >>>lopment >>> > > > >_ >View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10040 > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
Show the stack trace for the cast. The parent class loader of every web context and request should be a URLClassLoader as this is created by the AbstractWebContainer to establish a unique ENC namespace. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 5:08 PM Subject: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader > Does anyone know why the Jasper JspSevlet thinks that its TCL is always > a URLClassLoader? It takes the value from > Thread.currentThread().getContextClassLoader() and casts it with out a > care... does the same for getClass().getClassLoader()... > > It is assigning the value parentClassLoader, which is of type > URLClassLoader... but then they have checks for if (parentClassLoader > instanceof URLClassLoader). > > This is garbage... > > Anyways, I am seeing consistent ClassCastExceptions for > MBeanClassLoader... which is not a URLClassLoader. My guess is that > MBeanClassLoader could be a URLClassLoader, but that seems a bit artificial. > > Anybody know what is up with this? > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
No, I'm obviously talking rubbish again. I think I need to look at how Jetty does the classloaders to figure this one out. At Scott's suggestion, JBossMX remembers the context classloader from the MBean's registration and uses it again during MBean invocation. It has to be something to do with that. Regards, Adrian > I can't speak for apache/jasper. > > But (I think) with JBossMX jasper gets the apps > UnifiedClassLoader instead of JettyService's > MBeanClassLoader. > > The "I think" is because I haven't actually verified > this. > I do know the WebIntegration tests don't have the JSP > problems running under JBossMX that it does with the > RI. > > Regards, > Adrian > > > Does anyone know why the Jasper JspSevlet thinks > that > > its TCL is always > > a URLClassLoader? It takes the value from > > Thread.currentThread().getContextClassLoader() and > > casts it with out a > > care... does the same for > > getClass().getClassLoader()... > > > > It is assigning the value parentClassLoader, which > is > > of type > > URLClassLoader... but then they have checks for if > > (parentClassLoader > > instanceof URLClassLoader). > > > > This is garbage... > > > > Anyways, I am seeing consistent > ClassCastExceptions > > for > > MBeanClassLoader... which is not a URLClassLoader. > > My guess is that > > MBeanClassLoader could be a URLClassLoader, but > that > > seems a bit artificial. > > > > Anybody know what is up with this? > > > > --jason > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-dev > > > lopment > _ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10040 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
I can't speak for apache/jasper. But (I think) with JBossMX jasper gets the apps UnifiedClassLoader instead of JettyService's MBeanClassLoader. The "I think" is because I haven't actually verified this. I do know the WebIntegration tests don't have the JSP problems running under JBossMX that it does with the RI. Regards, Adrian > Does anyone know why the Jasper JspSevlet thinks that > its TCL is always > a URLClassLoader? It takes the value from > Thread.currentThread().getContextClassLoader() and > casts it with out a > care... does the same for > getClass().getClassLoader()... > > It is assigning the value parentClassLoader, which is > of type > URLClassLoader... but then they have checks for if > (parentClassLoader > instanceof URLClassLoader). > > This is garbage... > > Anyways, I am seeing consistent ClassCastExceptions > for > MBeanClassLoader... which is not a URLClassLoader. > My guess is that > MBeanClassLoader could be a URLClassLoader, but that > seems a bit artificial. > > Anybody know what is up with this? > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-dev > lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10040 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
Does anyone know why the Jasper JspSevlet thinks that its TCL is always a URLClassLoader? It takes the value from Thread.currentThread().getContextClassLoader() and casts it with out a care... does the same for getClass().getClassLoader()... It is assigning the value parentClassLoader, which is of type URLClassLoader... but then they have checks for if (parentClassLoader instanceof URLClassLoader). This is garbage... Anyways, I am seeing consistent ClassCastExceptions for MBeanClassLoader... which is not a URLClassLoader. My guess is that MBeanClassLoader could be a URLClassLoader, but that seems a bit artificial. Anybody know what is up with this? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty needs local entity update
The JettyService needs to update its local entity resolver to support DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.3//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_3_0.dtd"; which was recently added to main. All jboss-web dtds are now located with all other dtds in the server/src/resources/org/jboss/metadata and the lib/ext/jboss.jar in the distribution. Currently the WebIntegrationUnitTestCase fails with Jetty because of this: 10:44:51,562 ERROR [JBossWebApplicationContext#/jbosstest] problem locating jboss-web.xml java.io.FileNotFoundException: http://www.jboss.org/j2ee/dtds/jboss-web_3_0.dtd at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:2796) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1155) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty
Title: Message Hi, It seems that something is not configured properly with JBoss2.4.4 - Jetty 3.1.3 (I've tried 2.4.3 as well) on Linux (Suse 7.1) When Jetty is started separately ( ./jetty/bin/jetty.sh start ) I can run demo by using http://hostname:8080 everything is just fine! When I start both JBoss & Jetty ( ./jboss/bin/run.sh jetty ) DEMO is not running : HTTP ERROR: 404 Not Found Could not find resource for /jetty/demos.html RequestURI=/jetty/demos.html but Jboss Agent http://hostname:8082/ is running just fine When accessing JBoss, - on the Linux terminal window the string appear: NotFoundHandler in HandlerContext[/] What is the problem ? Please help ! my JBoss server.log file is attached Thanks Jack G. server.log Description: Binary data
Re: [jetty-discuss] [Fwd: [JBoss-dev] Jetty redeploy problems in RH]
Well I have kind of left it sit at that for now... but then I guess most of you realize that I'm not a big fan of JSPs or even reloading servlets. The problem is not a Jetty problem and is in code from the reference implementation - so I've got bigger fish to fry (Eg still have not heard if we have a security mechanism that works). If somebody out there REALLY wants it - I guess the best thing to do is to get a JVM that is not broken. If a real user bugs me a lot - I may tell them how to patch Jasper - but that aint going to make it into a Jetty release any time soon! If somebody really cares about this problem - they can write and register a URL handler for file urls that actually works. If they contributed this to jetty and/or jboss, I'm sure it would make it into a release as a useful work around. So summary is that it is tools down on this one from me Jules Gosnell wrote: > Greg, > > What is the situation now? Are we just waiting for the Jasper crew to > sort out a workaround ? are they likely to do so ? > > I enclose the last mail I could find on the subject - which suggests a > fix. This might well benefit other JBoss modules. Perhaps we could > persuade someone on the jboss-user list to run with it ? > > Jules > > >- > > JSP reloading is not working at the moment as the jasper folks appear > to have given up working around the crappy URLConnections and just call > >url.openConnection().getLastModified() > > Which just returns 0 on my JVM and has done so since the first release > of java.net! > > I could modify jasper, but don't really want to start on this now. > > So if somebody wants to write a FileURLConnection class and it's > associated URLStreamHandler - then that would fix this for good and > would > allow org.mortbay.util.Resource to be greatly simplified! > > Cheers, > > > Greg > > > > > > > Yahoo! Groups Sponsor -~--> > Sponsored by VeriSign - The Value of Trust > Do you need to encrypt all your online transactions? Find > the perfect solution in this FREE Guide from VeriSign. > http://us.click.yahoo.com/vCuuSA/UdiDAA/yigFAA/CefplB/TM > -~-> > > For the latest information about Jetty, please see http://jetty.mortbay.org > > To alter your subscription to this list goto >http://groups.yahoo.com/group/jetty-discuss > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > Subject: > > [JBoss-dev] Jetty redeploy problems in RH > From: > > Dain Sundstrom <[EMAIL PROTECTED]> > Date: > > Sun, 20 Jan 2002 14:04:43 -0600 > To: > > [EMAIL PROTECTED] > > > What is the status on fixing the redeploy problems with Jetty (RH). I am > referring to the problem where Jetty doesn't recompile the JSP pages on an > redeploy or even server restart. > > thanks, > -dain > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > -- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[Fwd: [JBoss-dev] Jetty redeploy problems in RH]
Greg, What is the situation now? Are we just waiting for the Jasper crew to sort out a workaround ? are they likely to do so ? I enclose the last mail I could find on the subject - which suggests a fix. This might well benefit other JBoss modules. Perhaps we could persuade someone on the jboss-user list to run with it ? Jules - JSP reloading is not working at the moment as the jasper folks appear to have given up working around the crappy URLConnections and just call url.openConnection().getLastModified() Which just returns 0 on my JVM and has done so since the first release of java.net! I could modify jasper, but don't really want to start on this now. So if somebody wants to write a FileURLConnection class and it's associated URLStreamHandler - then that would fix this for good and would allow org.mortbay.util.Resource to be greatly simplified! Cheers, Greg --- Begin Message --- What is the status on fixing the redeploy problems with Jetty (RH). I am referring to the problem where Jetty doesn't recompile the JSP pages on an redeploy or even server restart. thanks, -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- End Message ---
[JBoss-dev] Jetty redeploy problems in RH
What is the status on fixing the redeploy problems with Jetty (RH). I am referring to the problem where Jetty doesn't recompile the JSP pages on an redeploy or even server restart. thanks, -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] Jetty security problem
Every request has to be authenticated as the identity of the caller is a property of the request. The ThreadLocal is simply used to propagate the identity through the scope of the request and must be set on each request. The identity to credentials mapping are cached at the security manager layer to avoid having to perform full authentication. If the servlet container is also caching the caller identity because of a stateful session, it still should be calling out to the realm layer for authentication as the cached credentials may be expired ahead of the session. It also simplies the propagation of the caller identity outside of the servlet container when other secured J2EE components are invoked by the web component. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Anatoly Akkerman" <[EMAIL PROTECTED]> To: "Julian Gosnell" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, December 28, 2001 6:03 AM Subject: Re: [jetty-discuss] Re: [JBoss-dev] Jetty security problem > > I am not sure myself where is the second thread coming from. I'll try to > figure that one out. But in priniciple, Greg is right, using ThreadLocal > for security association is improper in this environment. Again, as Greg > pointed out, we would have to authenticate every request. Here is a > snippet from my log: > ... > As you can see, SocketListener 3 did authentication, while SocketListener1 > is doing role checking. Does it make sense to store the user credentials > is the JBossUserPrincipal and in isUserInRole() do authentication > again? This will set the thread association with proper security > context. I don't know, though, how to unset this once the thread is done > processing the request. > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] Jetty security problem
I am not sure myself where is the second thread coming from. I'll try to figure that one out. But in priniciple, Greg is right, using ThreadLocal for security association is improper in this environment. Again, as Greg pointed out, we would have to authenticate every request. Here is a snippet from my log: 2001-12-27 17:46:57,710 INFO [Default] RequestToEventTranslator: url=/formbasedloginscreen 2001-12-27 17:47:01,796 INFO [Default] Did not find the UCL resource sun/tools/javac/resources/javac_en.properties 2001-12-27 17:47:01,856 INFO [Default] Did not find the UCL resource sun/tools/javac/resources/javac_en_US.properties 2001-12-27 17:47:03,078 INFO [org.jboss.jetty.Jetty] JSP: init 2001-12-27 17:47:03,769 INFO [org.jboss.jetty.Jetty] JSP: init 2001-12-27 17:47:04,259 INFO [org.jboss.jetty.Jetty] JSP: init 2001-12-27 17:47:05,031 INFO [org.jboss.jetty.Jetty] JSP: init 2001-12-27 17:47:05,431 INFO [org.jboss.jetty.Jetty] JSP: init 2001-12-27 17:47:08,295 INFO [org.jboss.jetty.JBossUserRealm#default] JBossUserPrincipal: j2ee 2001-12-27 17:47:08,295 INFO [org.jboss.jetty.JBossUserRealm#default] ensureUser: 2001-12-27 17:47:08,295 INFO [org.jboss.jetty.JBossUserRealm#default] Curr thread: SocketListener-3|0|Socket[addr=127.0.0.1/127.0.0.1,port=3796,localport=8080] 2001-12-27 17:47:08,295 ERROR [Default] java.lang.Throwable 2001-12-27 17:47:08,295 ERROR [Default] at org.jboss.jetty.JBossUserRealm.ensureUser(JBossUserRealm.java:198) 2001-12-27 17:47:08,295 ERROR [Default] at org.jboss.jetty.JBossUserRealm.getUser(JBossUserRealm.java:214) 2001-12-27 17:47:08,295 ERROR [Default] at org.mortbay.jetty.servlet.ServletHandler.formAuthenticated(ServletHandler.java:721) 2001-12-27 17:47:08,295 ERROR [Default] at org.mortbay.http.handler.SecurityHandler.handle(SecurityHandler.java:311) 2001-12-27 17:47:08,315 ERROR [Default] at org.mortbay.http.HttpContext.handle(HttpContext.java:1145) 2001-12-27 17:47:08,315 ERROR [Default] at org.mortbay.http.HttpContext.handle(HttpContext.java:1099) 2001-12-27 17:47:08,315 ERROR [Default] at org.mortbay.http.HttpServer.service(HttpServer.java:725) 2001-12-27 17:47:08,315 ERROR [Default] at org.mortbay.http.HttpConnection.service(HttpConnection.java:745) 2001-12-27 17:47:08,315 ERROR [Default] at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:918) 2001-12-27 17:47:08,315 ERROR [Default] at org.mortbay.http.HttpConnection.handle(HttpConnection.java:760) 2001-12-27 17:47:08,345 ERROR [Default] at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:138) 2001-12-27 17:47:08,345 ERROR [Default] at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) 2001-12-27 17:47:08,345 ERROR [Default] at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) 2001-12-27 17:47:08,345 ERROR [Default] at java.lang.Thread.run(Unknown Source) 2001-12-27 17:47:08,365 INFO [org.jboss.jetty.JBossUserRealm#default] created JBossUserRealm::JBossUserPrincipal: j2ee 2001-12-27 17:47:08,365 INFO [org.jboss.jetty.JBossUserRealm#default] authenticating: Name:j2ee Password:j2ee 2001-12-27 17:47:08,506 INFO [Default] Did not find the UCL resource com/sun/security/auth/Resources_en.properties 2001-12-27 17:47:08,566 INFO [Default] Did not find the UCL resource com/sun/security/auth/Resources_en_US.properties 2001-12-27 17:47:08,746 INFO [Default] User 'j2ee' authenticated. 2001-12-27 17:47:08,746 INFO [Default] UsersRolesModule roles found: customer,gold_customer 2001-12-27 17:47:08,756 INFO [org.jboss.security.plugins.JaasSecurityManager.other] JaasSecurityManager: authenticated, setting active subject: Subject: Principal: j2ee Principal: Roles for thread SocketListener-3|0|Socket[addr=127.0.0.1/127.0.0.1,port=3796,localport=8080] 2001-12-27 17:47:08,786 INFO [org.jboss.jetty.JBossUserRealm#default] JBossUserPrincipal: j2ee is authenticated 2001-12-27 17:47:08,786 INFO [org.jboss.jetty.JBossUserRealm#default] Current thread: SocketListener-3|0|Socket[addr=127.0.0.1/127.0.0.1,port=3796,localport=8080] 2001-12-27 17:47:08,786 INFO [org.jboss.jetty.JBossUserRealm#default] JBossUserPrincipal: getting curr subj: Subject: Principal: j2ee Principal: Roles 2001-12-27 17:47:08,796 INFO [org.jboss.jetty.JBossUserRealm#default] JBossUserPrincipal: j2ee 2001-12-27 17:47:08,796 INFO [org.jboss.jetty.JBossUserRealm#default] ensureUser: 2001-12-27 17:47:08,796 INFO [org.jboss.jetty.JBossUserRealm#default] Curr thread: SocketListener-1|0|Socket[addr=127.0.0.1/127.0.0.1,port=3791,localport=8080] 2001-12-27 17:47:08,796 ERROR [Default] java.lang.Throwable 2001-12-27 17:47:08,796 ERROR [Default] at org.jboss.jetty.JBossUserRealm.ensureUser(JBossUserRealm.java:198) 2001-12-27 17:47:08,796 ERROR [Default] at org.jboss.jetty.JBossUserRealm.getUser(JBossUserRealm.java:214) 2001-12-27 17:47:08,796 ERROR [Default] at org.mortbay.jetty.servlet.ServletHandler.formAuthenticated(ServletHandler.java:752) 2001-12-27 17:47:08,7
Re: [jetty-discuss] Re: [JBoss-dev] Jetty security problem
Greg Wilkins wrote: > Well firstly I'm going to say that we have been having problems > with jboss role based authentication for some time. It is not > something that we want to get wrong, so I think the time has long > since passed where we need a good set of regression tests for > this. > > Now, while I can see that subsequent requests will be in different > threads - I cannot see where the second thread is coming from > within the same request > > Nowhere in the Jetty handling or the JBoss adaptor is a new thread > created, let alone for a call to the authentication API? Likewise, I do not create any extra threads in the integration code. Perhaps the Servlet itself is creating it ? Is it demonstrating programmatic security rather than declarative ? If so, then this is a problem, unless security info attached to primary request threads can be transparently inherited, in user code, by it's child threads Jules > > > As the JBoss JaasSecurityManager class appears to use ThreadLocals > to store authentication results then the solution may have to be to > authenticate every request rather than just relying on the contents > of a session to show that it has previously been authenticated. > > Note this probably means that we also have to deauthenticate threads when > they are returned to the thread pool.I can't see how Jetty can help > much here, as ThreadLocals are beyond it's control and can't > be cleared by it. I would say that adorning Threads with security > priviledges does not sound too robust in any environment that uses > thread pools (Ie almost any servlet container). > > I don't know enough about the jboss authentication mechanism to really > comment more - but I'll repeat that we should make security issues top > priority. > > regards > > Julian Gosnell wrote: > > > Anatoly, > > > > Thanks for the precise description of the problem. I shall take a look at > > this as soon as I find the time. Probably during the first week of Jan or so. > > > > Greg, > > > > Any thoughts about this before I plunge in ? > > > > Jules > > > > > > Anatoly Akkerman wrote: > > > > > >>Hi, guys > >> > >>I am running into problems with Jetty + JBoss 3.0alpha > >> > >>After some debugging here is what I have. > >> > >>Setup: > >>Jetty + JBoss 3.0 > >>Sun's Petstore 1.1.1 deployed piecewise (meaning each EJB and WAR are > >>packaged separately and deployed in a J2eeScopedDeployer) > >>JBossSX configured to pick up usernames, password and roles from files > >> > >>Here is what happens: > >> > >>1) a servlet in Petstore takes username and password from a Web form and > >>sets "j_username" and "j_password" in the session. Jetty seems to pick > >>this stuff up and pass it to JBossUserRealm to authenticate the user. > >>JbossUserPrincipal gets created and then proceeds to authenticate with > >>with _securityMgr (which is JaasSecurityManager "java:/jaas/other"). > >>Authentication succeeds, I see a log and I did doublecheck that > >>JaasSecurityManager sets activeSubject to this authenticated subject. > >> > >>2) Then, it seems, Jetty proceeds to check that this user has required > >>roles. It first calls JbossUserRealm.getUser(name) to obtain the > >>JBossUserPricipal and then calls isUserInRole(String role). This is where > >>the stuff fails miserably. The reason being that Jetty dispatched a > >>different thread to do role checking than the one that did > >>authentication. Because of this, JaasSecurityManager sees a null > >>activeSubject and says that the user does not have required roles. > >> > >>Now, this happens in a _single_ http request from a web client (just > >>clicked 'login' button on a form). I can try hacking a workaround just for > >>my demo to work but would like to help fixing this if it is a bug. > >> > >>- > >>Anatoly Akkerman > >>Computer Science Dept. > >>Courant Institute of Mathematical Sciences, NYU > >>715 Broadway, #719 Tel: 212 998-3493 > >>New York, NY 10003 Fax: 212 995-4123 > >>- > >> > >>___ > >>Jboss-development mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > > > > _ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > For the latest information about Jetty, please see http://jetty.mortbay. > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > -- > Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 > Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 > http://www.mortbay.com AU Phone: +61-(0)2 98107029 > > Yahoo! Groups Sponsor -~--> > FREE COL
Re: [jetty-discuss] Re: [JBoss-dev] Jetty security problem
Well firstly I'm going to say that we have been having problems with jboss role based authentication for some time. It is not something that we want to get wrong, so I think the time has long since passed where we need a good set of regression tests for this. Now, while I can see that subsequent requests will be in different threads - I cannot see where the second thread is coming from within the same request Nowhere in the Jetty handling or the JBoss adaptor is a new thread created, let alone for a call to the authentication API? As the JBoss JaasSecurityManager class appears to use ThreadLocals to store authentication results then the solution may have to be to authenticate every request rather than just relying on the contents of a session to show that it has previously been authenticated. Note this probably means that we also have to deauthenticate threads when they are returned to the thread pool.I can't see how Jetty can help much here, as ThreadLocals are beyond it's control and can't be cleared by it. I would say that adorning Threads with security priviledges does not sound too robust in any environment that uses thread pools (Ie almost any servlet container). I don't know enough about the jboss authentication mechanism to really comment more - but I'll repeat that we should make security issues top priority. regards Julian Gosnell wrote: > Anatoly, > > Thanks for the precise description of the problem. I shall take a look at > this as soon as I find the time. Probably during the first week of Jan or so. > > Greg, > > Any thoughts about this before I plunge in ? > > Jules > > > Anatoly Akkerman wrote: > > >>Hi, guys >> >>I am running into problems with Jetty + JBoss 3.0alpha >> >>After some debugging here is what I have. >> >>Setup: >>Jetty + JBoss 3.0 >>Sun's Petstore 1.1.1 deployed piecewise (meaning each EJB and WAR are >>packaged separately and deployed in a J2eeScopedDeployer) >>JBossSX configured to pick up usernames, password and roles from files >> >>Here is what happens: >> >>1) a servlet in Petstore takes username and password from a Web form and >>sets "j_username" and "j_password" in the session. Jetty seems to pick >>this stuff up and pass it to JBossUserRealm to authenticate the user. >>JbossUserPrincipal gets created and then proceeds to authenticate with >>with _securityMgr (which is JaasSecurityManager "java:/jaas/other"). >>Authentication succeeds, I see a log and I did doublecheck that >>JaasSecurityManager sets activeSubject to this authenticated subject. >> >>2) Then, it seems, Jetty proceeds to check that this user has required >>roles. It first calls JbossUserRealm.getUser(name) to obtain the >>JBossUserPricipal and then calls isUserInRole(String role). This is where >>the stuff fails miserably. The reason being that Jetty dispatched a >>different thread to do role checking than the one that did >>authentication. Because of this, JaasSecurityManager sees a null >>activeSubject and says that the user does not have required roles. >> >>Now, this happens in a _single_ http request from a web client (just >>clicked 'login' button on a form). I can try hacking a workaround just for >>my demo to work but would like to help fixing this if it is a bug. >> >>- >>Anatoly Akkerman >>Computer Science Dept. >>Courant Institute of Mathematical Sciences, NYU >>715 Broadway, #719 Tel: 212 998-3493 >>New York, NY 10003 Fax: 212 995-4123 >>- >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > Yahoo! Groups Sponsor -~--> > Send FREE Holiday eCards from Yahoo! Greetings. > http://us.click.yahoo.com/IgTaHA/ZQdDAA/ySSFAA/CefplB/TM > -~-> > > For the latest information about Jetty, please see http://jetty.mortbay. > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty security problem
Anatoly, Thanks for the precise description of the problem. I shall take a look at this as soon as I find the time. Probably during the first week of Jan or so. Greg, Any thoughts about this before I plunge in ? Jules Anatoly Akkerman wrote: > Hi, guys > > I am running into problems with Jetty + JBoss 3.0alpha > > After some debugging here is what I have. > > Setup: > Jetty + JBoss 3.0 > Sun's Petstore 1.1.1 deployed piecewise (meaning each EJB and WAR are > packaged separately and deployed in a J2eeScopedDeployer) > JBossSX configured to pick up usernames, password and roles from files > > Here is what happens: > > 1) a servlet in Petstore takes username and password from a Web form and > sets "j_username" and "j_password" in the session. Jetty seems to pick > this stuff up and pass it to JBossUserRealm to authenticate the user. > JbossUserPrincipal gets created and then proceeds to authenticate with > with _securityMgr (which is JaasSecurityManager "java:/jaas/other"). > Authentication succeeds, I see a log and I did doublecheck that > JaasSecurityManager sets activeSubject to this authenticated subject. > > 2) Then, it seems, Jetty proceeds to check that this user has required > roles. It first calls JbossUserRealm.getUser(name) to obtain the > JBossUserPricipal and then calls isUserInRole(String role). This is where > the stuff fails miserably. The reason being that Jetty dispatched a > different thread to do role checking than the one that did > authentication. Because of this, JaasSecurityManager sees a null > activeSubject and says that the user does not have required roles. > > Now, this happens in a _single_ http request from a web client (just > clicked 'login' button on a form). I can try hacking a workaround just for > my demo to work but would like to help fixing this if it is a bug. > > - > Anatoly Akkerman > Computer Science Dept. > Courant Institute of Mathematical Sciences, NYU > 715 Broadway, #719 Tel: 212 998-3493 > New York, NY 10003 Fax: 212 995-4123 > - > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty security problem
Hi, guys I am running into problems with Jetty + JBoss 3.0alpha After some debugging here is what I have. Setup: Jetty + JBoss 3.0 Sun's Petstore 1.1.1 deployed piecewise (meaning each EJB and WAR are packaged separately and deployed in a J2eeScopedDeployer) JBossSX configured to pick up usernames, password and roles from files Here is what happens: 1) a servlet in Petstore takes username and password from a Web form and sets "j_username" and "j_password" in the session. Jetty seems to pick this stuff up and pass it to JBossUserRealm to authenticate the user. JbossUserPrincipal gets created and then proceeds to authenticate with with _securityMgr (which is JaasSecurityManager "java:/jaas/other"). Authentication succeeds, I see a log and I did doublecheck that JaasSecurityManager sets activeSubject to this authenticated subject. 2) Then, it seems, Jetty proceeds to check that this user has required roles. It first calls JbossUserRealm.getUser(name) to obtain the JBossUserPricipal and then calls isUserInRole(String role). This is where the stuff fails miserably. The reason being that Jetty dispatched a different thread to do role checking than the one that did authentication. Because of this, JaasSecurityManager sees a null activeSubject and says that the user does not have required roles. Now, this happens in a _single_ http request from a web client (just clicked 'login' button on a form). I can try hacking a workaround just for my demo to work but would like to help fixing this if it is a bug. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty integration is broken in 2.4.4
thanks dude. Did the trick. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Tuesday, December 11, 2001 7:37 PM > To: [EMAIL PROTECTED]; Jboss-Development@Lists. Sourceforge. Net > Subject: Re: [JBoss-dev] Jetty integration is broken in 2.4.4 > > > > The jetty-service.jar in CVS is out of date. Download the current 2.4.4 > bundle from sourceforge. > > - Original Message - > From: "Bill Burke" <[EMAIL PROTECTED]> > To: "Jboss-Development@Lists. Sourceforge. Net" > <[EMAIL PROTECTED]> > Sent: Tuesday, December 11, 2001 4:16 PM > Subject: [JBoss-dev] Jetty integration is broken in 2.4.4 > > > > Just got latest from CVS. How do I check out this Jetty > integration from > > 2.4.4 so that I can fix it? I can't seem to figure out what module to > use. > > > > Thanks, > > > > Bill > > > > > > [ConfigurationService] Could not create MBean > > DefaultDomain:service=Jetty(org.jboss.jetty.JettyService) > > java.lang.NoClassDefFoundError: org/jboss/logging/log4j/JBossCategory > > at java.lang.Class.getConstructors0(Native Method) > > at java.lang.Class.getConstructors(Class.java:775) > > at > com.sun.management.jmx.Introspector.testCompliance(Introspector.java:95) > > at com.sun.management.jmx.MetaData.testCompliance(MetaData.java:132) > > at > > > com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl > .java:759) > > at > > > org.jboss.configuration.ConfigurationService.create(ConfigurationS > ervice.jav > > a:683) > > at > > > org.jboss.configuration.ConfigurationService.loadConfiguration(Con > figuration > > Service.java:461) > > at java.lang.reflect.Method.invoke(Native Method) > > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > > at org.jboss.Main.(Main.java:200) > > at org.jboss.Main$1.run(Main.java:110) > > at java.security.AccessController.doPrivileged(Native Method) > > at org.jboss.Main.main(Main.java:106) > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty integration is broken in 2.4.4
The jetty-service.jar in CVS is out of date. Download the current 2.4.4 bundle from sourceforge. - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Tuesday, December 11, 2001 4:16 PM Subject: [JBoss-dev] Jetty integration is broken in 2.4.4 > Just got latest from CVS. How do I check out this Jetty integration from > 2.4.4 so that I can fix it? I can't seem to figure out what module to use. > > Thanks, > > Bill > > > [ConfigurationService] Could not create MBean > DefaultDomain:service=Jetty(org.jboss.jetty.JettyService) > java.lang.NoClassDefFoundError: org/jboss/logging/log4j/JBossCategory > at java.lang.Class.getConstructors0(Native Method) > at java.lang.Class.getConstructors(Class.java:775) > at com.sun.management.jmx.Introspector.testCompliance(Introspector.java:95) > at com.sun.management.jmx.MetaData.testCompliance(MetaData.java:132) > at > com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:759) > at > org.jboss.configuration.ConfigurationService.create(ConfigurationService.jav > a:683) > at > org.jboss.configuration.ConfigurationService.loadConfiguration(Configuration > Service.java:461) > at java.lang.reflect.Method.invoke(Native Method) > at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at org.jboss.Main.(Main.java:200) > at org.jboss.Main$1.run(Main.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.Main.main(Main.java:106) > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty integration is broken in 2.4.4
Just got latest from CVS. How do I check out this Jetty integration from 2.4.4 so that I can fix it? I can't seem to figure out what module to use. Thanks, Bill [ConfigurationService] Could not create MBean DefaultDomain:service=Jetty(org.jboss.jetty.JettyService) java.lang.NoClassDefFoundError: org/jboss/logging/log4j/JBossCategory at java.lang.Class.getConstructors0(Native Method) at java.lang.Class.getConstructors(Class.java:775) at com.sun.management.jmx.Introspector.testCompliance(Introspector.java:95) at com.sun.management.jmx.MetaData.testCompliance(MetaData.java:132) at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:759) at org.jboss.configuration.ConfigurationService.create(ConfigurationService.jav a:683) at org.jboss.configuration.ConfigurationService.loadConfiguration(Configuration Service.java:461) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.Main.(Main.java:200) at org.jboss.Main$1.run(Main.java:110) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.Main.main(Main.java:106) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty
That is sort of what I was thinking too. Instead of one huge app like petstore, we could have several smaller examples. These would be specific examples of how to do things in Jboss. Al [EMAIL PROTECTED] wrote: >I am thinking more of 'kickstart' examples being deployed at get GO ... for >testing/verifying to get that "instant gratification" feeling ... also then >it would be very *good* to have several (heavy) app examples contributed ? >... > >/peter_f > >on 1-12-04 17.36, Julian Gosnell at [EMAIL PROTECTED] wrote: > >>I suppose there are legal issues preventing us from >>shipping a working PetStore as part of this APP ? >> >>Jules >> >>--- Allen Fogleson <[EMAIL PROTECTED]> wrote: > >>Actually this sounds like something interesting. I'd >> >>>be willing to take >>>up the mantle on this one. >>> >>>I wonder about the idea of a full app, or maybe >>>some simple examples >>>along the lines of tomcats "examples" web app. (of >>>course using EJB, JSP >>>and possibly MDB in there.) >>> >>>Either way it sounds interesting, and I have been >>>sitting on my duff >>>long enough in here that I need to donate some stuff >>>back. >>> >>>Al >>> >>>Julian Gosnell wrote: >>> --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > >>>Julian, >>> Well, I guess we need to kick of the >>>jboss-demo.ear >>> project ! Any takers ? Jules >Me myself and I -would prefer to have some apps >deployed at starup of JBoss >as wars / ears / sar - in that it makes for so > >>>much >>> >better social engeniring >... > >Yours >/peter_f > >http://www.ipagents.com/humanerror.mp3 > >on 1-12-04 03.12, Julian Gosnell at >[EMAIL PROTECTED] wrote: > >>Peter, >> >>I'm not sure what you are saying ! >> >>Do you think there should be apps pre-deployed ? >> >>If so where - I removed them from '/' because i >> >felt it might hinder people > >>who >>wanted to deploy their own stuff. >> >>Jules >> >> >>Peter Fagerlund wrote: >> >>>As earlier thread mentioned/suggested - both >>> >>>the >>> >test and 'kick start' would > >>>*grow* tremendously by having some apps >>> >>>deployed >>> >from get GO ... > >>>? >>> >>>/peter_f >>> >>>on 1-12-04 01.06, Julian Gosnell at >>> >[EMAIL PROTECTED] wrote: > Who is suggesting you hit these urls ? As bundled, Jetty comes with no apps deployed >>>- >>> >so hitting these urls WILL > tell you that nothing is found. You won't find anything there until you PUT >something there. > It looks as if some doc is out of date >somewhere. > Give me a pointer to it and I shall update it. Thanks, Jules "Haller, Joe" wrote: >I have downloaded and installed > >JBoss-2.4.3_Jetty-3.1.3-1 > >I am operating under JDK 1.3.1_01. > >I have followed the instructions in the > >>>README >>> >and it appears > >to start. > >However: > >Hitting URLs http://localhost:8080, > >http://localhost:8080/demo, > >http://localhost:8080/jboss, etc. give the > >following error: > >HTTP ERROR: 404 Not Found >Could not find resource for / >RequestURI=/ > >Hitting URL http://localhost:8082 appears to > >give some > >administrative page. > >I get a similar error when accessing some of > >online documentation > >on the JBoss web site: > >http://www.jboss.org/documentation/HTML/ch02.html. > >Can anyone help here? > >Regards, >J. Haller > >>> ___ >Jboss-development mailing list >[EMAIL PROTECTED] > >>> >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >>>_ >>> Do You Yahoo!? Get your free @yahoo.com address at >http://mail.yahoo.com > ___ Jboss-development mailing list [EMAIL PROTECTED] >>> >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >> >>> >>>_ >>> >>Do You Yahoo!? >>Get your free @yahoo.com address at >> >http://mail.yahoo.com > > > >>> >>> >>> Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ >>>discover and win it! >>> The competition end
Re: [JBoss-dev] Jetty
I havent investigated it, but yeah I imagine there are [EMAIL PROTECTED] wrote: >I suppose there are legal issues preventing us from >shipping a working PetStore as part of this APP ? > >Jules > > --- Allen Fogleson <[EMAIL PROTECTED]> wrote: > >Actually this sounds like something interesting. I'd > >>be willing to take >>up the mantle on this one. >> >>I wonder about the idea of a full app, or maybe >>some simple examples >>along the lines of tomcats "examples" web app. (of >>course using EJB, JSP >>and possibly MDB in there.) >> >>Either way it sounds interesting, and I have been >>sitting on my duff >>long enough in here that I need to donate some stuff >>back. >> >>Al >> >>Julian Gosnell wrote: >> >> > --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > >>Julian, >> > >> >Well, I guess we need to kick of the >>jboss-demo.ear >> >project ! >> > >> >Any takers ? >> > >> > >> >Jules >> > >> >>Me myself and I -would prefer to have some apps >> >>deployed at starup of JBoss >> >>as wars / ears / sar - in that it makes for so >>much >> >>better social engeniring >> >>... >> >> >> >>Yours >> >>/peter_f >> >> >> >>http://www.ipagents.com/humanerror.mp3 >> >> >> >>on 1-12-04 03.12, Julian Gosnell at >> >>[EMAIL PROTECTED] wrote: >> >> >> >>>Peter, >> >>> >> >>>I'm not sure what you are saying ! >> >>> >> >>>Do you think there should be apps pre-deployed ? >> >>> >> >>>If so where - I removed them from '/' because i >> >>> >> >>felt it might hinder people >> >> >> >>>who >> >>>wanted to deploy their own stuff. >> >>> >> >>>Jules >> >>> >> >>> >> >>>Peter Fagerlund wrote: >> >>> >> As earlier thread mentioned/suggested - both >>the >> >> >>test and 'kick start' would >> >> >> *grow* tremendously by having some apps >>deployed >> >> >>from get GO ... >> >> >> ? >> >> /peter_f >> >> on 1-12-04 01.06, Julian Gosnell at >> >> >>[EMAIL PROTECTED] wrote: >> >> >> >Who is suggesting you hit these urls ? >> > >> >As bundled, Jetty comes with no apps deployed >>- >> > >> >>so hitting these urls WILL >> >> >> >tell you that nothing is found. >> > >> >You won't find anything there until you PUT >> > >> >>something there. >> >> >> >It looks as if some doc is out of date >> > >> >>somewhere. >> >> >> >Give me a pointer to it and I shall update it. >> > >> >Thanks, >> > >> >Jules >> > >> > >> >"Haller, Joe" wrote: >> > >> >>I have downloaded and installed >> >> >> >>JBoss-2.4.3_Jetty-3.1.3-1 >> >> >> >>I am operating under JDK 1.3.1_01. >> >> >> >>I have followed the instructions in the >>README >> >> >> >>and it appears >> >> >> >>to start. >> >> >> >>However: >> >> >> >>Hitting URLs http://localhost:8080, >> >> >> >>http://localhost:8080/demo, >> >> >> >>http://localhost:8080/jboss, etc. give the >> >> >> >>following error: >> >> >> >>HTTP ERROR: 404 Not Found >> >>Could not find resource for / >> >>RequestURI=/ >> >> >> >>Hitting URL http://localhost:8082 appears to >> >> >> >>give some >> >> >> >>administrative page. >> >> >> >>I get a similar error when accessing some of >> >> >> >>online documentation >> >> >> >>on the JBoss web site: >> >> >> http://www.jboss.org/documentation/HTML/ch02.html. >> >> >> >>Can anyone help here? >> >> >> >>Regards, >> >>J. Haller >> >> >> >> >>>___ >>> >> >>Jboss-development mailing list >> >>[EMAIL PROTECTED] >> >> >> >> >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > >> > >> > >> >> >>_ >> > >> >Do You Yahoo!? >> >Get your free @yahoo.com address at >> > >> >>http://mail.yahoo.com >> >> >> > >> >>>___ >>> >> >Jboss-development mailing list >> >[EMAIL PROTECTED] >> > >> >> >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > >> >>> >> >>> >> >> >>_ >> > >> >>>Do You Yahoo!? >> >>>Get your free @yahoo.com address at >> >>> >> >>http://mail.yahoo.com >> >> >> >> >> >> >> > >> >> >> >> >Nokia 5510 looks weird sounds great. >> >Go to http://uk.promotions.yahoo.com/nokia/ >>discover and win it! >> >The competition ends 16 th of December 2001. >> >=== message truncated === > > >Nokia 5510 looks weird sounds great. >Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! >The competition ends 16 th of December 2001. > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty
I am thinking more of 'kickstart' examples being deployed at get GO ... for testing/verifying to get that "instant gratification" feeling ... also then it would be very *good* to have several (heavy) app examples contributed ? ... /peter_f on 1-12-04 17.36, Julian Gosnell at [EMAIL PROTECTED] wrote: > I suppose there are legal issues preventing us from > shipping a working PetStore as part of this APP ? > > Jules > > --- Allen Fogleson <[EMAIL PROTECTED]> wrote: > > Actually this sounds like something interesting. I'd >> be willing to take >> up the mantle on this one. >> >> I wonder about the idea of a full app, or maybe >> some simple examples >> along the lines of tomcats "examples" web app. (of >> course using EJB, JSP >> and possibly MDB in there.) >> >> Either way it sounds interesting, and I have been >> sitting on my duff >> long enough in here that I need to donate some stuff >> back. >> >> Al >> >> Julian Gosnell wrote: >> >>> --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > >> Julian, >>> >>> Well, I guess we need to kick of the >> jboss-demo.ear >>> project ! >>> >>> Any takers ? >>> >>> >>> Jules >>> Me myself and I -would prefer to have some apps deployed at starup of JBoss as wars / ears / sar - in that it makes for so >> much better social engeniring ... Yours /peter_f http://www.ipagents.com/humanerror.mp3 on 1-12-04 03.12, Julian Gosnell at [EMAIL PROTECTED] wrote: > Peter, > > I'm not sure what you are saying ! > > Do you think there should be apps pre-deployed ? > > If so where - I removed them from '/' because i > felt it might hinder people > who > wanted to deploy their own stuff. > > Jules > > > Peter Fagerlund wrote: > >> As earlier thread mentioned/suggested - both >> the >> test and 'kick start' would >> *grow* tremendously by having some apps >> deployed >> from get GO ... >> ? >> >> /peter_f >> >> on 1-12-04 01.06, Julian Gosnell at >> [EMAIL PROTECTED] wrote: >>> Who is suggesting you hit these urls ? >>> >>> As bundled, Jetty comes with no apps deployed >> - >>> so hitting these urls WILL >>> tell you that nothing is found. >>> >>> You won't find anything there until you PUT >>> something there. >>> It looks as if some doc is out of date >>> somewhere. >>> Give me a pointer to it and I shall update it. >>> >>> Thanks, >>> >>> Jules >>> >>> >>> "Haller, Joe" wrote: >>> I have downloaded and installed JBoss-2.4.3_Jetty-3.1.3-1 I am operating under JDK 1.3.1_01. I have followed the instructions in the >> README and it appears to start. However: Hitting URLs http://localhost:8080, http://localhost:8080/demo, http://localhost:8080/jboss, etc. give the following error: HTTP ERROR: 404 Not Found Could not find resource for / RequestURI=/ Hitting URL http://localhost:8082 appears to give some administrative page. I get a similar error when accessing some of online documentation on the JBoss web site: >> http://www.jboss.org/documentation/HTML/ch02.html. Can anyone help here? Regards, J. Haller >> >> >>> ___ Jboss-development mailing list [EMAIL PROTECTED] >> >> >> https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >>> >> >> >> _ >>> >>> Do You Yahoo!? >>> Get your free @yahoo.com address at >>> http://mail.yahoo.com >>> >> >>> ___ >>> Jboss-development mailing list >>> [EMAIL PROTECTED] >>> >> >> >> https://lists.sourceforge.net/lists/listinfo/jboss-development >>> > > >> >> >> _ >>> > Do You Yahoo!? > Get your free @yahoo.com address at > http://mail.yahoo.com >>> >> >> >> >>> Nokia 5510 looks weird sounds great. >>> Go to http://uk.promotions.yahoo.com/nokia/ >> discover and win it! >>> The competition ends 16 th of December 2001. >> > === message truncated === > > > Nokia 5510 looks weird sounds great. > Go to http://uk.promotions.yahoo.com/nokia/ discover a
RE: [JBoss-dev] Jetty
Forgot 8) Local and Remote objects -Original Message- From: Hicks, James Sent: Tuesday, December 04, 2001 10:46 AM To: Julian Gosnell; Allen Fogleson Cc: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Jetty Why not decide on an app that will run inside JBoss with integrated tomcat and jetty, and non-integrated web servers. That way there is something for everyone. Here are some main features the app should have 1) Built for JBoss 3.0 2) Use all types of EJBs (BMP, CMP 2, Session Beans, and MDB) 3) Built using Design Patterns 4) Use JavaMail 5) Have container managed authentication (JAAS & JBossSX) 6) Have web-based and swing based clients. 7) Maybe include a sample of web-services in JBoss?? Anyone have some solid ideas? James Hicks -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 10:36 AM To: Allen Fogleson Cc: '[EMAIL PROTECTED]' Subject: Re: [JBoss-dev] Jetty I suppose there are legal issues preventing us from shipping a working PetStore as part of this APP ? Jules --- Allen Fogleson <[EMAIL PROTECTED]> wrote: > Actually this sounds like something interesting. I'd > be willing to take > up the mantle on this one. > > I wonder about the idea of a full app, or maybe > some simple examples > along the lines of tomcats "examples" web app. (of > course using EJB, JSP > and possibly MDB in there.) > > Either way it sounds interesting, and I have been > sitting on my duff > long enough in here that I need to donate some stuff > back. > > Al > > Julian Gosnell wrote: > > > --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > > Julian, > > > >Well, I guess we need to kick of the > jboss-demo.ear > >project ! > > > >Any takers ? > > > > > >Jules > > > >>Me myself and I -would prefer to have some apps > >>deployed at starup of JBoss > >>as wars / ears / sar - in that it makes for so > much > >>better social engeniring > >>... > >> > >>Yours > >>/peter_f > >> > >>http://www.ipagents.com/humanerror.mp3 > >> > >>on 1-12-04 03.12, Julian Gosnell at > >>[EMAIL PROTECTED] wrote: > >> > >>>Peter, > >>> > >>>I'm not sure what you are saying ! > >>> > >>>Do you think there should be apps pre-deployed ? > >>> > >>>If so where - I removed them from '/' because i > >>> > >>felt it might hinder people > >> > >>>who > >>>wanted to deploy their own stuff. > >>> > >>>Jules > >>> > >>> > >>>Peter Fagerlund wrote: > >>> > >>>>As earlier thread mentioned/suggested - both > the > >>>> > >>test and 'kick start' would > >> > >>>>*grow* tremendously by having some apps > deployed > >>>> > >>from get GO ... > >> > >>>>? > >>>> > >>>>/peter_f > >>>> > >>>>on 1-12-04 01.06, Julian Gosnell at > >>>> > >>[EMAIL PROTECTED] wrote: > >> > >>>>>Who is suggesting you hit these urls ? > >>>>> > >>>>>As bundled, Jetty comes with no apps deployed > - > >>>>> > >>so hitting these urls WILL > >> > >>>>>tell you that nothing is found. > >>>>> > >>>>>You won't find anything there until you PUT > >>>>> > >>something there. > >> > >>>>>It looks as if some doc is out of date > >>>>> > >>somewhere. > >> > >>>>>Give me a pointer to it and I shall update it. > >>>>> > >>>>>Thanks, > >>>>> > >>>>>Jules > >>>>> > >>>>> > >>>>>"Haller, Joe" wrote: > >>>>> > >>>>>>I have downloaded and installed > >>>>>> > >>JBoss-2.4.3_Jetty-3.1.3-1 > >> > >>>>>>I am operating under JDK 1.3.1_01. > >>>>>> > >>>>>>I have followed the instructions in the > README > >>>>>> > >>and it appears > >> > >>>>>>to start. > &
RE: [JBoss-dev] Jetty
Why not decide on an app that will run inside JBoss with integrated tomcat and jetty, and non-integrated web servers. That way there is something for everyone. Here are some main features the app should have 1) Built for JBoss 3.0 2) Use all types of EJBs (BMP, CMP 2, Session Beans, and MDB) 3) Built using Design Patterns 4) Use JavaMail 5) Have container managed authentication (JAAS & JBossSX) 6) Have web-based and swing based clients. 7) Maybe include a sample of web-services in JBoss?? Anyone have some solid ideas? James Hicks -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 10:36 AM To: Allen Fogleson Cc: '[EMAIL PROTECTED]' Subject: Re: [JBoss-dev] Jetty I suppose there are legal issues preventing us from shipping a working PetStore as part of this APP ? Jules --- Allen Fogleson <[EMAIL PROTECTED]> wrote: > Actually this sounds like something interesting. I'd > be willing to take > up the mantle on this one. > > I wonder about the idea of a full app, or maybe > some simple examples > along the lines of tomcats "examples" web app. (of > course using EJB, JSP > and possibly MDB in there.) > > Either way it sounds interesting, and I have been > sitting on my duff > long enough in here that I need to donate some stuff > back. > > Al > > Julian Gosnell wrote: > > > --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > > Julian, > > > >Well, I guess we need to kick of the > jboss-demo.ear > >project ! > > > >Any takers ? > > > > > >Jules > > > >>Me myself and I -would prefer to have some apps > >>deployed at starup of JBoss > >>as wars / ears / sar - in that it makes for so > much > >>better social engeniring > >>... > >> > >>Yours > >>/peter_f > >> > >>http://www.ipagents.com/humanerror.mp3 > >> > >>on 1-12-04 03.12, Julian Gosnell at > >>[EMAIL PROTECTED] wrote: > >> > >>>Peter, > >>> > >>>I'm not sure what you are saying ! > >>> > >>>Do you think there should be apps pre-deployed ? > >>> > >>>If so where - I removed them from '/' because i > >>> > >>felt it might hinder people > >> > >>>who > >>>wanted to deploy their own stuff. > >>> > >>>Jules > >>> > >>> > >>>Peter Fagerlund wrote: > >>> > >>>>As earlier thread mentioned/suggested - both > the > >>>> > >>test and 'kick start' would > >> > >>>>*grow* tremendously by having some apps > deployed > >>>> > >>from get GO ... > >> > >>>>? > >>>> > >>>>/peter_f > >>>> > >>>>on 1-12-04 01.06, Julian Gosnell at > >>>> > >>[EMAIL PROTECTED] wrote: > >> > >>>>>Who is suggesting you hit these urls ? > >>>>> > >>>>>As bundled, Jetty comes with no apps deployed > - > >>>>> > >>so hitting these urls WILL > >> > >>>>>tell you that nothing is found. > >>>>> > >>>>>You won't find anything there until you PUT > >>>>> > >>something there. > >> > >>>>>It looks as if some doc is out of date > >>>>> > >>somewhere. > >> > >>>>>Give me a pointer to it and I shall update it. > >>>>> > >>>>>Thanks, > >>>>> > >>>>>Jules > >>>>> > >>>>> > >>>>>"Haller, Joe" wrote: > >>>>> > >>>>>>I have downloaded and installed > >>>>>> > >>JBoss-2.4.3_Jetty-3.1.3-1 > >> > >>>>>>I am operating under JDK 1.3.1_01. > >>>>>> > >>>>>>I have followed the instructions in the > README > >>>>>> > >>and it appears > >> > >>>>>>to start. > >>>>>> > >>>>>>However: > >>>>>> > >>>>>>Hitting URLs http://localhost:8080, > >>>>>> >
RE: [JBoss-dev] Jetty
petstore is running on jboss.org i am about to link it marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Julian Gosnell |Sent: Tuesday, December 04, 2001 11:36 AM |To: Allen Fogleson |Cc: '[EMAIL PROTECTED]' |Subject: Re: [JBoss-dev] Jetty | | |I suppose there are legal issues preventing us from |shipping a working PetStore as part of this APP ? | |Jules | | --- Allen Fogleson <[EMAIL PROTECTED]> wrote: > |Actually this sounds like something interesting. I'd |> be willing to take |> up the mantle on this one. |> |> I wonder about the idea of a full app, or maybe |> some simple examples |> along the lines of tomcats "examples" web app. (of |> course using EJB, JSP |> and possibly MDB in there.) |> |> Either way it sounds interesting, and I have been |> sitting on my duff |> long enough in here that I need to donate some stuff |> back. |> |> Al |> |> Julian Gosnell wrote: |> |> > --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > |> Julian, |> > |> >Well, I guess we need to kick of the |> jboss-demo.ear |> >project ! |> > |> >Any takers ? |> > |> > |> >Jules |> > |> >>Me myself and I -would prefer to have some apps |> >>deployed at starup of JBoss |> >>as wars / ears / sar - in that it makes for so |> much |> >>better social engeniring |> >>... |> >> |> >>Yours |> >>/peter_f |> >> |> >>http://www.ipagents.com/humanerror.mp3 |> >> |> >>on 1-12-04 03.12, Julian Gosnell at |> >>[EMAIL PROTECTED] wrote: |> >> |> >>>Peter, |> >>> |> >>>I'm not sure what you are saying ! |> >>> |> >>>Do you think there should be apps pre-deployed ? |> >>> |> >>>If so where - I removed them from '/' because i |> >>> |> >>felt it might hinder people |> >> |> >>>who |> >>>wanted to deploy their own stuff. |> >>> |> >>>Jules |> >>> |> >>> |> >>>Peter Fagerlund wrote: |> >>> |> >>>>As earlier thread mentioned/suggested - both |> the |> >>>> |> >>test and 'kick start' would |> >> |> >>>>*grow* tremendously by having some apps |> deployed |> >>>> |> >>from get GO ... |> >> |> >>>>? |> >>>> |> >>>>/peter_f |> >>>> |> >>>>on 1-12-04 01.06, Julian Gosnell at |> >>>> |> >>[EMAIL PROTECTED] wrote: |> >> |> >>>>>Who is suggesting you hit these urls ? |> >>>>> |> >>>>>As bundled, Jetty comes with no apps deployed |> - |> >>>>> |> >>so hitting these urls WILL |> >> |> >>>>>tell you that nothing is found. |> >>>>> |> >>>>>You won't find anything there until you PUT |> >>>>> |> >>something there. |> >> |> >>>>>It looks as if some doc is out of date |> >>>>> |> >>somewhere. |> >> |> >>>>>Give me a pointer to it and I shall update it. |> >>>>> |> >>>>>Thanks, |> >>>>> |> >>>>>Jules |> >>>>> |> >>>>> |> >>>>>"Haller, Joe" wrote: |> >>>>> |> >>>>>>I have downloaded and installed |> >>>>>> |> >>JBoss-2.4.3_Jetty-3.1.3-1 |> >> |> >>>>>>I am operating under JDK 1.3.1_01. |> >>>>>> |> >>>>>>I have followed the instructions in the |> README |> >>>>>> |> >>and it appears |> >> |> >>>>>>to start. |> >>>>>> |> >>>>>>However: |> >>>>>> |> >>>>>>Hitting URLs http://localhost:8080, |> >>>>>> |> >>http://localhost:8080/demo, |> >> |> >>>>>>http://localhost:8080/jboss, etc. give the |> >>>>>> |> >>following error: |> >> |> >>>>>>HTTP ERROR: 404 Not Found |> >>>>>>Could not find resource for / |> >>>>>>RequestURI
Re: [JBoss-dev] Jetty
I suppose there are legal issues preventing us from shipping a working PetStore as part of this APP ? Jules --- Allen Fogleson <[EMAIL PROTECTED]> wrote: > Actually this sounds like something interesting. I'd > be willing to take > up the mantle on this one. > > I wonder about the idea of a full app, or maybe > some simple examples > along the lines of tomcats "examples" web app. (of > course using EJB, JSP > and possibly MDB in there.) > > Either way it sounds interesting, and I have been > sitting on my duff > long enough in here that I need to donate some stuff > back. > > Al > > Julian Gosnell wrote: > > > --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > > Julian, > > > >Well, I guess we need to kick of the > jboss-demo.ear > >project ! > > > >Any takers ? > > > > > >Jules > > > >>Me myself and I -would prefer to have some apps > >>deployed at starup of JBoss > >>as wars / ears / sar - in that it makes for so > much > >>better social engeniring > >>... > >> > >>Yours > >>/peter_f > >> > >>http://www.ipagents.com/humanerror.mp3 > >> > >>on 1-12-04 03.12, Julian Gosnell at > >>[EMAIL PROTECTED] wrote: > >> > >>>Peter, > >>> > >>>I'm not sure what you are saying ! > >>> > >>>Do you think there should be apps pre-deployed ? > >>> > >>>If so where - I removed them from '/' because i > >>> > >>felt it might hinder people > >> > >>>who > >>>wanted to deploy their own stuff. > >>> > >>>Jules > >>> > >>> > >>>Peter Fagerlund wrote: > >>> > As earlier thread mentioned/suggested - both > the > > >>test and 'kick start' would > >> > *grow* tremendously by having some apps > deployed > > >>from get GO ... > >> > ? > > /peter_f > > on 1-12-04 01.06, Julian Gosnell at > > >>[EMAIL PROTECTED] wrote: > >> > >Who is suggesting you hit these urls ? > > > >As bundled, Jetty comes with no apps deployed > - > > > >>so hitting these urls WILL > >> > >tell you that nothing is found. > > > >You won't find anything there until you PUT > > > >>something there. > >> > >It looks as if some doc is out of date > > > >>somewhere. > >> > >Give me a pointer to it and I shall update it. > > > >Thanks, > > > >Jules > > > > > >"Haller, Joe" wrote: > > > >>I have downloaded and installed > >> > >>JBoss-2.4.3_Jetty-3.1.3-1 > >> > >>I am operating under JDK 1.3.1_01. > >> > >>I have followed the instructions in the > README > >> > >>and it appears > >> > >>to start. > >> > >>However: > >> > >>Hitting URLs http://localhost:8080, > >> > >>http://localhost:8080/demo, > >> > >>http://localhost:8080/jboss, etc. give the > >> > >>following error: > >> > >>HTTP ERROR: 404 Not Found > >>Could not find resource for / > >>RequestURI=/ > >> > >>Hitting URL http://localhost:8082 appears to > >> > >>give some > >> > >>administrative page. > >> > >>I get a similar error when accessing some of > >> > >>online documentation > >> > >>on the JBoss web site: > >> > > >>http://www.jboss.org/documentation/HTML/ch02.html. > >> > >>Can anyone help here? > >> > >>Regards, > >>J. Haller > >> > > >>___ > >>Jboss-development mailing list > >>[EMAIL PROTECTED] > >> > > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > >_ > > > >Do You Yahoo!? > >Get your free @yahoo.com address at > > > >>http://mail.yahoo.com > >> > > > > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > > > > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > >>> > >>> > > >_ > > > >>>Do You Yahoo!? > >>>Get your free @yahoo.com address at > >>> > >>http://mail.yahoo.com > >> > >> > >> > > > > > > >Nokia 5510 looks weird sounds great. > >Go to http://uk.promotions.yahoo.com/nokia/ > discover and win it! > >The competition ends 16 th of December 2001. > === message truncated === Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty
Actually this sounds like something interesting. I'd be willing to take up the mantle on this one. I wonder about the idea of a full app, or maybe some simple examples along the lines of tomcats "examples" web app. (of course using EJB, JSP and possibly MDB in there.) Either way it sounds interesting, and I have been sitting on my duff long enough in here that I need to donate some stuff back. Al Julian Gosnell wrote: > --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > Julian, > >Well, I guess we need to kick of the jboss-demo.ear >project ! > >Any takers ? > > >Jules > >>Me myself and I -would prefer to have some apps >>deployed at starup of JBoss >>as wars / ears / sar - in that it makes for so much >>better social engeniring >>... >> >>Yours >>/peter_f >> >>http://www.ipagents.com/humanerror.mp3 >> >>on 1-12-04 03.12, Julian Gosnell at >>[EMAIL PROTECTED] wrote: >> >>>Peter, >>> >>>I'm not sure what you are saying ! >>> >>>Do you think there should be apps pre-deployed ? >>> >>>If so where - I removed them from '/' because i >>> >>felt it might hinder people >> >>>who >>>wanted to deploy their own stuff. >>> >>>Jules >>> >>> >>>Peter Fagerlund wrote: >>> As earlier thread mentioned/suggested - both the >>test and 'kick start' would >> *grow* tremendously by having some apps deployed >>from get GO ... >> ? /peter_f on 1-12-04 01.06, Julian Gosnell at >>[EMAIL PROTECTED] wrote: >> >Who is suggesting you hit these urls ? > >As bundled, Jetty comes with no apps deployed - > >>so hitting these urls WILL >> >tell you that nothing is found. > >You won't find anything there until you PUT > >>something there. >> >It looks as if some doc is out of date > >>somewhere. >> >Give me a pointer to it and I shall update it. > >Thanks, > >Jules > > >"Haller, Joe" wrote: > >>I have downloaded and installed >> >>JBoss-2.4.3_Jetty-3.1.3-1 >> >>I am operating under JDK 1.3.1_01. >> >>I have followed the instructions in the README >> >>and it appears >> >>to start. >> >>However: >> >>Hitting URLs http://localhost:8080, >> >>http://localhost:8080/demo, >> >>http://localhost:8080/jboss, etc. give the >> >>following error: >> >>HTTP ERROR: 404 Not Found >>Could not find resource for / >>RequestURI=/ >> >>Hitting URL http://localhost:8082 appears to >> >>give some >> >>administrative page. >> >>I get a similar error when accessing some of >> >>online documentation >> >>on the JBoss web site: >> >>http://www.jboss.org/documentation/HTML/ch02.html. >> >>Can anyone help here? >> >>Regards, >>J. Haller >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >> >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > >_ > >Do You Yahoo!? >Get your free @yahoo.com address at > >>http://mail.yahoo.com >> > >___ >Jboss-development mailing list >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/jboss-development > >>> >>> >_ > >>>Do You Yahoo!? >>>Get your free @yahoo.com address at >>> >>http://mail.yahoo.com >> >> >> > > >Nokia 5510 looks weird sounds great. >Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! >The competition ends 16 th of December 2001. > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty
--- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > Julian, Well, I guess we need to kick of the jboss-demo.ear project ! Any takers ? Jules > > Me myself and I -would prefer to have some apps > deployed at starup of JBoss > as wars / ears / sar - in that it makes for so much > better social engeniring > ... > > Yours > /peter_f > > http://www.ipagents.com/humanerror.mp3 > > on 1-12-04 03.12, Julian Gosnell at > [EMAIL PROTECTED] wrote: > > > Peter, > > > > I'm not sure what you are saying ! > > > > Do you think there should be apps pre-deployed ? > > > > If so where - I removed them from '/' because i > felt it might hinder people > > who > > wanted to deploy their own stuff. > > > > Jules > > > > > > Peter Fagerlund wrote: > > > >> As earlier thread mentioned/suggested - both the > test and 'kick start' would > >> *grow* tremendously by having some apps deployed > from get GO ... > >> > >> ? > >> > >> /peter_f > >> > >> on 1-12-04 01.06, Julian Gosnell at > [EMAIL PROTECTED] wrote: > >> > >>> Who is suggesting you hit these urls ? > >>> > >>> As bundled, Jetty comes with no apps deployed - > so hitting these urls WILL > >>> tell you that nothing is found. > >>> > >>> You won't find anything there until you PUT > something there. > >>> > >>> It looks as if some doc is out of date > somewhere. > >>> > >>> Give me a pointer to it and I shall update it. > >>> > >>> Thanks, > >>> > >>> Jules > >>> > >>> > >>> "Haller, Joe" wrote: > >>> > I have downloaded and installed > JBoss-2.4.3_Jetty-3.1.3-1 > I am operating under JDK 1.3.1_01. > > I have followed the instructions in the README > and it appears > to start. > > However: > > Hitting URLs http://localhost:8080, > http://localhost:8080/demo, > http://localhost:8080/jboss, etc. give the > following error: > > HTTP ERROR: 404 Not Found > Could not find resource for / > RequestURI=/ > > Hitting URL http://localhost:8082 appears to > give some > administrative page. > > I get a similar error when accessing some of > online documentation > on the JBoss web site: > http://www.jboss.org/documentation/HTML/ch02.html. > > Can anyone help here? > > Regards, > J. Haller > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > >>> > >>> > >>> > _ > >>> Do You Yahoo!? > >>> Get your free @yahoo.com address at > http://mail.yahoo.com > >>> > >>> > >>> ___ > >>> Jboss-development mailing list > >>> [EMAIL PROTECTED] > >>> > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > _ > > Do You Yahoo!? > > Get your free @yahoo.com address at > http://mail.yahoo.com > > > Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty
Julian, Me myself and I -would prefer to have some apps deployed at starup of JBoss as wars / ears / sar - in that it makes for so much better social engeniring ... Yours /peter_f http://www.ipagents.com/humanerror.mp3 on 1-12-04 03.12, Julian Gosnell at [EMAIL PROTECTED] wrote: > Peter, > > I'm not sure what you are saying ! > > Do you think there should be apps pre-deployed ? > > If so where - I removed them from '/' because i felt it might hinder people > who > wanted to deploy their own stuff. > > Jules > > > Peter Fagerlund wrote: > >> As earlier thread mentioned/suggested - both the test and 'kick start' would >> *grow* tremendously by having some apps deployed from get GO ... >> >> ? >> >> /peter_f >> >> on 1-12-04 01.06, Julian Gosnell at [EMAIL PROTECTED] wrote: >> >>> Who is suggesting you hit these urls ? >>> >>> As bundled, Jetty comes with no apps deployed - so hitting these urls WILL >>> tell you that nothing is found. >>> >>> You won't find anything there until you PUT something there. >>> >>> It looks as if some doc is out of date somewhere. >>> >>> Give me a pointer to it and I shall update it. >>> >>> Thanks, >>> >>> Jules >>> >>> >>> "Haller, Joe" wrote: >>> I have downloaded and installed JBoss-2.4.3_Jetty-3.1.3-1 I am operating under JDK 1.3.1_01. I have followed the instructions in the README and it appears to start. However: Hitting URLs http://localhost:8080, http://localhost:8080/demo, http://localhost:8080/jboss, etc. give the following error: HTTP ERROR: 404 Not Found Could not find resource for / RequestURI=/ Hitting URL http://localhost:8082 appears to give some administrative page. I get a similar error when accessing some of online documentation on the JBoss web site: http://www.jboss.org/documentation/HTML/ch02.html. Can anyone help here? Regards, J. Haller ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >>> _ >>> Do You Yahoo!? >>> Get your free @yahoo.com address at http://mail.yahoo.com >>> >>> >>> ___ >>> Jboss-development mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty
Peter, I'm not sure what you are saying ! Do you think there should be apps pre-deployed ? If so where - I removed them from '/' because i felt it might hinder people who wanted to deploy their own stuff. Jules Peter Fagerlund wrote: > As earlier thread mentioned/suggested - both the test and 'kick start' would > *grow* tremendously by having some apps deployed from get GO ... > > ? > > /peter_f > > on 1-12-04 01.06, Julian Gosnell at [EMAIL PROTECTED] wrote: > > > Who is suggesting you hit these urls ? > > > > As bundled, Jetty comes with no apps deployed - so hitting these urls WILL > > tell you that nothing is found. > > > > You won't find anything there until you PUT something there. > > > > It looks as if some doc is out of date somewhere. > > > > Give me a pointer to it and I shall update it. > > > > Thanks, > > > > Jules > > > > > > "Haller, Joe" wrote: > > > >> I have downloaded and installed JBoss-2.4.3_Jetty-3.1.3-1 > >> I am operating under JDK 1.3.1_01. > >> > >> I have followed the instructions in the README and it appears > >> to start. > >> > >> However: > >> > >> Hitting URLs http://localhost:8080, http://localhost:8080/demo, > >> http://localhost:8080/jboss, etc. give the following error: > >> > >> HTTP ERROR: 404 Not Found > >> Could not find resource for / > >> RequestURI=/ > >> > >> Hitting URL http://localhost:8082 appears to give some > >> administrative page. > >> > >> I get a similar error when accessing some of online documentation > >> on the JBoss web site: http://www.jboss.org/documentation/HTML/ch02.html. > >> > >> Can anyone help here? > >> > >> Regards, > >> J. Haller > >> > >> ___ > >> Jboss-development mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > _ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty
As earlier thread mentioned/suggested - both the test and 'kick start' would *grow* tremendously by having some apps deployed from get GO ... ? /peter_f on 1-12-04 01.06, Julian Gosnell at [EMAIL PROTECTED] wrote: > Who is suggesting you hit these urls ? > > As bundled, Jetty comes with no apps deployed - so hitting these urls WILL > tell you that nothing is found. > > You won't find anything there until you PUT something there. > > It looks as if some doc is out of date somewhere. > > Give me a pointer to it and I shall update it. > > Thanks, > > Jules > > > "Haller, Joe" wrote: > >> I have downloaded and installed JBoss-2.4.3_Jetty-3.1.3-1 >> I am operating under JDK 1.3.1_01. >> >> I have followed the instructions in the README and it appears >> to start. >> >> However: >> >> Hitting URLs http://localhost:8080, http://localhost:8080/demo, >> http://localhost:8080/jboss, etc. give the following error: >> >> HTTP ERROR: 404 Not Found >> Could not find resource for / >> RequestURI=/ >> >> Hitting URL http://localhost:8082 appears to give some >> administrative page. >> >> I get a similar error when accessing some of online documentation >> on the JBoss web site: http://www.jboss.org/documentation/HTML/ch02.html. >> >> Can anyone help here? >> >> Regards, >> J. Haller >> >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty
Who is suggesting you hit these urls ? As bundled, Jetty comes with no apps deployed - so hitting these urls WILL tell you that nothing is found. You won't find anything there until you PUT something there. It looks as if some doc is out of date somewhere. Give me a pointer to it and I shall update it. Thanks, Jules "Haller, Joe" wrote: > I have downloaded and installed JBoss-2.4.3_Jetty-3.1.3-1 > I am operating under JDK 1.3.1_01. > > I have followed the instructions in the README and it appears > to start. > > However: > > Hitting URLs http://localhost:8080, http://localhost:8080/demo, > http://localhost:8080/jboss, etc. give the following error: > > HTTP ERROR: 404 Not Found > Could not find resource for / > RequestURI=/ > > Hitting URL http://localhost:8082 appears to give some > administrative page. > > I get a similar error when accessing some of online documentation > on the JBoss web site: http://www.jboss.org/documentation/HTML/ch02.html. > > Can anyone help here? > > Regards, > J. Haller > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
