[JBoss-dev] Re: default web server
Scott M Stark wrote: Simply because Tomcat is the defacto standard and the default choice for most of our users and I'm not happy with the level of integration we currently offer. For those of you who are using Jetty and are happy with that choice, I just want to assure you that regardless of what decisions the JBoss Group make, that Jetty in JBoss will continue to be supported by a strong open source community sponsored by Mort Bay and commercial support will be available for it from the core developers network. So we are continuing to develop and support the jetty sar for JBoss and hopefully it will continue to live in the JBoss project (although we may want to review the duplicate source tree issue). The intent will be to keep the web container services totally pluggable so that you can simple drop in the web sar of *your* choice. regards -- /** * Greg Wilkins * Partner * Core Developers Network **/ There's a difference between knowing the path and walking the path - morpheus --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Attn: Sacha - AbstractSessionManager changes in org.mortbay...
Sacha Labourey wrote: Consequently, in any case, what is the process to get RW access to Jetty? Ask - and almost always you shall receive. If you want I'll give you access and you can check these changes in, but if they are just stats changes then I'm happy to do it my self as it will probably guilt me into improving some stats elsewhere. Actually, I'll give you write access even if you want me to do the merge as I hope it will calm the waters after the recent commercial differences. Basic rules for committing to Jetty are: + Try to keep the jetty-discuss list informed of what you are doing ahead of time + Don't break the build. + Don't get upset if your changes get modified - all contributions are worthwhile - even if they get replaced with something else as they have at least inspired, provoked or guides the something else. + Most of the code is copyright Mort Bay, but you don't want to assign your copyright to MB - then you don't have to. Note that there is another merge needed back from JBoss, as Christoph has made some recent changes with the handling of the web.xml parsing. I have not moved these back to JEtty yet as I am still concerned a bit about not binding core jetty classes to XML (as some deployments do not use it). Christoph modified his patches after I mentioned this, but I have not had time to review them again. I actually think I need to clean up that whole area and hope to have a new version that includes Christophs requirements in the next week or two. cheers --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Mort Bay Consulting joins Core Developers Network
=== Open Letter: Mort Bay Consulting joins Core Developers Network === As most of you know, Mort Bay Consulting, has been involved with the JBoss Project for well over 2 years as the developers of Jetty, the open source HTTP/servlet container, and its integrators with JBoss. We have also been involved with JBoss Group, the commercial entity, as providers of Jetty and JBoss professional services. Our experiences during this time have regrettably led us to conclude that our commercial and personal apsirations would be better served outside of the JBoss Group. Therefore, we have decided to join the Core Developers Network (http://www.coredevelopers.net), an open source services organization whose business ethos aligns more closely with our own. The Core Developers Network has been formed as a partnership of peers with the guiding principles of openness, fairness and inclusivity. Its charter is to provide a commercial infrastructure to enable open source contributors to deliver their professional expertise to the marketplace, independent of their contributions to open source projects. Mort Bay will be using Core Developers Network as our preferred channel for training, documentation and support services. We want to emphasise that after joining Core Developers, we will continue to provide the same responsive, high-quality technical support to the JBoss project as we have always done. As ever, we wish it every success and will do all that we can to strengthen and enhance that success. We will, however, be drawing a clear distinction between our support for JBoss the project and for JBoss Group, the commercial entity. Sincerely, Mort Bay Consulting Ltd -- 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: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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
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 --- This sf.net email is sponsored
Re: [JBoss-dev] Re: [jetty-discuss] isValid() not a good fit for certs
Phil, It has been suggested that Jetties approach of testing each certificate in turn until one passes is incorrect. As the array of certificates indicates the chain of trust and they all need to be checked to verify authentication. As we are already passing an object as a credential to the realm, I suggest that we pass the entire array of certificates to the realm for it to check: java.security.cert.X509Certificate[] certs = (java.security.cert.X509Certificate[]) request.getAttribute(javax.servlet.request.X509Certificate); if (certs==null || certs.length==0 || certs[0]==null) return null; Principal principal = certs[0].getSubjectDN(); if (principal==null) principal=certs[0].getIssuerDN(); UserPrincipal user = realm.authenticate(principal==null?clientcert:principal.getName(), certs,request); return user; Would that be an appropriate thing to do? Note that I agree with Scott that we do not need a mutable Principal returned. cheers -- 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: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] Re: [jetty-discuss] isValid() not a good fit for certs
The jetty ClientCertAuthenticator has the following code
java.security.cert.X509Certificate[] certs =
(java.security.cert.X509Certificate[])
request.getAttribute(javax.servlet.request.X509Certificate);
if (certs==null || certs.length==0 || certs[0]==null)
return null;
for (int i=0;icerts.length;i++)
{
Principal principal = certs[i].getSubjectDN();
UserPrincipal user = realm.authenticate(principal.getName(),
certs[i],
request);
if (user!=null)
return user;
}
Thus the DN for the certificate is used as the principal name and
each certificate is tried until one succeeds.
Note there is no requirement on the abstract jetty realm to return a user
with the same principal as passed to realm.authenticate, so the name
can be changed by the realm.
The subject DN is optional, so I think I had better protect this
code from a null pointer. In future I will pass a principal of clientcert
if no subjectDN is available (unless you have a better suggestion).
cheers
Dawes, Phil wrote:
Hi all,
The AuthenticationManager.isValid(principal,credential) isn't a good fit for
certificates AFAICS, because you don't know the principal name before you've
authenticated the credential.
I am extending the jetty and tomcat bindings to support certificate
authentication to a JAAS loginmodule, and am having to create a dummy
principal to hack round this.
This works, but getting the principal name out of the httprequest object
returns a dummy name (I'm using cert serial and issuer).
I was wondering:
1) Is there a better way of doing this?
(e.g. should I be using JAAS directly rather than the jboss security
interfaces)
2) Is the AuthenticationManager interface going to change in the near future
to accomodate certs etc..?
Cheers,
Phil
--
If you have received this e-mail in error or wish to read our e-mail
disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender.
--
Yahoo! Groups Sponsor -~--
Plan to Sell a Home?
http://us.click.yahoo.com/J2SnNA/y.lEAA/MVfIAA/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/
--
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: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] Re: [jetty-discuss] isValid() not a good fit for certs
Dawes, Phil wrote: Unfortunately, unlike Jetty, JbossSX does require that the principal be the same for each subsequent call into the security layer after the initial auth, since JaasSecurityManager caches the subject information based on principal. This means AFAIK I can't switch the principal to a different one after the authenticate. thinks Although I suppose Jetty could use a Principal which allowed the name to be changed retrospectively without changing the hashcode - would this work?. /thinks Note that on each request that needs to be authenticated, Jetty will follow the same code. It will call realm.authenticate passing the subjectDN as the principal name. So the name does not really change within the principal. It is just that Jetty does not care if the principal passed back from that call has the same name as was passed. It is the returned principal that is used to setup the user and principal methods on the request. It is up to the realm implementation if it passed back the same principal or a new one each time. Having said that - I see no problem with your suggestion from the Jetty side of things - but I'll defer to Jules to comment on the Jetty/JBoss realm implementation. I'll put the changes into ClientCertAuthenticator anyway as I think they are generally a good idea: Principal principal = certs[i].getSubjectDN(); if (principal==null) principal=certs[i].getIssuerDN(); UserPrincipal user = realm.authenticate(principal==null?clientcert:principal.getName(), certs[i],request); While we are thinking about authentication, somebody needs to get some spare cycles to implement runAs for servlets. Jan was just about to start on that, but then got sucked into the Duetche Bank void for the next n months Scott had made some suggestions for that - but I never got time to digest them. cheers I ought to elaborate - the real problem for me is not thinking of a name for a dummy principal to use. The real problem is that after authentication, the application writers will want to get more information about the user other than just the principal name. In order to do this we have a service which returns information about the user when passed the authenticated principal. This means that the principal name needs to be something sensible (currently UserID in our weblogic setup). Weblogic has an api (like jetty's) which allows the principal to be created after the authentication, thus allowing the realm to dictate what the authenticated principal name is. How does this sound as a solution: - jetty ClientCertAuthenticator uses subjectDN, or failing that, CertSerialIssuer as the username (not important really) - The Jetty JbossUserRealm creates a principal which can have its name changed without changing the object hashcode. - Realm calls isValid(principal, cert) - Home baked JAAS LoginModule authenticates certificate, and populates active subject on commit. - Realm then sets the principal name to be that of the first principal in the active subject. This means that the author of the JAAS login module can dictate what name of the principal after the authentication has taken place, and the Jetty JbossUserRealm is still pretty generic. Does this sound reasonable? -- 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: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] [ jboss-Bugs-604085 ] Jetty is not deploying packedwars
___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars
Dustin, thanks for your offer of help... My windows is still patching booting patching booting and looks to be hours or days away from being usable! So can you turn on verbose debugging in Jetty (simplest via the JMX interface). You want to set debug = true verbosity = 99 loglabels = true I think you also need to turn on JBoss debugging, as the jetty debug messages are just passed to the JBoss mechanism. then deploy a simple web app that is failing. Collect the logs and send them to me with the webapp. thanks Barlow, Dustin wrote: I'm more then happy to help in whatever way I can. I sent Jules the server logs from JBoss, but I suspect those weren't helpful being that from JBoss's perspective, there didn't appear to be any deployment errors generated. Let me know what else I can do to help you get what information you need to fix the problem. Dustin Barlow -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 5:43 AM To: Jules Gosnell Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars Jules Gosnell wrote: This is most likely the same as the spaces within paths issue. Because the war is packed, it is unpacked to a temporary dir, which has spaces in it. Greg is looking at it. No I'm not! I've had a total windows failure and after spending hours rebuilding that damn thing - applying service pack 3 rendered the thing unbootable again. I've had one user send me some detailed trace on it, and I'm currently suspecting something about classloading can't handle %20 in file URLs. But without a system I can't test. Jan has tried to reproduce the problem on her, but spaces in filenames are working without problem on straight jetty. So I need verbose debug traces from users with failures -- PLEASE. I'm trying to put a windows dev system back together today... cheers Jules [EMAIL PROTECTED] wrote: Bugs item #604085, was opened at 2002-09-03 10:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=604085group_id =22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty is not deploying packed wars Initial Comment: I am seeing a problem with Jetty not deploying wars from the deploy directory in the current 3.0 and 3.2 branches. If you take the default/deploy/jmx-console.war and repack this: deploy 414ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415jar -tf jmx-console.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/jmx/ WEB-INF/classes/org/jboss/jmx/adaptor/ WEB-INF/classes/org/jboss/jmx/adaptor/control/ WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.class WEB-INF/classes/org/jboss/jmx/adaptor/html/ WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptorServ let.class WEB-INF/classes/org/jboss/jmx/adaptor/model/ WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData.cl ass WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData.cl ass WEB-INF/classes/roles.properties WEB-INF/classes/users.properties WEB-INF/web.xml displayMBeans.jsp displayOpResult.jsp images/ images/head_blue.gif index.jsp inspectMBean.jsp style_master.css Startup the default config and although Jetty says the war was deployed: 13:18:20,769 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/deploy/jmx-console. war 13:18:21,340 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=0,context=/jmx-console 13:18:21,390 INFO [jbossweb] Checking Resource aliases 13:18:21,490 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-consol e.war/61.jmx-console.war!/ to C:\DOCUME~1 \starksm\LOCALS~1\Temp\Jetty_0_0_0_0_80 80__jmx-console\webapp 13:18:22,312 INFO [jbossweb] Started WebApplicationContext[/jmx-console,jar:fil e:/C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/tmp/depl oy/server/default/deploy/jmx-console.war/61.jmx- console.war!/] 13:18:22,392 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-console.war/61.jmx-console.war to /jmx-console 13:18:22,392 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss-3.2.0RC1/server/default/deploy/jmx- console.war 13:18:22,402 INFO [URLDeploymentScanner] Started It is in fact not accessible
[JBoss-dev] Re: [JBoss-user] bundled tc4/jetty not remembering previous authenticationin single session
Jim, This has been discussed on JSR154, trying to get this behaviour better described in the the 2.4 servlet spec. Unfortunately we did not resolve anything other than agreeing that the behaviour for resources without authentication constraints is undefined. My angle on this is that: a) Caching authentication is bad. You can't assume that authentication from a previous request is still valid, as realms may be managed dynamically, credit may expire etc. etc. b) Checking authentication may be expensive as it may be remote and involved complicated algorithms - even challenge response. c) A secured page may include many resources, such as images that do not need to be secured. So Jetty takes the approach that we only check authentication for the resources that have an authentication constraint. And thus the authenticated username is only available for authenticated resources. Jetty could be more flexible/configurable on this - but to my mind security is not something to get wrong. Thus I think we will stick with this approach until the spec suggests a better way forward. But there is nothing stopping you taking the username from an authenticated request and putting it in the session yourself for use by unauthenticated requests. regards jfc wrote: Hi Greg, Any thoughts on that problem I emailed you about? This was the demo-auth-prob.war attachment I emailed on Monday this week. I cc'ed Jules as requested. Below is the jetty forum message. I have subsequently received some input from Scott Stark and Craig McClanahan and have the links below (after the message). I am happy that this is not a bug but I am still interested in how jetty implements the relevent portion of the spec. i.e. if jetty provides some way to manually store/cache the auth info for subsequent authenticated requests and whther you have any suggestions for implementing a solution on the jetty+jboss bundle - I would be upgrading to jboss3 as you pointed out the fact that jetty's security is better integrated into the latest version of jboss. *From:* jakespigl3 [EMAIL PROTECTED] http://groups.yahoo.com/group/jetty-support/post?protectID=045044219153050213015171031024021239000150066136226225152006048067 *Date:* Sat Aug 24, 2002 7:09 pm *Subject:* web container not remembering previous authentication in single session Hi, JBoss3.0.0+Jetty??? (don't see any reference to Jetty version in latest bundle) I have created a war file to demonstrate a problem(relating to authentication - FORM-BASED or BASIC on jboss+jetty bundle) with which I have spent a lot of time trying to resolve. The problem is this: 1. unauthenticated user's request is to a secured resource; 2. login form / basic form is presented to user; 3. user logs in successfully i.e. successfully authenticated (req.getRemoteUser(userid) reflects this); 4. same user then requests a non-secured resource and is not recognized as being authenticated(request.getRemoteUser(userid) returns null). 5. same user requests the previous (point 3) resource and is taken directly to the secured resource (i.e. container recognizes or 'remembers' the request as having been authenticated.) I am interested only in persisting this authentication info on the web engine at this point - I'll get to the ejb container later. I have to go back to jboss2.4.3+tc4.0 to get the web container to remember a previous authentication (within the same session of course) - however, anything above those two combinations and it just doesn't remember. I have tried more than one login module implementation without it affecting the result (DatabaseServerLoginModule). Also, I have tried deploying the war into a standalone tomcat container(4.0.4) and the container does remember the previous authentication. I have attached the 'demo-auth-prob.war' file. just drop it into the jboss 3.0.0 deploy directory to deploy it. (If neccessary I can supply the source). Feel free to try the form-based variation by modifying the archived web.xml (currently commented out). The war is currently configured to utilize the UserRolesLoginModule which I believe will be invoked should the jboss-web.xml security realm not be found in your jboss's login-config.xml. Cheers Jim (how do I attach the file??) The forum links: jboss-user: http://www.geocrawler.com/mail/thread.php3?subject=%5BJBoss-user%5D+bundled+tc4%2Fjetty+not+remembering+previous+authentication+in+single+sessionlist=10767 tomcat-user: http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/msg64159.html Thanks jim -- 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: OSDN - Tired of that same old cell phone? Get a new here for FREE! https
Re: [jetty-discuss] Re: [JBoss-dev] [ jboss-Bugs-594563 ] Includeof JSP jumps to top of page
Jetty makes an effort to avoid flushing the buffer - as this is not
very network efficient.
For example, if the includer has called getWriter and the includee also calls
getWriter, then their is no need to flush before the include.
cheers
Alex Sumner wrote:
Seems to be a Jasper thing, exactly the same happens with Tomcat 4.0.4. If
you programatically dispatch a request from within a JSP, either with
something like this:
%RequestDispatcher rd = application.getRequestDispatcher(/Included.jsp);
rd.include(request, response);%
or with the equivalent code in a custom tag, then the output stream isn't
flushed first, so the included stuff ends up before the stuff that preceeded
it.
- Original Message -
From: Alex Sumner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 13, 2002 5:26 PM
Subject: Re: [JBoss-dev] [ jboss-Bugs-594563 ] Include of JSP jumps to top
of page
I've seen something very similar with Jetty 3.1.7. Calling
RequestDispatcher.include() should flush the output stream, but it appears
not to. If you add an explicit
response.getWriter().flush();
(or response.getOutputStream().flush() I guess, though I haven't tried it)
just before the include(), then it works as expected.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 13, 2002 1:18 PM
Subject: [JBoss-dev] [ jboss-Bugs-594563 ] Include of JSP jumps to top of
page
Bugs item #594563, was opened at 2002-08-13 12:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594563group_id
=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Miner (jeff_miner)
Assigned to: Scott M Stark (starksm)
Summary: Include of JSP jumps to top of page
Initial Comment:
OS: Win98
JDK: 1.4
I have some code that manually does a JSP include
by getting a RequestDispatcher. The code worked
under Weblogic 5.1 and 6. In Jboss/Catalina,
although there are no errors thrown, the output from
the included JSP gets put at the top of the containing
page rather than in the middle where it was called.
This is puzzling because it ought to be exactly the
same as a jsp:include ... tag (and I assume those
work!)
**Containing Page***
tabletrtd
%= myObject.getOutput(request, response) %
/td/tr/table...
*** Object
public String getOutput(HttpServletRequest request,
HttpServletResponse response) {
RequestDispatcher dispatch =
context.getRequestDispatcher(someJSP.jsp);
try {
dispatch.include(request, response);
} catch(Exception e){}
return ;
*
The output from someJSP.jsp should go inside the
table, but instead it goes at the top of the containing
page.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594563group_id
=22866
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Yahoo! Groups Sponsor -~--
4 DVDs Free +sp Join Now
http://us.click.yahoo.com/pt6YBB/NXiEAA/ySSFAA/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/
--
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 sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] Possible Jetty race condition?Or threading mystery? Help!!
Already in CVS.
cheers
PS. don't blow away Marc's jasper hack in JBoss
Jules Gosnell wrote:
Guys,
I reproduced the problem on JBoss-3.0.1 easily, added Greg's fixes to
the Jetty component and could not then reproduce the Exception.
Greg, If you stick this into Mort Bay Jetty cvs (or shall I?), I will do
a merge into the necessary JBoss branches.
Jules
Greg Wilkins wrote:
David,
thanks for the detailed analysis of this.I had seen this once
before but
had never been able to reproduce it.
I think I know what is going on It is not strickly a race rather
the thread is being returned to the pool with interrupted status true -
this is effecting it being used for other purposes.
I think the fix is two fold - although I can't test this as I still
cant reproduce it.
Firstly I need to stop interrupting myself. Close does an interupt
to so that the HttpServer.stop method does not hang for those JVMs where
closing a socket is not enough to wakeup a blocked thread. So I think
close
should be:
if (_handlingThread!=null Thread.currentThread!=_handlingThread)
_handlingThread.interrupt();
Secondly, threads returned to the ThreadPool need to have their
interrupted
status cleared by calling Thread.interrupted.For now I have done this
in the ThreadPool.JobRunner.run method:
while(_running)
{
// clear interrupts
Thread.interrupted();
Can you make these changes and see if that fixes the problem?
thanks
David Jencks wrote:
I've been investigating the Interrupted while requesting permit
exception
that now occurs in recent jboss 3 versions under heavy load and
wonder if
it is due to a race condition in the jetty thread pool. In any case it
seems clear that the Interrupt() is called from Jetty's
HttpConnection.close() method.
Here's some annotated trace info (some from modifying Thread to tell us
what is going on). This is all about thread 4ac866. It appears to
being
used by 2 HttpConnections more or less simultaneously (??)
--we start by HttpConnection recording it's thread.
2002-08-12 10:17:08,829 INFO [org.mortbay.http.HttpConnection] setting
_handlingThread to
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
in HttpConnection: org.mortbay.http.HttpConnection@462080
--later, it is done with this thread so it interrupts it. Note we are
using HttpConnection 462080
2002-08-12 10:17:08,833 INFO [org.mortbay.http.HttpConnection]
interrupting handling thread:
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
from thread
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
in HttpConnection: org.mortbay.http.HttpConnection@462080
--Here's Thread telling us all about the interrupt call
2002-08-12 10:17:08,834 ERROR [STDERR] Interrupt
called--
on thread
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
from thread
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
2002-08-12 10:17:08,835 ERROR [STDERR] java.lang.Exception: Stack trace
from interrupt
2002-08-12 10:17:08,836 ERROR [STDERR] at
java.lang.Thread.interrupt(Thread.java:665)
2002-08-12 10:17:08,836 ERROR [STDERR] at
org.mortbay.http.HttpConnection.close(HttpConnection.java:248)
2002-08-12 10:17:08,837 ERROR [STDERR] at
org.mortbay.http.HttpConnection.destroy(HttpConnection.java:1102)
2002-08-12 10:17:08,837 ERROR [STDERR] at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:1066)
2002-08-12 10:17:08,838 ERROR [STDERR] at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:808)
2002-08-12 10:17:08,838 ERROR [STDERR] at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:186)
2002-08-12 10:17:08,838 ERROR [STDERR] at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:322)
2002-08-12 10:17:08,839 ERROR [STDERR] at
org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:713)
2002-08-12 10:17:08,840 ERROR [STDERR] at
java.lang.Thread.run(Thread.java:479)
--The interrupt completed successfully, we are still in HttpConnection
462080
2002-08-12 10:17:08,841 INFO [org.mortbay.http.HttpConnection] finished
interrupting handling thread:
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner
Re: [jetty-discuss] Re: [JBoss-dev] Possible Jetty race condition?Or threading mystery? Help!!
I meant the hack I did for Marc. I have raised a bug against the jasper people for it - but I have seen no action from them yet.In fact they have 290+ open bugs against tomcat/jasper and not much action on any of them! The hack is in the jboss jetty tree, but not in the main jetty tree. Don't know why really - just hedging bets I guess. cheers marc fleury wrote: Greg, Already in CVS. cheers PS. don't blow away Marc's jasper hack in JBoss You wrote it :) Hey the other day I was at this Sabre division and one of the things they were asking about is precompiled JSP, I didn't know you had commited the fix for live deployment, it is really useful. Is there any way jasper integrates this. marcf Yahoo! Groups Sponsor -~-- 4 DVDs Free +sp Join Now http://us.click.yahoo.com/pt6YBB/NXiEAA/RN.GAA/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/ -- 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 sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Possible Jetty race condition? Or threading mystery?Help!!
--- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ 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 --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Rice study
) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:510) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:789) at org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection(LocalDataSource.java:102) -dain --- 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 -- Greg Wilkins[EMAIL PROTECTED]http://www.mortbay.com Mort Bay Consulting Pty. Ltd. AU.+61(0)29977 2395 Mort Bay Consulting Limited. England UK. +44(0)7092063462 --- 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] Re: JDK 1.4 support?
Jason Dillon wrote: There is already 1.4 support in both 3.0 and HEAD. The jboss/connector module has some conditionals which build some javax stubs for 1.3 but not for 1.4. OK, I'll have a look. IMO it would be better to integrate Jetty as binary, so that we don't have to keep the build systems in syncs in addition to the sources. This will make it much easier to update when Jetty updates too. This never works nicely as both JBoss and Jetty have frequent releases. So you end up tracking JBoss X + Jetty Y + WebAppService Z, so you have three version numbers to track. Plus there are branding and support issues - JBG wants to have the whole J2EE source etc. Finally I'll soon be doing a license change so that Jetty under JBoss is LGPL as opposed to the artistic license that it is currently under. cheers --jason -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 12:40 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: JDK 1.4 support? Jason, I want to wrap up the Jetty load balancer as a JBoss service. However the load balancer is written using the nio libraries from jdk1.4 (because why load balance if your bottle neck is a user space java.io threads on your load balancer). Can we get optional jdk1.4 support into the build environment? What I'm doing in jetty is to have a separate src1.4 tree that only gets compiled if ant can see a jdk.14 compiler. It get's compiled into classes1.4 and then an extra org.mortbay.jetty-jdk1.4.jar is built with the both the normal classes and extra (and replacement) classes from classes1.4 cheers -- Greg Wilkins[EMAIL PROTECTED]http://www.mortbay.com Mort Bay Consulting Pty. Ltd. AU.+61(0)29977 2395 Mort Bay Consulting Limited. England UK. +44(0)7092063462 -- Greg Wilkins[EMAIL PROTECTED]http://www.mortbay.com Mort Bay Consulting Pty. Ltd. AU.+61(0)29977 2395 Mort Bay Consulting Limited. England UK. +44(0)7092063462 --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JDK 1.4 support?
Jason, I want to wrap up the Jetty load balancer as a JBoss service. However the load balancer is written using the nio libraries from jdk1.4 (because why load balance if your bottle neck is a user space java.io threads on your load balancer). Can we get optional jdk1.4 support into the build environment? What I'm doing in jetty is to have a separate src1.4 tree that only gets compiled if ant can see a jdk.14 compiler. It get's compiled into classes1.4 and then an extra org.mortbay.jetty-jdk1.4.jar is built with the both the normal classes and extra (and replacement) classes from classes1.4 cheers -- Greg Wilkins[EMAIL PROTECTED]http://www.mortbay.com Mort Bay Consulting Pty. Ltd. AU.+61(0)29977 2395 Mort Bay Consulting Limited. England UK. +44(0)7092063462 --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JSR-77 and Jetty
As Jetty already wraps it's major components as MBeans (Listeners and Contexts) then I think it makes sense for the AbstractWebContainer only to define interfaces for the components that need to be managed. Then the specific web container can instantiate those component MBeans with the JSR-77 attributes plus any container specific attributes. If the web container only provided data rather than created the management objects, then it would be difficult to include additional attributes and methods. I guess we could have two sets of MBeans, but that is a bit ugly. Scott M Stark wrote: It does not have to be exposed if its not a useful op. These management objects can just be created, registered on deployment of a web module and unregistered when the web module is undeployed. That would be simpler. I'm not sure if the web container will have to actually create the management objects or just provide the info to create these. Since you could define a WebModule that has its stateManageable, statisticsProvider, and eventProvider attributes false, a minimal managed view could be provided using simple data objects from the web server. That should be a supported option as it is a low barrier of entry for the web server integrater. The more complex the management object implementation in terms of those attributes the more it seems the web server itself will have to create the management object. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Andreas Schaefer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 20, 2002 5:43 PM Subject: Re: [JBoss-dev] JSR-77 and Jetty Hi Scott At a minimum at the AbstractWebContainer level we define the hooks to obtain the required Servlet[] management objects needed to make up the WebModule management object. There may not be much to this other than a simple template method that defines the requirements for obtaining management information/callbacks to impliment the JSR-77 objects. These are not attributes or operations of the web container right? They are just mbeans bound into the JSR-77 management namespace. Maybe there is a WebModule[] getWebModules() operation here? Just to see that I understand you correctly. You want to expose a list of JSR-77 MBeans by the AbstractWebContainer with getWebModule(). And the JSR-77 MBeans are provided by the Web server. Correct ? Andy --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ 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 --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JSR-77 and Jetty
Contexts, filters and servlets can all be individually stopped and started in Jetty, with the following results: A stopped context will not be given any new requests. All components (servlets/filters) of a context will be stopped when stop is called on the context However, there may be an issue with the getContext().getRequestDispatcher() path still being able to inject requests to a stopped context. These should not be handled, but I'll look at dealing with them better. If a request does make it to a stopped servlet, then an Unavailable exception will be thrown. Need to consider if this is correct, maybe their mapping should just dissappear. However, they could still be access by RequestDispatcher that were created before the stop, so the Unavailable exception is correct then. A stop/start of a servlet does the servlet lifecycle destroy/initialize thang. Looking at it, I think I need to tidy up handling of stopped filters. Does JSR77 say anything about managing Filters? They should look pretty much the same as servlets. Note there are no methods to get all the servlets, but it is trivial to add and I will do so shortly. The question is what API should it return for each servlet? Not the servlet itself as calls to the lifecycle methods will go straight to client code and the container will not be able to manage them properly. Jules Gosnell wrote: Andreas Schaefer wrote: Hi Jules 1. Are you sure that JSR77 talks at the granularity of Servlets - or is it WebApplications - or both. A Servlet is not the unit of deployment, the WebApplication is. A WebApplication may contain 0-n Servlets. JSR-77 have an application (EAR) with one or more modules (WAR,JAR,RAR) and each containing eithe EJBs, Servlets or ResourceAdaptors. So, yes, JSR-77 needs both the web application and the servlets its contains. OK - can do. 2. Jetty has a concept of deploy, start, stop and undeploy. Currently webapps are started as soon as they are deployed - so when you say start/stop, do you mean deploy/undeploy or start/stop ? JSR-77 is not clear in this point but the lack of the creation of services I think it means to start/stop but not deploy/undeploy. BTW what does start/stop mean (make it available/unavailable to serve) ? What happens with the servlets at this time. Can you start/stop servlets ? start/stop means (Greg can give you the exact definition for Jetty) something like make-available-to-client. If the webapp is stopped, it is still deployed but the client cannot see it - although it can be restarted very quickly... 3. I am keen for Jetty to support a restart() and a redeploy() - atomic functions which put incoming requests on hold while they do their job - thus ensuring 24*7 service, with no lost requests, even if you upgrade your website at a peak time... I believe JSR77 also has optional? provision for (at least one of) these. I think that it is important that we support it from the start even if it is simply implemented in terms of the others... Ahhmm, where did you see that in JSR-77 ? Aha ! - I think I am getting 77 and 88 confused again ! Jules Thanx - Andy --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ 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 --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: JSR-77 and Jetty
Answering email in reverse order Yes this is possible. Give me a day or two as I have not read JSR-77. Once I'm upto speed, then I'll be able to comment better. It may be as Jules suggested that Jetty should provide a lot more JSR-77 support itself, which then should be adapted as Scott suggests to the interfaces specified by the Abstract Web container. cheers Andreas Schaefer wrote: Hi Greg To make JSR-77 implementation (a J2EE management API) complete I need to support the web-service and I wills start with Jetty (it seems to be tough enough). To start with I need a place where I can create a WebModule (represents a WAR file) and each Servlet (for now the once defined in web.xml). For me its seems that the deployment of the servlets are deep inside Jetty and I am not quite sure how we want to integrate JSR-77 into Jetty. Beause JSR-77 does not provide Java classes to implement I would suggest that the necessary information are provide by Jetty MBeans so that JSR-77 can pick it up and perform the appropriate steps. Therefore I need: - List of Servlets deployed - A way to start/stop servlets if possible (I would think this means load/unload a Servlet) - Any attributes you maybe want to expose to manage servlets (no attributes specified in the JSR-77 spec.) Is this possible ? Thanx Andy Schaefer Code or be coded Check out: www.madplanet.com -- 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 --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMX Meta data
Juha, I'd like to extend the JMX metadata generation to search for proper descriptions for MBeans, attributes, methods and parameters from resource files. If you startup a JBoss that uses Jetty, you will see via the JMX agent that all the jetty MBeans have descriptive text associated with them. This text is obtained from mbean_en.properties files which are searched for on the package/inheritance hierarchy of the MBean. I think it adds significantly to the usability of the JMX interface. It should be a pretty simple addition to the StandardMetaData class. As you appear to be the main author of the JMX stuff, I thought I'd clear it with you before adding this capability. Of course, even with this capability, we would still need other developers to actually write the mbean.properties files - but at least there would be a standard mechanism to document the MBeans. regards -- 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 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [jetty-discuss] More problems with Jetty, Filters and Sitemesh
) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) at java.lang.Thread.run(Thread.java:479) /snip This is an exception from HEAD, though I get the same behavior from Branch_3_0 as well. What is going on here? --jason Yahoo! Groups Sponsor -~-- Tied to your PC? Cut Loose and Stay connected with Yahoo! Mobile http://us.click.yahoo.com/QBCcSD/o1CEAA/sXBHAA/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/ -- 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 ___ 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: [jetty-discuss] Re: [JBoss-dev] Jetty NPE on undeployment ofjbosstest-web
] 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 Yahoo! Groups Sponsor -~-- Take the Yahoo! Groups survey for a chance to win $1,000. Your opinion is very important to us! http://us.click.yahoo.com/NOFBfD/uAJEAA/Ey.GAA/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/ -- 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 ___ 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: [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
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
(HttpServer.java:744) at org.jboss.jetty.Jetty.service(Jetty.java:530) at org.mortbay.http.HttpConnection.service(HttpConnection.java:743) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) at java.lang.Thread.run(Thread.java:484) -Mensaje original- De: jules [mailto:jules]En nombre de Jules Gosnell Enviado el: jueves, 21 de marzo de 2002 0:47 Para: [EMAIL PROTECTED] Asunto: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty] I guess that this is probably me, but just in case - does it ring any bells ? Jules 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/ 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/ Yahoo! Groups Sponsor -~-- Tiny Wireless Camera under $80! Order Now! FREE VCR Commander! Click Here - Only 1 Day Left! http://us.click.yahoo.com/nuyOHD/7.PDAA/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/ -- 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] Re: HTTP loadbalancing
So has anybody actually tried the load balancer? Or is it not such a needed feature after all :-) 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] Re: [jetty-support] More on Deployments: Applet jars
Applet jars should be treated as content, just as you say like a gif or html file. There is no standard mechanism to get an applet jar out of a WEB-INF/classes or WEB-INF/lib directory. cheers Ignacio Coloma wrote: Hi, has someone realized that applet jars are included in wars and should be put 'as is' on the web resources dir? (I mean, treated the same as any gif image or html file) I'm asking because I use one of these and my app used to work nice until two days or so. Then I realized that since some time ago my applet jar is not accesible for the browser but instead being copied to the temp dir of JBoss. Yahoo! Groups Sponsor -~-- Tiny Wireless Camera under $80! Order Now! FREE VCR Commander! Click Here - Only 1 Day Left! http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/CefplB/TM -~- 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] 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] RE: [JBoss-user] JBOSS 3.x FINAL
things |correct. If you |want to know how flexible, buy the docs. It's only $10.00. | |Bill | |___ |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 -- 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] CVS update: contrib/jetty/src/main/org/mortbay/http HttpContext.java
User: gregwilkins
Date: 02/03/11 17:50:52
Modified:jetty/src/main/org/mortbay/http HttpContext.java
Log:
Fixed rather embarrasing security problem with security constraints.
A constraint at /my/secret/stuff/* could be bypassed with //my//secret//stuff
The Jetty recommendation has always been to restrict / and then relax constraints
for things like /my/public/stuff/*. Webapps that took this safer approach were
not effected.
Revision ChangesPath
1.7 +4 -2 contrib/jetty/src/main/org/mortbay/http/HttpContext.java
Index: HttpContext.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/mortbay/http/HttpContext.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- HttpContext.java 11 Mar 2002 05:28:59 - 1.6
+++ HttpContext.java 12 Mar 2002 01:50:51 - 1.7
@@ -1,6 +1,6 @@
//
// Copyright (c) 2000 Mort Bay Consulting (Australia) Pty. Ltd.
-// $Id: HttpContext.java,v 1.6 2002/03/11 05:28:59 janb Exp $
+// $Id: HttpContext.java,v 1.7 2002/03/12 01:50:51 gregwilkins Exp $
//
package org.mortbay.http;
@@ -30,6 +30,7 @@
import org.mortbay.util.MultiException;
import org.mortbay.util.Resource;
import org.mortbay.util.StringUtil;
+import org.mortbay.util.URI;
/* */
/** Context for a collection of HttpHandlers.
@@ -54,7 +55,7 @@
* @see HttpServer
* @see HttpHandler
* @see org.mortbay.jetty.servlet.ServletHttpContext
- * @version $Id: HttpContext.java,v 1.6 2002/03/11 05:28:59 janb Exp $
+ * @version $Id: HttpContext.java,v 1.7 2002/03/12 01:50:51 gregwilkins Exp $
* @author Greg Wilkins (gregw)
*/
public class HttpContext implements LifeCycle
@@ -1327,6 +1328,7 @@
HttpResponse response)
throws HttpException, IOException
{
+ pathInContext=URI.canonicalPath(pathInContext);
// Save the thread context loader
Thread thread = Thread.currentThread();
ClassLoader lastContextLoader=thread.getContextClassLoader();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Jasper problems - Eureka !
Jules, I guess this is the ultimate solution - ie a compiler that takes URLs in the classpath. As that has not been forthcoming from jikes, sun or whatever - then your wrapper idea is one way of providing it. But a couple of notes: + No matter what we do about unpacking, we have to remove any code from anywhere that does new File(url.getPath()) or equivalent. This is just not portable and never will be. This code needs to be replaced NOW - before any unpacking solution is put in place. + I don't think we need to look for *.java files as resource. While a cool idea - it is the *.jsp files that are resources and *.java files are generated in temporary directories. + A simple initial solution could do away with the whole cache thing. On every compile the classpath can be unpacked, converted to a file classpath and then discarded after the compile. OK it will run slowly, but it is simple and will be able to test the idea first up. No matter what, your wrapper idea is a fair bit of work. My preferred solutions in priority order are: 1) Ban all use of JSPs :-) 2) Only support precompiled JSPs :-| 3) Provide a unpack everything option in JBoss 4) Get the compiler writers (jikes et al?) to support URLs 5) Get the jakarta folks to write your wrapper 6) Get the JBoss folks to write your wrapper. 7) You can write your wrapper 8) Somebody suggest that the jetty people write the wrapper. cheers Jules Gosnell wrote: I was giving Jasper and all the related unpacking problems some thought in the car on the way home this evening and reckon I have a nice, simple solution to all our woes (and Tomcat's, if they are interested...). Jasper supports pluggable compilers. We simply write a ResourceBasedCompilerAdaptor Compiler. This has 3 main features : 1. it understands URLs on it's classpath. Any non-file: URL is treated as a resource available to Thread.currentThread().getContextClassLoader(), copied into a cache, and replaced on the classpath with a file: URL to the copy. 2. when looking for the .java file that it is being asked to compile, as well as looking in the file system, it will try getting the file as a resource from Thread.currentThread().getContextClassLoader(), copying it into the same cache and substituting the original filename with a new one pointing to the copy. 3. It wrap-n-delegates to the actual required compiler - javac, jikes etc. Which may then painlessly compile away, oblivious to the fact that it is running in a resource based, rather than file-based, environment. Anyone see any problems ? I reckon that with this, we can forget all those painful unpacking problems, whilst still being able to run apps that are already unpacked, with no overhead. At the same time the code maintains compatibility with future versions of Jasper (unless they change the compiler API) whilst having no dependencies on ServletContainer or AppServer. Lastly, a URL-file cache may come in useful for local caching of remote resources, if JBoss or Jetty does not already contain one.. Before you ask, I haven't given any thought to timing out the cache, but it should be possible to check the date on the remote resource shouldn't it (do I need 1.4 to do this?). Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- 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] Re: [jetty-discuss] HTTP loadbalancing
MMM all is not well in the state of java.nio! At least on linux, I'm getting lots of strange behaviour, which I suspect are bugs in the implementation or my understanding of it. Firstly it appears that the loadbalancer only works if debug is turned on. With debug turned off, it runs faster and I start seeing the following problems: + closing of a channel is not seen by the other end (client or server) until it tries to write back. + If such a lingering close happens, then following connections fail. the server reports a new connection, but the finishConnect() method returns false. It would be good if somebody could try this stuff on a win32 platform to see if it is well behaived there?? I have put a bit more failure handling in. The mickey mouse policy now keeps trying servers until they have all failed. Also server failure undoes InetAddress stickyness. cheers Greg Wilkins wrote: I have now added client InetAddress stickyness, which is probably going to be good enough for 90% of cases. But for those that want session stickyness, I have now allow delayed server allocation and pass the queued data into the Policy. This will allow a search for jsessionId up until the queue is full (at which time you had better allocated or you will just block). Only thing lacking is a monitor of the response channel so you can pick up session cookie sets. I'm now going to stop on the balancing policy and concentrate on the network stuff. Still no decent exception handling. There is also a funny in the nio (at least on Linux), where I close the Channel, the socket, the inputstream, the outputstream, etc. and the client still does not see the closed connection until it tries to write another packet! Note good for HTTP/1.0! This only happens sometimes - and never in a test harness!?!?!?!?! 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
Re: [JBoss-dev] Re: [jetty-discuss] Re: Jasper problems - Eureka !
Narrow band reply, as I am not sure about this. I think jasper already gets the jsps as URLs and/or resources. That's why last modified does not work unless it is using jdk1.4 cheers Jules Gosnell wrote: I see your point, Jan. However, even if JBoss supplies us with file: urls, Jasper will still need the WAR unpacked so it can get at the JSPs (Greg, when I said .java in my previous mail I meant .jsp). My solution, will sort this as well, since .jsps will also be picked up by getResource(). I agree with Greg that some other project SHOULD pick up this work. However, since they haven't, it might not be a bad idea for me to pick this up and play with it for a little. I figure that I can put together a very naive version fairly painlessly. Less painfully, in fact, than having to continually explain the problem on various lists/fora and provide a stream of half hearted attempts at a proper Jasper integration. Furthermore, if it works, it gives JBoss/Jetty an extra win - we can run all apps packed. Since it is not really a production problem (as discussed), a really naive caching approach would probably work (I'm sure URL will probably be caching the whole lot underneath me anyway). I'm going to give it a couple of hours this evening and see how far I get and what problems I uncover. Speak to you soon, Jules Jan Bartel wrote: Let's consider bang for buck, or effort for reward: how much effort is it going to be for JBoss to provide a real path for items in an njar format (ie really making their AbstractWebContainer getCompileClasspath() method *really* return a compilable classpath rather than a bunch of URLs) versus implementing Jules' undoubtedly groovy solution? In my effort v reward calculation, I'm factoring in that what we are *in fact* trying to solve here is a development-time problem only: JSPs in production are usually pre-compiled (speed and undesirability of having javac on production machines). So, my calculator says: Fix JBoss getCompileClasspath()v ResourceBasedCompilerAdaptor small effort:sufficient rewardvbig effort:sufficient reward Jan Greg Wilkins wrote: Jules, I guess this is the ultimate solution - ie a compiler that takes URLs in the classpath. As that has not been forthcoming from jikes, sun or whatever - then your wrapper idea is one way of providing it. But a couple of notes: + No matter what we do about unpacking, we have to remove any code from anywhere that does new File(url.getPath()) or equivalent. This is just not portable and never will be. This code needs to be replaced NOW - before any unpacking solution is put in place. + I don't think we need to look for *.java files as resource. While a cool idea - it is the *.jsp files that are resources and *.java files are generated in temporary directories. + A simple initial solution could do away with the whole cache thing. On every compile the classpath can be unpacked, converted to a file classpath and then discarded after the compile. OK it will run slowly, but it is simple and will be able to test the idea first up. No matter what, your wrapper idea is a fair bit of work. My preferred solutions in priority order are: 1) Ban all use of JSPs :-) 2) Only support precompiled JSPs :-| 3) Provide a unpack everything option in JBoss 4) Get the compiler writers (jikes et al?) to support URLs 5) Get the jakarta folks to write your wrapper 6) Get the JBoss folks to write your wrapper. 7) You can write your wrapper 8) Somebody suggest that the jetty people write the wrapper. cheers Jules Gosnell wrote: I was giving Jasper and all the related unpacking problems some thought in the car on the way home this evening and reckon I have a nice, simple solution to all our woes (and Tomcat's, if they are interested...). Jasper supports pluggable compilers. We simply write a ResourceBasedCompilerAdaptor Compiler. This has 3 main features : 1. it understands URLs on it's classpath. Any non-file: URL is treated as a resource available to Thread.currentThread().getContextClassLoader(), copied into a cache, and replaced on the classpath with a file: URL to the copy. 2. when looking for the .java file that it is being asked to compile, as well as looking in the file system, it will try getting the file as a resource from Thread.currentThread().getContextClassLoader(), copying it into the same cache and substituting the original filename with a new one pointing to the copy. 3. It wrap-n-delegates to the actual required compiler - javac, jikes etc. Which may then painlessly compile away, oblivious to the fact that it is running in a resource based, rather than file-based, environment. Anyone see any problems ? I reckon that with this, we can forget all those painful unpacking problems, whilst still being able to run apps that are already unpacked, with no overhead. At the same time the code
Re: [JBoss-dev] Re: [jetty-discuss] HTTP loadbalancing
Bill Burke wrote:
I'll be your buddy
OK Bud!
I've just checked in a skeleton load balancer into
Jetty/src1.4/org/mortbay/loadbalancer
It has all the nio network plumbing for two way connections with
flow control - but not very good exception handling at the moment.
A trivial round robin policy is used:
public class Policy
{
private Server[] _server;
private int next;
public Policy(Server[] server)
{
_server=server;
}
public void allocate(Connection connection)
throws IOException
{
next=(next+1)%_server.length;
connection.allocate(_server[next]);
}
}
Note that this Policy class does not even have the API to do
anything real can't look for jsessionid and fiddly to get the
InetAddress of the client but it is at least a start.
The nio stuff is really rather cool - I think I may take some
timeout from load balancing to write SocketChannelListener for
Jetty, which should be a big winner for scalability!!!
So Bill or other Buddies, please have a look at the code and we
can talk Policies soon!
I use the org.mortbay.tools.Tenlet (telnet backwards) class
as a sample server - so I can type back at a telnet client.
to run with 1 listener on 8123 and two servers you say:
java org.mortbay.loadbalancer.Balancer :8123 - 127.0.0.1: 127.0.0.1:
remember this is a release-early-release-often piece of code... be gentle :-)
cheers
PS. If another buddy wants to get in on the scene - we have to make the
thing JMX manageable!
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] Non blocking listener. was: HTTP loadbalancing
OK, I have added a java.nio listener to Jetty: org.mortbay.http.SocketChannelListener It has had very little testing, but appears to be working OK on my machine. If anybody has a big iron and something that can generate lot's of connections, it would be interesting to see what it does for performance. It should reduce the thread count significantly! This is java 1.4 only, so I can't move it to the JBoss repository until the build.sh knows how to handle optional 1.4 stuff. cheers Dan Christopherson wrote: This is maybe a bit offtopic, and a bit long, but this is one of those serindipitous occasions where a conversation strikes on something somebody else is already working on... Greg Wilkins wrote: + Use java.nio as: * if you care about performance you should be using jdk1.4 anyway * if you want one machine to handle more connections than the sum of all your servers, then java.net.ServerSocket aint going to do the job! * I want to play with nio before I write the NioListener for Jetty! -- 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] Re: [jetty-discuss] HTTP loadbalancing
I have now added client InetAddress stickyness, which is probably going to be good enough for 90% of cases. But for those that want session stickyness, I have now allow delayed server allocation and pass the queued data into the Policy. This will allow a search for jsessionId up until the queue is full (at which time you had better allocated or you will just block). Only thing lacking is a monitor of the response channel so you can pick up session cookie sets. I'm now going to stop on the balancing policy and concentrate on the network stuff. Still no decent exception handling. There is also a funny in the nio (at least on Linux), where I close the Channel, the socket, the inputstream, the outputstream, etc. and the client still does not see the closed connection until it tries to write another packet! Note good for HTTP/1.0! This only happens sometimes - and never in a test harness!?!?!?!?! 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
Re: [JBoss-dev] Re: [jetty-discuss] HTTP loadbalancing
Bill Burke wrote: Cool! I hope nobody took offense to any of my comments! I was hoping to generate a discussion exactly like this! More comments follow... There have been several requests for something like this over the last year or so - this discussion was good to get me to actually start doing something. While using DNS may well be a naive, I think it is more naive to think that user space code running on a general purpose computer is a good solution if you are concerned about load and/or failover. If you really want performance and reliability, then firmware is the solution for you and the 25K will do a little to help my Cisco shares :-) However, I do think we need a reasonable solution that works as a reasonable introduction to loadbalancing and failover. * If sticky sessions are used, or all new connections look for jsessionid= in the first packet of the request and the response. If found, associate the ID with the current connecton allocation. Is the jsessionid available through the URL in HTTPS requests? In HTTPS everything including the URL is encrypted. The balancer will only see a stream of random bytes. I'll be your buddy ;). Hey, Let's talk about it at JBossOne? Well I hope to have it working before JBossOne. I'm close to getting the nio stuff working one way (Client to Server) and I should get the reverse path working shortly. So hopefully next week I'll be able to check in the network infrastructure which we can then work with to make a flexible/robust/simple loadbalancer! NB. I have previously bagged out nio on the Jetty-list- I think I will have to take a lot of that back (other than my complaint about anything with n in the name). It is rather cool and does have good links back to the old blocking stuff In fact a ChannelListener is now high on my priority list for Jetty. So another suggestion to the JBoss folks that you get the build environment able to optionally compile 1.4 based classes for these new bells and whistles! In the meantime, this might be a good source for requirements: http://www.cisco.com/univercd/cc/td/doc/pcat/11150.htm thanks -- 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] Re: NioListener. Was: HTTP loadbalancing
Dan, You general purpose server sounds interesting - as there does appear to be more cases of multiple protocols being sent to the same port for some reason. However I think it would be a little too complex and perhaps slow for a general Jetty listener. My intentions for a NioListener for Jetty is to follow the model I used for the NBIO listener. That is a select set is only used for accepts and idle connections. An connection is idled after a response has been sent if it is persitent and no bytes are available to be read. Once idle, the connection is put into the select set waiting for read or close events. Once a connection has been selected as readable, it will be taken out of the select set, switched to blocking mode, the socket extracted, a thread allocated and the standard jetty handling called for a request/response cycle. The advantage of this approach is that it does not break any of the existing connection handling, but does not tie up a thread per idle connection. Typically 90% of connections are idle at any given time, so this is a big saving for scaling up. Apparently the 2.4 servlet spec is going to have some more support for nio built in - but they have not said what that will be (and will probably only tell the community after it is all too late to change). cheers Dan Christopherson wrote: This is maybe a bit offtopic, and a bit long, but this is one of those serindipitous occasions where a conversation strikes on something somebody else is already working on... Greg Wilkins wrote: + Use java.nio as: * if you care about performance you should be using jdk1.4 anyway * if you want one machine to handle more connections than the sum of all your servers, then java.net.ServerSocket aint going to do the job! * I want to play with nio before I write the NioListener for Jetty! Hmm. I've been writing a sort of general purpose TCP server using the NIO stuff that I'd actually rather like to try grafting onto the front end of Jetty, if you don't mind. Bear in mind that this is fairly early work yet, and there are probably lots of holes. Basically, the way it's structure is there is a Server (MBean) which contains listeners (one for each declared hostname:port). The Server has a single thread that uses an NIO selector to find out when it needs to accept on any of them. The resulting SocketChannels are handed off to a ReaderManager, which chooses a ReaderThread to handle that channel. Each reader thread selects on all of its channels, reads data and delegates to a Protocol implementation to build a Request and put appropriate data into it. Once the request gets to the state HEADERS_READ (the headers have all been read and there is enough there to be dispatched) the Reader thread hands gets a worker thread from a pool and hands the Request off to a ContextManager which uses information from the request to dispatch to the appropriate RequestHandler stack (which is where I _think_ Jetty would come in). When the request needs to be written to its output (because it's buffer is full, or the request has been completely handled) it (carrying its SocketChannel) gets handed off/hands itself to a WriterManager, which chooses a WriteThread to handle it in a similiar non-blocking fashion as the ReaderThread. Note that a POST request (or an SMTP command, or a JBossMQ message on a new protocol, or anything that can distinguish header/envelope from body/payload) can be dispatched and processing can begin while the request body is still being read. Likewise on the output: if the buffer is full, it will start to be written while processing continues. ReaderThreads hold onto SocketChannels until they're closed (to enable keep alive), WriterThreads do not. Direct Byte Buffers are used and pooled wherever possible, allowing the underlying implementation to optimize transfers. I think the biggest advantage here is the level of control it gives administrators over thread usage: you can configure read, write, and work pools separately. One of the things people notice in JBoss under linux is the number of threads used - they'd notice it under Windows or any commercial Unix as well if they looked, it's just that Linux puts its threads right out there for you to see and freak out on in ps and top et. al. Another thought I've had is to use this same framework as the basis for a new invoker for JBoss, so that remote client invocations don't put the server at the mercy of the whims of RMI's thread usage. thoughts, chortels, flames? thanks for your time, danch -- 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
[JBoss-dev] Re: [jetty-discuss] HTTP loadbalancing
While using DNS may well be a naive, I think it is more naive to think that user space code running on a general purpose computer is a good solution if you are concerned about load and/or failover. If you really want performance and reliability, then firmware is the solution for you and the 25K will do a little to help my Cisco shares :-) However, I do think we need a reasonable solution that works as a reasonable introduction to loadbalancing and failover. If my understanding of the clustering / session manager is correct, it does not really matter if sessions are not 100% sticky. The clustering stuff will cope, but it is just more efficient if it does not need to move everything to a new node. So this is the approach that I would like to take for this: + Write it in java, because we want to be 100% pure. If that is not fast enough - buy Cisco ( I will declare an interest here as Cisco are the prime sponsor of Jetty development !-) + Use java.nio as: * if you care about performance you should be using jdk1.4 anyway * if you want one machine to handle more connections than the sum of all your servers, then java.net.ServerSocket aint going to do the job! * I want to play with nio before I write the NioListener for Jetty! * Allow sticky sessions, sticky IP and sticky host options. * If sticky sessions are used, or all new connections look for jsessionid= in the first packet of the request and the response. If found, associate the ID with the current connecton allocation. * If sticky IP is set, use a hashmap of the source InetAddress to determine the connection association. * If sticky host option is set, use hashmap on InetAddress.getCanonicalHostName() to determine the connection association. * If multiple options are set, they are tried in the order they we defined until an association is found. * Stickyness applies to a listener, so you can have different settings for http and https ports. * If you have a new connection, an association to a server will be made via a pluggable balance policy. The default will be round robin or least connections. * If a connections are only re-associated as they break or fail to connect to a server. + A failing server will continue to be tried for new connections according to the balancing policy - so that it can come back into the fold. A fancy balancing policy may wish to exclude a failed server for a period of time, or until further notice. + At this stage, there will be no re-balancing of existing associations if the load becomes asymmetric due to random chance (or any other reason). How does that sound? It should at least be a start for load balancing and failover. I should have something working like this within a day or a month (Now there is a broad estimate for you). I'm happy to do this myself, but would also appreciate a keen buddy on this once the skeleton is in place. cheers Bill Burke wrote: I was looking at the way Apache+Tomcat works. They use a protocol between themselves. Apache decrypts the SSL message and extracts sticky session information as well as SSL information and passes this over a load-balanced socket over a proprietary protocol to the Tomcat instance. The message contains the HTTP request as well as all the SSL information. Tomcat unpacks the message, creates an HttpRequest, and sends the request on their local bus. I guess they call this a Tomcat Connector. --- Marc, I see no reason why you have to be separate from Apache. The issues here aren't trivial and they've already done all the work and they're open-source. Actually their license is much more liberal than LGPL. Plus for this kind of stuff you probably want something written in C for speed as Greg suggested. Jetty already leverages Jasper, why not mod_jk? --- As far as load-balancing based on client IP and AOL, it is even worse than you think. Supposedly, a client's IP can change in the middle of the session.(I said supposedly remember ;) You acutally have to stick on a mask of the IP. Sure, client IP isn't the best way, but it was the only thing us ignorant bloaks knew at the time :) -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 07, 2002 6:05 AM To: [EMAIL PROTECTED] Subject: Re: [jetty-discuss] HTTP loadbalancing Chris, Your comments are correct (and user are the only ones who should post to jetty-discuss!-) There are two common solutions: As the load balancer is in your organization then you can give it the server certificate and it can terminate the SSL connection. The forwarded connection is then done using standard HTTP or some other protocol. It is not over the internet, so it is moderately secure (depending on the organizations network setup). The main problem with this setup, is that the server knows nothing about the SSL side of things
Re: [JBoss-dev] Bug: Jetty + forwarding requests
Alexander, Which methods don't get changed? getRequestURI used to change with a forward, but now does not. This is according to the spec. getServletPath and getPathInfo are definitely working for me. getParameter has always been a little problematic and I would not be surprized if there was a problem there. But the watchdog test suite gives this stuff a fair wack and we are passing those tests - so I'd be surprised if anything was majorly wrong. Anyway, put the details in a bug report (either on jboss or jetty - your call) and I'll have a look. cheers Alexander Horuzhiy wrote: Hi developpers, I think, I find bug in Jetty. When doing forward request getRequestDispatcher(target).forward(request, response), appear buG - target receive old request, i.e. parameters don't adjusted to match the path of the target resource. With early version of Jetty (with Jboss 3.0.0beta1) it work. //Alexander _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=10170 ___ 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
[JBoss-dev] Security problem in authentication model.
There is a problem with the use of ThreadLocals to record Authentication when the client (in this case Jetty) is using ThreadPools. I have previously mentioned this, but now I have confirmation that it is a problem for a Client. He created a small thread pool for the listener (4 threads), then used 4 browsers to hit authenticated pages and authenticated with a different user for each browser. The effect of this was for the JBoss authentication mechanism to create ThreadLocal authentications for each of these threads. He then got new browsers and started hitting unauthenticated pages that reported the request and EJB auth details. These new requests receive random EJB authentication depending on which thread from the thread pool they are allocated: 23:33:25,434 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:25,464 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:38,333 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:33:38,373 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,341 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,371 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:57,186 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin 23:34:57,236 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin We need a mechanism to unauthenticate Threads, so the Jetty can call this after each request. Note that it is not an option to get rid of the ThreadPool as that would be a HUGE performance hit. regards -- 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] Security problem in authentication model.
OK, I see what they are doing and will add a call to SecurityAssociation.setPrincipal(null) after each request. Scott M Stark wrote: This is why the Catalina security integration implements both the Realm and Valve interfaces. The Realm callbacks establish the authentication and the Valve limits the scope of the information to the duration of the request. The thread of control returns to the Catalina pool with no thread local association. The Tomcat 3.2 security integration does the same thing, but it a lot more work because the integration interface is not as clean. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Greg Wilkins [EMAIL PROTECTED] To: [EMAIL PROTECTED]; jules [EMAIL PROTECTED] Sent: Monday, February 25, 2002 4:30 PM Subject: [JBoss-dev] Security problem in authentication model. There is a problem with the use of ThreadLocals to record Authentication when the client (in this case Jetty) is using ThreadPools. I have previously mentioned this, but now I have confirmation that it is a problem for a Client. He created a small thread pool for the listener (4 threads), then used 4 browsers to hit authenticated pages and authenticated with a different user for each browser. The effect of this was for the JBoss authentication mechanism to create ThreadLocal authentications for each of these threads. He then got new browsers and started hitting unauthenticated pages that reported the request and EJB auth details. These new requests receive random EJB authentication depending on which thread from the thread pool they are allocated: 23:33:25,434 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:25,464 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:38,333 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:33:38,373 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,341 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,371 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:57,186 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin 23:34:57,236 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin We need a mechanism to unauthenticate Threads, so the Jetty can call this after each request. Note that it is not an option to get rid of the ThreadPool as that would be a HUGE performance hit. regards -- 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 -- 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] Problem with NestedURLHandlerFactory
I'm trying to check out Jetty's behaviour with the njar: URL type, but
am having some problems making NestedURLHandlerFactory work?
to demonstrate, I have modified the main in the class to
public static void main(String[] arguments) throws Exception
{
NestedURLHandlerFactory.start();
//URL u = new URL(njar:njar:file:c:/test1.zip!/test2.zip!/hello.txt);
//String data = new DataInputStream(u.openStream()).readLine();
//System.out.println(The file said: + data);
try
{
URL u =
new
URL(njar:njar:file:/tmp/examples2.war!/examples.war!/WEB-INF/web.xml);
InputStream in = u.openStream();
byte[] buf = new byte[1024];
int l=in.read(buf,0,1024);
while (l=0)
{
System.err.write(buf,0,l);
l=in.read(buf,0,1024);
}
}
catch(Exception e)
{
e.printStackTrace();
}
try
{
URL u =
new URL(njar:file:/tmp/examples.war!/WEB-INF/web.xml);
InputStream in = u.openStream();
byte[] buf = new byte[1024];
int l=in.read(buf,0,1024);
while (l=0)
{
System.err.write(buf,0,l);
l=in.read(buf,0,1024);
}
}
catch(Exception e)
{
e.printStackTrace();
}
}
I run this against the two test war files I have attached to this email (put in the
/tmp directory).
The first attempt on njar:njar:file:/tmp/examples2.war!/examples.war!/WEB-INF/web.xml
fails with:
java.io.FileNotFoundException: JAR entry WEB-INF/web.xml not found in
/tmp/nested-25835.jar
when I check /tmp/nested-25835.jar, it is exactly the same as /tmp/examples2.war -
which I
don't think is correct.
You can see why this is happening on the next test on
njar:file:/tmp/examples.war!/WEB-INF/web.xml,
which returns the content of /tmp/examples.war rather than the web.xml classs.
This is on linux using jdk 1.3.1_02-b02 and 1.4.0-rc-b91
The full text of a run is :
gregw@brick: ~/Jetty4
[596] java org.jboss.util.NestedURLHandlerFactory
Opening next nested jar: njar:file:/tmp/examples2.war!/examples.war
Opening final nested jar: file:/tmp/examples2.war
file URL : file:/tmp/nested-50611.jar
Opening saved jar: jar:file:/tmp/nested-50611.jar!/WEB-INF/web.xml
java.io.FileNotFoundException: JAR entry WEB-INF/web.xml not found in
/tmp/nested-50611.jar
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:95)
at
sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:105)
at java.net.URL.openStream(URL.java:955)
at
org.jboss.util.NestedURLHandlerFactory.main(NestedURLHandlerFactory.java:179)
Opening final nested jar: file:/tmp/examples.war
K-*ÎÌϳR0Ô3àår.JM,IMÑuªcKbáY,sMEwëxÆcæ)øfvåvWu¤æu+xæ%ëiòrñr`P¢?c«GGPKbXs
etc. etc. etc. until my xterm goes strange!
PS. The temp files should be marked as deleteOnExit.
--
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
examples.war
Description: Binary data
examples2.war
Description: Binary data
[JBoss-dev] Re: Problem with NestedURLHandlerFactory
OK, I'm still having trouble making Jetty run with an unpacked njar URL. After a few changes it is getting a little better, but if I am passed something like: njar:file:/home/gregw/Jetty4/webapps/test2.jar^/test.war then Jetty tries to run that unpacked by using URLs like: jar:njar:file:/home/gregw/Jetty4/webapps/test2.jar^/test.war!/WEB-INF/web.xml All starts off well, but I eventually get problems with the JarURLConnection like: java.lang.NullPointerException at java.util.zip.Inflater.reset(Inflater.java:253) at java.util.zip.ZipFile.getInflater(ZipFile.java:249) at java.util.zip.ZipFile.getInputStream(ZipFile.java:197) at java.util.zip.ZipFile.getInputStream(ZipFile.java:174) at java.util.jar.JarFile.getInputStream(JarFile.java:307) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:120) at org.mortbay.util.Resource.exists(Resource.java:262) at org.mortbay.util.JarResource.exists(JarResource.java:69) at org.mortbay.jetty.servlet.ServletHandler$Context.getResource(ServletHandler.java:888) at org.mortbay.jetty.servlet.ServletHandler$Context.getResourceAsStream(ServletHandler.java:915) at org.apache.jasper.compiler.TldLocationsCache.processWebDotXml(TldLocationsCache.java:152) at org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:138) at org.apache.jasper.EmbededServletOptions.init(EmbededServletOptions.java:345) at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:266) 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:390) at org.mortbay.http.HttpServer.start(HttpServer.java:186) at org.mortbay.jetty.Server.main(Server.java:331) I'm not sure if this is a bug in the JarURLConnection or your nested handler. The pity is that if the jar:.../! wrapping did not initially work, then Jetty would have extracted the war and continued OK. So this should work in JBoss as the default is the force extraction. but it would be nice to be able to run without extracting. So hopefully when I commit the changes to Jetty, you will not need to do the extraction unless AbstractWebApplication needs it - in which case it is better for JBoss to do the extraction once and pass Jetty the extracted location. cheers David Jencks wrote: Here's my current version. Everything except Jetty runs fine: this is I think because Jetty doesn't understand njar:...^/ very well. -- 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] Re: Virtual Host support
Virtual host support has been in Jetty from the day dot. It is simply that there is no J2ee standard deployment mechanism for them in JBoss. You are correct that the web-jetty.xml file can be used to setup a virtual host for a webapplication. Something like: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE Configure PUBLIC -//Mort Bay Consulting//DTD Configure 1.1//EN http://jetty.mortbay.org/configure_1_1.dtd; Configure class=org.mortbay.jetty.servlet.WebApplicationContext Call name=registerHostArgYourVirtualHostName/Arg/Call /Configure Marius Kotsbak wrote: I see that Virtual Host support is mentioned in the TODO-file in jboss/jetty plugin. Does that mean that it isn't possible yet to set up virtual hosts that each war should be bound to? Is it possible to do this with WEB-INF/web-jetty.xml? I think this would be best to specify in jboss-web.xml since it is common among different web containers, together with the context root. Does anyone know when this will be implemented? Thanks Marius Boostcom.no -- 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: [jetty-discuss] [Fwd: [JBoss-dev] do filter set in web.xml work?]
Good point!!
I've put a fix in so that the ServletHandler get's started as part of the
FilterHandler startup. That should be synced with JBoss cvs shortly.
Jules Gosnell wrote:
I'm forwarding this from JBoss-dev.
Jules
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] do filter set in web.xml work?
From:
Roman Kunert [EMAIL PROTECTED]
Date:
Mon, 18 Feb 2002 14:00:49 -0600
To:
[EMAIL PROTECTED]
Hi,
While playing with Sun's waf-framework I encountered the following error:
20:18:15,494 ERROR [Jetty] problem deploying
file:/home/roman/jboss_src/3.0/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.einfa.war
to /einfa
java.lang.NullPointerException
at
org.mortbay.jetty.servlet.ServletHandler$Context.getResource(ServletHandler.java:867)
at de.meldebehoerde.einfa.signon.web.SignOnFilter.init(Unknown Source)
at org.mortbay.jetty.servlet.FilterHolder.start(FilterHolder.java:88)
at org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:152)
at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1370)
at
org.jboss.jetty.JBossWebApplicationContext.startHandlers(JBossWebApplicationContext.java:220)
at org.mortbay.http.HttpContext.start(HttpContext.java:1341)
at
org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:428)
at org.jboss.jetty.Jetty.deploy(Jetty.java:273)
at org.jboss.jetty.JettyService.performDeploy(JettyService.java:284)
...
The corresponding lines from SignOnFilter.java:
public void init(FilterConfig config) throws ServletException {
this.config = config;
URL protectedResourcesURL = null;
try {
protectedResourcesURL =
config.getServletContext().getResource(/WEB-INF/signon-config.xml);
...
It seems to me as if the ServletContext hasn't been created at this stage of
deployment ('config.getServletContext()' returns null)?
Any ideas?
_
View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9052
___
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
[JBoss-dev] JDK 1.4 Logging in Jetty
JBoss Jetty developers I have just added optional support for JDK 1.4 logging into Jetty. I expect that this will totally break the JBoss build, so I will not tag the src1.4 tree in Jetty for inclusion into JBoss. We will need to be careful to not use standard release tags for future imports as you will then get the 1.4 stuff. You probably also want to start thinking about the migration path. In Jetty I have added a src1.4 tree into which 1.4 dependant code goes. This is both new classes and replacements for classes that exist in the normal src hierarchy. My build.xml script only compiles the src1.4 stuff into classes if java.util.logging.Logger is available. I expect this to be a major pain for the next 2 to 4 years! The stuff in src1.4 at the moment is just improved Logging, using the StackTraceElement stuff (so I don't have to parse the stack anymore) and provides a LoggerLogSink to redirect the Jetty log mechanism into the 1.4 Logger for org.mortbay 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
Re: [JBoss-dev] Status of ear deployment
Sorry, but I've been away from my computer, so I have not been able to contribute to this discussion But looking over what has been said - my quick response is If WARDeployer is handling the WEB-INF/lib jars *and* the WEB-INF/classes directory, then I think the simplest thing to do is to switch the Jetty CL into J2 compliant mode (ie always delegates). This means that whatever policy is selected (Servlet compliant or J2 compliant) will be implemented in a single place within JBoss. Jetty's own interpretation of the servlet spec and changes to it's definition of System class will not effect the running of JBoss. Actually, I'll look at changing Jetty so that it can use JBoss's classloader directly and then we don't need to bother with any delegation. But as I said, this is my quick response as I once again rush out the door... I'll read everything again late tonight and send a more considered response. cheers marc fleury wrote: Sorry thinking some more and answering some |2- Jetty CLs bypass the JDK parent delegation model and do |explicit creation |of classes from their classloaders. So any new class seen by Jetty is |loaded by Jetty CL, delegated to JBoss CL if not found. THIS IS SPEC |COMPLIANT. THIS COMPLETELY BREAKS THE INTEGRATION as the Jetty Classes |would not be seen as loaded by the same classloaders as the JBoss classes. |You want to share classes? tough it out. Well come to think of it it only breaks integration if we are *sharing* classes. Duplicate classes in /webinf/classes and some other package (EJB or another servlet) would not be seen. The proper way to do integration (classes seen by this ear/war and other classes) is to move the classes out of there. So in fact having Jetty implement the spec and look for classes locally and then delegate to JBoss would only break integration in case the user duplicates classes in their packages and is looking for sharing. This looks OK. |3- I code WARDeployer parsing of the webinf/classes (simple), we can code a |fancy granularity if need be (scott's point) but priority is to |integration and ease of use. Never breaks, can be made spec |compliant. This |is transparent to Jetty (bypasses its management of web-inf/classes) This is really my favorite now. I am working on the assumption that dave is not full of shit and that this package was indeed working before, this means that we were parsing the webinf/classes in OUR deployer already, unless jetty was implementing a 2/ solution before which it wasn't. Greg, note that if I implement 3 right now and you implement 2 your 2 will override 3 (you will find the class in the 2 step and not go with the UCL from 3/ therefore have exactly the same effect). In other words you are free to implement your spec compliance and do away with parent delegation as requested by the spec (which is dumb imsho) with the knowledge and understanding that 1- this is irrelevant to the case standalone or not it only comes into play if you have a CL to delegate to (JBoss parent in this case). 2- it will only break integration of shared classes. But that is the spec for you. I think I have reached a conclusion on my part. a/ I will go ahead with 3/ b/ you can override by implementing your JettyCL that do servlet spec compliance on ordering but if you don't and just delegate as is, we have integration. And thus speed. Anything for speed. |4- The user stop bothering us with more packaging non-sense from SUN, puts this is un-realistic :) |5- Apache developers get their shit together and so is this. marcf WAIT WAIT WAIT PS: 1/ (UCL in Jetty) would give us spec compliance AND integration, but I would rather do the work myself... although that would be one place where having the JBoss/Jetty codebase becomes interesting... h maybe this is simpler even though it is really a fork from the jetty base. -- 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: AW: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Auth entication Problem
This is now implemented in both Jetty4 and Jetty3_1 CVS branches. Hopefully I'll get a release of both of these out in the next week cheers Jung , Dr. Christoph wrote: Greg, Jules, Luke! thx much for your replies. Indeed, the '*' role authentication constraint seems to match my issue very well if it also lets through null-authenticated/credential calls ... If I can help to patch SecurityHandler (jetty4 or backport to jetty3, perhaps), please let me know. Otherwise, I would be glad if you could send me a notification when it is available ... Thnx much, CGJ -Ursprüngliche Nachricht- Von: Greg Wilkins [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 31. Januar 2002 01:31 An: Luke Taylor Cc: 'Jboss-Development ([EMAIL PROTECTED])'; [EMAIL PROTECTED] Betreff: Re: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem Luke, I stand corrected. It is the '*' role behaviour that should be used. The lack of any role means no access.I knew the 2.3 spec had defined both these cases, but got them mixed up. Jetty4 will definitely support this style of security constraint soon. I think Jetty3 can also be made to support this without breaking any existing code (but I'll think about this a bit more before changing this). thanks Luke Taylor wrote: Greg Wilkins wrote: Cristoph, Eitherway, you do not want the semantics of NONE, you want the user to be authenticated, but you do not care what group they are in. Again, Jetty has an extension to the spec to support this. All users are in the role org.mortbay.http.User. However this is implemented in the HashUserRealm which is not used by JBoss. So for now, you must define a role that all your JBoss users are in and specify an AuthConstraint for that role. Hi Greg, Wouldn't this be the same as using * for the role-name? I had a brief look at the servlet 2.3 spec before replying previously and that's the syntax it uses for all roles. So it should then perform authentication and allow any user who has a role recognised by the application. Luke. -- 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: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem
=\+_realmName+''); response.sendError(HttpResponse.__401_Unauthorized); return false; } Is there another way to do it? Is my goal against the spec at all? Does Jetty 4 do it exactly like this? Or do you think there is a small potential to persuade Jetty to insert a reasonable null-credential against login-module case? Thanks much, CGJ (Dr. Schorsch) Currently spinnin´ all-time soul classic: Omar, Who chooses the seasons *Do You Yahoo!?* Get personalised at My Yahoo! http://uk.rd.yahoo.com/mail_uk/my?http://uk.my.yahoo.com. *Yahoo! Groups Sponsor* http://us.a1.yimg.com/us.yimg.com/a/an/anchor/shopping/gloss/gel_ncs_fragrance_intution.jpg http://rd.yahoo.com/M=153641.1824646.3335993.1261774/D=egroupweb/S=1705375618:HM/A=889707/R=0/*http://shop.store.yahoo.com/cgi-bin/clink?gloss2+shopping:dmad/M=153641.1824646.3335993.1261774/D=egroupweb/S=1705375618:HM/A=889707/R=1/1012336098+http://us.rmi.yahoo.com/rmi/http://www.gloss.com/rmi-framed-url/http://www.gloss.com/module/EsteeLauder/templates/product/prod_multi.jhtml%3FmCategoryId=cat40207%26mktAdTrack=2272 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 the Yahoo! Terms of Service 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: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem
Luke, I stand corrected. It is the '*' role behaviour that should be used. The lack of any role means no access.I knew the 2.3 spec had defined both these cases, but got them mixed up. Jetty4 will definitely support this style of security constraint soon. I think Jetty3 can also be made to support this without breaking any existing code (but I'll think about this a bit more before changing this). thanks Luke Taylor wrote: Greg Wilkins wrote: Cristoph, Eitherway, you do not want the semantics of NONE, you want the user to be authenticated, but you do not care what group they are in. Again, Jetty has an extension to the spec to support this. All users are in the role org.mortbay.http.User. However this is implemented in the HashUserRealm which is not used by JBoss. So for now, you must define a role that all your JBoss users are in and specify an AuthConstraint for that role. Hi Greg, Wouldn't this be the same as using * for the role-name? I had a brief look at the servlet 2.3 spec before replying previously and that's the syntax it uses for all roles. So it should then perform authentication and allow any user who has a role recognised by the application. Luke. -- 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: [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
[JBoss-dev] Re: isAuthenticated. JBoss/Jetty
Jules Gosnell wrote: isAuthenticated() is now in. It reauthenticates every time it is called, using a password cached from the last call to authenticate(). This will have been from the original request thread. Cool, but it will have the effect of authorizing any thread that is allocated to a request for that session. This will make things work (but maybe too well). I haven't pursued the threadlocal issue. I do not explicitly set them up, so I am assuming someone else is responsible for tidying them up. Of course, I could be wrong :-) I still think that somebody needs to look at this. Using ThreadLocals to authorize threads is probably cool for passing control to third party objects and allowing them to also be authenticated. However it simply does not address the problems of a) Threads started by those threads (should you authorize threadgroups???) and b) Thread pools. Currently over time, every thread in a thread pool will get authorized for some user or other and there is no mechanism that I know to remove that authorization. Thread pooling is such common practise, that any security mechanism must handle it. Either the Jboss mechanism needs to stop using ThreadLocals, or a bullet proof mechanism needs to be provided for removing authorization from threads that are returned to the pools. cheers Greg Wilkins wrote: Well the idea of an extra call is that it can be implemented simply for most situations (return true). For JBoss where a) authorization can be revoked and b) the thread locals need to be setup, you will have to reauthenticate on every call to isAuthenticated. You will have to cache the info you need from the authenticate() request. As you say, you can cache the request, only the data you get from it. Are the JBoss guys discussing the ThreadLocal issue at all?? cheers Jules Gosnell wrote: Do you mean : 1. re-authenticate() on every call to isAuthenticated() - if so from where am I meant to pick up the HttpRequest (needed for setting Attributes to support e.g JAAS), and the password ? The passwd could be cached from the initial authentication, but the request can't. But then if they were the same call, why have 2 different ones in the API ? 2. cache result of authenticate() and return that. I figure you mean (1), hence the question. Jules Greg Wilkins wrote: I have added isAuthenticated call to UserPrinciple to check if a session is still authenticated. You will need to implement this to call the JBoss authentication mechanism again, which should fix most of our problems. I still think the JBoss ThreadLocals suck - and don't know how we can get rid of them??? -- 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- 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: [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: [jetty-discuss] FW: [JBoss-dev] Runaway threads in 3.0 ?
I'm on the case. The session scavenger is there to timeout sessions. It has some poxy code to try and guestimate a timeout interval to check the sessions. This was half cleaned up in Jetty4, but I expect it has a busy loop bug from the sound of it. Check your session expiry interval in your web.xml. If it is zero, set it to something. If it is set, set it to something REALLY LARGE. I'll through away the existing code and get a new implementation out tomorrow. regards --- Hunter Hillegas [EMAIL PROTECTED] wrote: Just in case no one else forwards this... Something on Jboss-Dev about run-away threads in Jetty 4... -- Forwarded Message From: marc fleury [EMAIL PROTECTED] Date: Sun, 9 Dec 2001 14:40:40 -0700 (MST) To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Runaway threads in 3.0 ? By analyzing HPROF output of an idle server with HPjmeter, it appears that org.mortbay.jetty.servlet.HashSessionManager$SessionSc venger.run is the main culprit? What is all this stuff anyway? ouch... take this to jetty-discuss right away, and ask them to look into it, they are usually pretty fast and accurate in fixing, if we are going to ship it standard with JBoss it better be up to snuff, otherwise buh bye marcf -- End of Forwarded Message Yahoo! Groups Sponsor -~-- Promise to Quit Nicotrol will help http://us.click.yahoo.com/5vN8tD/AqSDAA/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] Mort Bay Consulting Australia and UK.GB Phone: +44-(0)7775534369 http://www.mortbay.com AU Phone: +61-(0)299772395 http://shopping.yahoo.com.au - Yahoo! Shopping - Free CDs for thousands of Priority Shoppers! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ANN] JBoss 3.0 alpha is out
://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 __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- 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] EAR classpath access....
I can't see how we can get java compilers to use our classloaders without actually modifying the javac compilers. Ant does not do this - it passed a classpath that you have specified in the build.xml The fundamental problem is that JSPs are not well designed when it comes to deployment, as you essentially need to support a miniture IDE on an arbitrary platform.IMHO it is outside the scope of Jetty and/or JBoss to try to solve the design problems of JSPs I think that the best that we can do is to make a best effort approach to determine a file classpath that we can pass to the JspServlet. We should also provide good override mechanisms to allow a deployer (or ear developer) to explicitly set the classpath passed to the JspServlet Of course this is only a half arsed solution - but then I think JSPs are the thing that is half arsed.If you think about it, the chances of any compiler following the inverted classloading priorities of the latest servlet spec are zero anyway. So the runtime classpath will load jars from the context in preference to the compilers ext directory, but at compile time, you will almost certainly get the jars from the ext directory. To try specifying the boot classpath would just be way to platform dependant. So I think that anybody with a non trivial context classpath is going to have all sorts of JSP compile problems anyway. So I think we should stop trying to solve JSPs problems - take a best guess at a file classpath and then suggest pre-compilation if they get any deployment problems. cheers marc fleury wrote: |Yeap, jikes is not java -- it is C++. Also, it may very well be so that |even Sun's compiler can't do this. In Tomcat they configure a command line |for sun.tools.javac which has a special -classpath switch. Don't know if |the jvm uses it or javac itself reads the entries in the classpath and |loads classes from there bypassing CL mechanisms. | |This sucks big time, because if you don't precompile JSPs, you end up |having to trag all the necessary .class files into the WAR. No |integration... well then FUCK it ! we use the invm javac, we tweak it to be in process with the right CL and VOILA! If ANT can do it we can do it, and don't give me the speed booboo, the speed of javac in process is diabolical. It takes what 20 seconds to compile the WHOLE of JBOSS? so your 2-3 little JSP are not going to impress Javac invm marcf | | | | -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
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: Your just putting the onus on the Application programmer to work around shortcomings in the Server - I think. But that is exactly the problem with the non-compliant class loader as specified by the 2.3 servlet spec. Because it advocates a application developer knows better approach, then the application developer get's total control over non-system classes - so they have to set it up right, else it does not work. If they want to share class instances between the servlet container and the EJB container, then they MUST prevent the servlet context from seeing those classes, else it will load it's own copy of them. There is absolutely no programatic way to distinguish between a webapp that has included a class on purpose to override an old version in the container, or due to an unknowing programmer being overzealous with their classpath. Perhaps someone will make a pronouncement on HOW JBoss/Jetty SHOULD behave here. Then we can figure out how to achieve this behaviour. Unfortunatley the default behaviour should be what the specification says and the 2.3 servlet spec definitely requires the non java2 compliant class loader. Somebody should check the full J2EE specification to see exactly what it specifies, as there is no guarantee that the specs are compatible in this regards. I'm in two minds about providing the compliant loader options - while I think it is the simple and correct way to go, it may just complicate things to propogate a non standard mode. Maybe EJB developers are just going to have to be a lot more careful with their classpaths now??? And this includes the developers of the JBoss web integration test suite. Their should not be classes in the webapp context that are also available via the EJB container or system class loader. Regards -- 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: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Rickard Öberg wrote: Julian Gosnell wrote: Are you saying that we should simply support both - but not a third strategy which somehow supports sandboxing AND optimised intra-container calls ? Well, I believe the real fix is to make the EJB-loader use the non Java2 class-loading style as well, i.e. force people to bundle in JAR's that the app is going to use. That is the ultimate way to get things portable, and to be able to allow different running apps use different versions of, say, JAXP. I have to say that I reluctantly agree. Now that the non-compliant loader cat is out of the bag, we have no choice but to force users to be disciplined about their bundling of jars. For consistency this should apply the the EJB container as well as teh servlet container (again assuming the J2EE spec does agree with the 2.3 servlet spec). However, I would like to suggest a change in the language. We should try to force the users to NOT include jars that they can reasonably expect the container will provide. JAXP is a key example, as I think it was the driver for the change in the specification. Users wanted richer XML parsing for their web applications than was provided by their containers. Hence they now have the ability to write an application that is dependant on a specific JAXP version and/or provider by bundling the jars for them. But now almost all container provide recent versions of JAXP with good parser implementations, so applications that include jaxp.jar and xerces.jar are probably fixing a problem that no longer exists! So our language should encourage users to NOT include their own versions of jars unless absolutely necessary for a particular deployment. Somewhere is should be clearly stated that the BYO implementation approach is bad because: + Firstly and foremost, it is just bad OO design. You should be dependant on the interfaces not the implementations. Sure it allows you to get around short term deployment issues, but it is a much better approach to try to get your container to provide the APIs and implementations that you need. + Including your own jars does create confusion and problems in calling local interfaces that actually cross classloader boundaries. The new priority inversion of classloader increases the chances of cross loader calls being made. + There is a significant cost in terms of memory and serialization. + Applications that provide their own implementations of common libraries cannot receive the benefits of updating the container. If new versions are deployed by a container that fix bugs or improve performance, these are not used by applications that have included their own jars. + The logical extension of shipping your own jaxp.jar in order to be portable is to ship your own swing, your own jboss and eventually your own JVM, OS and hardware :-) Thus I think the documentation should not be written so that developers think I better include jaxp.jar xerces.jar as it is better to be safe than sorry. Rather they should be encouraged to not include these jars, in the knowledge that IF a problem does occur with a particular container AND they can't update that container, only then should they can fix that deployment by including specific versions of the jars they need. Finally users should be given the confidence that their containers of choice are open and being actively maintained, thus new APIs and implementations should rapidly become available in the containers. regards -- 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: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: OK - So I will go with Jetty's non-compliant ClassLoader strategy. Calls will only be delegated upwards if they cannot be satisfied locally. Please don't call it Jetty's non-compliant strategy! We are just relunctanly following the servlet spec!-) Trouble is, this fails the isAssignableFrom() check in JRMPContainerInvoker.invoke() and blows up. What class does it fail for? Can't you remove that class/jar from the webapplication, so that it can only be loaded from the EJB classloader? 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
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
So just to clarify all this... RH is the next release of JBoss (Rabbit Hole?) and it will include a classloader that supports scopes. I gather that scopes are a way to control class loading that is not directly related to the parent hierarchy of classloaders (inverted or otherwise). Jetty/JBoss should ignore the 2.3 spec recommendation to invert the classloading priorities and always delegate to the JBoss classloader. If a developer wants to replace things such as JAXP, they will be able to do so via the JBoss scope mechanism. This can be done simply by the Jetty JBoss module changing the compliance mode of the Jetty ContextLoader. Note that standalone Jetty4 will continue to support the 2.3 recommendation by default for now. We can review this before Jetty4 goes stable. 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
Re: [JBoss-dev] Re: [jetty-discuss] Re: Persistant HttpSession
We have started work on pluggable session managers, but no definite plans on when it will make it into a release. Two options, add it as part of the 2.3 API work, which will mean it will only be available after several months of alpha and beta releases. Or, add it to the 3.1.x series, which should be able to be done in a few weeks. It sounds like jboss would like this sooner rather than later, so the second approach may be the best one. cheers marc fleury wrote: So we need to hear from the jetty side... guys... did you make any progress with teh HTTPSession cluster as an entity? Interestingly enough EJB's are appearing as system constructs (there is another place where we see it with Juha it is in an advanced management console for clustered jmx nodes) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Monday, September 24, 2001 10:59 AM |To: [EMAIL PROTECTED]; Greg Wilkins; |[EMAIL PROTECTED] |Cc: Julian Gosnell; Bill Burke |Subject: RE: [JBoss-dev] Re: [jetty-discuss] Re: Persistant HttpSession | | |Hello, | |On my side, I have thought to it (even made some basic designs). |Nevertheless, I will first work on the HA framework with Bill, |SLSB, ... the |HTTPSession trick is about in the same todo line as the SFSB (guess why). | |Cheers, | | | | HASacha | | | | -Message d'origine- | De : [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]De la part de marc | fleury | Envoye : lundi, 24 septembre 2001 16:45 | A : Greg Wilkins; [EMAIL PROTECTED] | Cc : Julian Gosnell; [EMAIL PROTECTED]; Bill Burke | Objet : RE: [JBoss-dev] Re: [jetty-discuss] Re: Persistant HttpSession | | | hey... | | did you make any progress on that front? i would love to see it | working and | see us optimize the time under it. | | marcf | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development Yahoo! Groups Sponsor -~-- Get your FREE VeriSign guide to security solutions for your web site: encrypting transactions, securing intranets, and more! http://us.click.yahoo.com/XrFcOC/m5_CAA/yigFAA/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
[JBoss-dev] Re: [Fwd: [jetty-discuss] Virtual Hosts By Web app]
, 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
[JBoss-dev] Jetty3.1.rc9 vs Tomcat4.0rc0
As Jetty is nearing 3.1.0, Tomcat is nearing 4.0.0, I thought it time to have a little comparison. I had a quick peek at the oppositions latest release candidate and have to say, from my quick look, I'm impressed and they have lifted their game. Very slick packaging and documentation, which shows Jetty up a fair bit. I also did a little bit of rought performance testing, and while they have also picked up there game here, I'm pleased to note that Jetty still has it where it counts! Stressing JettyTomcat Threadsreq/sec req/sec - 4 125 222 (but burning lots more CPU) 8 217 208 12 267 216 16 275 215 20 278 212 For the testing, I used the tomcat examples webapp and a random selection of URLs repeated 5000 times per thread. I didn't try to optimize either configuration, but checked that they were both logging each request. This is all completely non-scientific and I probably biased it somehow or other (that subconcious always get's you). It is also comparing apples with oranges a little bit as tomcat 4 is a 2.3 spec container and Jetty is still 2.2. Hopefully somebody more objective and thorough will do some real benchmarking! But what this is showing is that tomcat 4.0 is putting out the challenge, at least in features, packaging and it is much closer on performance. Hopefully this will prompt the Jetty team to lift our game a bit. An ideal result would be for the best servlet server to be very difficult to determine :-) 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
Re: [JBoss-dev] The trouble with ClassLoaders.
The Jetty loader has not changed for a while. It either just uses the parent classloader (ie jboss's classloader) or if there is a WEB-INF/classes directory or jars in WEB-INF/lib, then it creates a derivation of URLClassLoader with the jboss loader as the parent. Has anybody tried running jetty with debug on (maybe verbose) so you can see the loader setup and each class as it is loaded. Debug can be controlled via JMX. cheers Julian Gosnell wrote: Nothing has changed in Jetty between the last 2.4 release which worked and RH, which doesn't. The only changes made to the integration were made last nigh, after I had discovered the problem. The integration code retrieves a ClassLoader passed by the J2EEDeployer on the deployment thread and passes this into Jetty to use for the deployment. I've no idea what sort of changes have been made to this ClassLoader - perhaps Jetty is making some assumptions about it that have changed underneath us Jules -- 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] The trouble with ClassLoaders.
Jules - good tracking, but can we see some stack traces? Does the Class.forName() call end up being passed to the ContextLoader? It should so long as it was called by a class also loaded by the ContextLoader. It may be that some classes are being loaded from the system classpath, when they really should be on the context classpath. If a bit of SOAP is on the system classpath, then it will be loaded from there in preference to the contextloader (parents always get a go first). But then those classes would not be able to use Class.forName() to get classes that are only in the context classloader. cheers PS.Does anybody want to be off the CC list on this? Julian Gosnell wrote: I just tried it... Things are getting more interesting. The problem arises when SOAP tries to load javax.activation.DataSource from WEB-INF/lib/activation.jar It looks like this and 5 other classes from the same jar are all loaded successfully. Then a little bit later SOAP tries to load javax.activation.DataSource again using Class.forName() and the call throws a ClassDefNotFoundError... It looks like it should have found the class already loaded - but failed to. Jules --- Julian Gosnell [EMAIL PROTECTED] wrote: I'll try this this evening, Jules --- Greg Wilkins [EMAIL PROTECTED] wrote: The Jetty loader has not changed for a while. It either just uses the parent classloader (ie jboss's classloader) or if there is a WEB-INF/classes directory or jars in WEB-INF/lib, then it creates a derivation of URLClassLoader with the jboss loader as the parent. Has anybody tried running jetty with debug on (maybe verbose) so you can see the loader setup and each class as it is loaded. Debug can be controlled via JMX. cheers Julian Gosnell wrote: Nothing has changed in Jetty between the last 2.4 release which worked and RH, which doesn't. The only changes made to the integration were made last nigh, after I had discovered the problem. The integration code retrieves a ClassLoader passed by the J2EEDeployer on the deployment thread and passes this into Jetty to use for the deployment. I've no idea what sort of changes have been made to this ClassLoader - perhaps Jetty is making some assumptions about it that have changed underneath us Jules -- 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 Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- 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] Config Files was: Rabit hole
Yep - I know this got a little off topic, but I always react when I hear people discuss where do we put the Jetty config files and I try to encourage them to use a single configuration style for an application and Jetty - be that Jetty's config files or their own. What you say about the config files being a little unreadable is true. Lots of people have talked about XSL front ends or some other way to make them more approachable - but the problem is once developers start using them, they are very straight forward for them - so those efforts stop. I think they would be a little too much for many admins type to use. The unsolved problem with them is persistence. If you use these scripts to configure a system, then an admin uses a graphical JMX tool to change that config - how do you save that new configuration? The beauty of Set only config, is that it can be saved with Gets. Config that uses calling semantics is going to be harder to automatically persist - without the objects themselves knowing about the XML format. Cisco want me to persist configuration soon, so I will have to find a way to solve this problem. Anyway - this is probably enough on this for now. When you guys want to consider updating you config mechanism, I'm more than happy to help out - donate code from Jetty - or change jetty a bit to match whatever you come up with. cheers marc fleury wrote: |The problem with both of the above appraches - is who calls start? |In Jetty - everything implements the lifecycle interface, so it has |start and stop methods. If you call start on HttpServer, it calls |start on all the components within it. So you don't really want |a config agent calling start on every component that it see's registered |along the way There is one thing that I really *love* about your stuff, it is the calling semantics you show in XML. See that is really powerful. Right now configuration in JBoss is done with static snippets that describe the setter basically. Cycling was difficult. Your stuff enables setting references on MBeans which is pretty cool. It seems that if you do component only inside then the advantage about doing it through your scripting language is missed. I think it is really powerful for external references. |Another problem is sometimes you may need to be a little more procedural |than just a straight set. For example in the Jetty demo config, we call |getServletHandler in order to set some specific attribute on it: | | Call name=addContext | Arg//Arg | Set name=ClassPathSystemProperty name=jetty.home |default=.//servlets//Set | Set name=DynamicServletPathSpec/servlet/*/Set | Get name=ServletHandler | Set name=ServeDynamicSystemServlets type=booleanFALSE/Set | /Get | | | |OK - looking at the above, it is all pretty incoherent and I don't |expect anybody |to understand it.Unless you know Jetty. So I will try from a |different angle. |I have found it very valuable in another project to have a JMX |configuration |agent that work very similar to the one I've assumed in JBoss, but slightly |more powerful. It supports Set, Get, Call and New tags to be run like a |script to configure newly registered JMX objects. | -- 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 and Rabbit Hole
Julian Gosnell wrote: However, initially, Jetty still expects files, which are best arranged in a hierarchy and assosciated with Jetty. Any thoughts It should not be too much work to do away with the Jetty config files all together and configure Jetty entirely via JMX. For the cisco deployment, this is exactly what they do and they have a JMX configuration architecture not unlike JBosses. The main difference is that: + The lifecycle methods are not expected. (ie don't have to have a start(); + Arbitrary methods can be called as well as attributes set. So I think the aim of the integration, should be to remove all trace of the jetty configuration mechanism from a standard jboss/jetty installation. This may be simple? As jetty configuration for most purposes can be reduced to a series of JMX sets followed by a call to start(). My vague understanding of the jboss config architecture is that this should be supported. However they may be more complex configurations that require arbitrary methods to be called on the jetty mbeans. These will have to be addressed either by changing the jetty mbeans so everything can be done as sets, then start() - or improving the jboss mechanism so that more arbitrary jmx calls can be made. Again for the cisco deployment, I used a config file format very similar to that of Jetty's XML - but which was able to call arbitrary JMX methods. 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
Re: [JBoss-dev] Jetty and Rabbit Hole
jmxname=com.mortbay.jetty:name=Jetty,Server=0,SocketListener=0 Set name=portSystemProperty name=application.portno default=8080//Set Set name=minThreads5/Set Set name=maxThreads255/Set Set name=maxIdleTimeMs6/Set Set name=maxReadTimeMs6/Set /Configure Configure jmxname=com.mortbay.jetty:name=Jetty,Server=0,WriterLogSink=0 Set name=filenameSystemProperty name=application.log default=./logs//_mm_dd.request.log/Set Set name=retainDays90/Set Set name=appendtrue/Set /Configure But this second style of config assumes that the config agent has triggered and configured the SocketListener and WriterLogSink during the configuration of HttpServer - thus they will be configured before the start call on the HttpServer I guess the point that I am trying to make is that some components such as Listeners and log sinks can very easily be configured with a sequence of sets. But something as complex as a HTTP server and servlet container, needs a little more than a sequence of sets. So either you config agent needs to support Set, Call, New tags!Or something else must coordinate the creation of all the component MBeans that can be configured with just a simple sequence of Sets ~(but who calls start() would still be a problem). MMm I don't think this describes what I'm talking about much better? So if you are confused - it is my fault. I'll try to have more of a look at the JBoss stuff and make my suggestions using your XML as examples rather than mine. marc fleury wrote: |It should not be too much work to do away with the Jetty config files |all together and configure Jetty entirely via JMX. remember that what we are aiming for is filesystem independence. The fact that the configuration is in a file with XML is not the problem it is the fact that it is expected from a filesystem file that is problematic. JBoss loads its own configuration with jboss-services.xml (ex.jboss.jcml) and then bit by bit through XML snippets but the vehicle that delivers them to the main system is not important. Right now we use URL to create Element to pass to the core. The core is fed Elements where those elements come from today are URLs (file or http). JMX is the core that applies the changes how these changes get there is through URLClassLoaders. |For the cisco deployment, this is exactly what they do and they have |a JMX configuration architecture not unlike JBosses. The main difference |is that: | | + The lifecycle methods are not expected. (ie don't have to have a | start(); That's bad :( | + Arbitrary methods can be called as well as attributes set. Ok that I am interested in seeing, is that your scripting language? the XML semantic that recreates invocation? |So I think the aim of the integration, should be to remove all trace of |the jetty configuration mechanism from a standard jboss/jetty installation. The best would be to deliver that configuration either as part of sar that julian was talking about and we provide a way for you to find a fileSystem file (simplest is a file at teh top of the hierarchy that you look for) or even better URL based. |This may be simple? As jetty configuration for most purposes can be |reduced to a series of JMX sets followed by a call to start(). My That would nicely map to the ELement parser that is in there. |However they may be more complex configurations that require arbitrary |methods to be called on the jetty mbeans. These will have to be arbitrary methods called sounds strange. Give me an example of that. Do you mean something like the dynamic MBeans? |addressed either by changing the jetty mbeans so everything can be |done as sets, then start() - or improving the jboss mechanism so that |more arbitrary jmx calls can be made. be more precise, this doesn't tell me much, there are predefined MBeans (standard) and dynamic MBeans. We support standard MBeans right now, we could proxy the calls to invoke as well. |Again for the cisco deployment, I used a config file format very similar |to that of Jetty's XML - but which was able to call arbitrary JMX methods. If you are talking about your scripting language, I think it might be very interesting as we build more evolved frameworks for management. But I am curious to see what kind of scenarios you are talking about that require these files. marcf -- 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] Re: [jetty-discuss] Re: Persistant HttpSession
Guys, I think it is valuable to consider many different implementations of session - even bad ones, so we get a good flexible session manager implementation. Remember that when we look at session persistance and session distribution mechanism - lots of class loader issues will start cropping up. So even if a EJB based persistent session proves to be horribly inefficient - it would be a good test of the session classloading to share the classloader of JBoss etc. But when it comes to production quality session management - I don't think we want to invent the whole wheel ourselves and we should build on the work of others. A few other things of note here - so we get the abstract model of a session manager right - we should have a good look at other containers. Gnu-paperclips for one is working towards pluggable session managers and I have talked to them before about sharing session managers between jetty and paperclips. So it would be good if we had a very very similar API so we could just borrow (and donate) session managers. Thus it would be worthwhile for folks to have a look at what they have done. Secondly, the 2.3 servlet API has lots of session lefecycle and event support in it. So when we abstract the session manager - we should build in support for those lifecycles. Thus a quick read of the 2.3 servlet spec is in order. I'm a little head down bum up at the moment to think about all this in detail. What I plan is to concentrate on getting a 3.1.0 out in the next week or two. Then immediately start a 3.2.A0 stream in which we can break out the session manager and start playing with this stuff. 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
Re: [JBoss-dev] Nested JMX Service Groups...??!
Hi all,
I'm the author of the Jetty MBeans, so I may be able to explain
them a bit more.
Jetty is used in several different JXM frameworks, of which JBoss is
only one of them.
JMX is meant to be a extensible managment framework, so you should not
try to constrain the number or type of MBeans that register. If you
don't know what they are - some other agent or MBean may! In the
case of JBoss, the extra Jetty MBeans can be examined via the
HtmlAdaptor agent and the Jetty configuration browsed and/or changed.
While observing registrations of MBeans and taking actions as a
result is a common JMX pattern, you have to be careful that your
agent knows that it is OK to call a method. Firstly you need
to check that the method exists. Really you should check
that the object is of the type you think it is - just because
it has an init method does not mean that it implements the
JBoss lifecycle,
In an other JMX framework that Jetty is used in, either the
object name or the object class is checked against a XML
configuration file before any on-registration actions are taken.
JBoss must be able to be deployed in any JMX framework, so
it cannot make assumptions that it is the only game in town.
Note that Jetty uses Model MBeans rather than StandardMBeans
so that additional meta information may be includeded about the
methods and attributes. You will see that when viewing the
Jetty MBeans in the HtmlAdaptor agent, the pop up text contains
real information that it taken from a resource bundle in Jetty.
cheers
Julian Gosnell wrote:
I'm getting the stacktrace because I'm catching an
Error and printing it out in my code.
I cannot add the lifecycle methods to every MBean
because they are 3rd party, created dynamically and
not under my control.
I don't think it is enough to simply ignore these
Errors. The fact that JettyMBeans do not implement
init() is a direct result of their ignorance of the
JBossService lifecycle. They _DO_ have
start()/stop()/destroy(), but these are part of a
Jetty lifecycle and not intended for use by JBoss. If
JBoss calls lifecycle methods on MBeans that are
created, owned and managed internally by Jetty the
results would not be good.
We should be considering how a number of MBeans can
register with the JBoss MBeanServer, some of which
indicate that they wish their lifecycle managed by
JBoss, and some of which (the default) don't
Jules
--- David Jencks [EMAIL PROTECTED] wrote:
Hi,
Well, it looks to me like he has thrown the
NoSuchMethodException himself
in his ModelMBeanImpl. This exception dexcends from
Exception, thus is not
a reflection exception, and isn't caught by any of
the exception
handlers/ignorers.
I don't yet understand what ModelMBeans are for...
but if he changed the
missing method handling to match that of line 1620
of the MBeanServerImpl,
the problems might go away.
Further posts from Scott Stark and Marc Fleury make
me think this may be
difficult to impossible. If so, we could instead
change ServiceControl to
ignore MethodNotFoundExceptions as well as
ReflectionExceptions. e.g.
around line 67
} catch (ReflectionException e)
{
// Not a service - ok
}
catch (NoSuchMethodException e) {
//Not a service - also ok
} catch (RuntimeMBeanException e)
Personally I am inclined to suggest putting empty
methods for the
nonexistent operations in every mbean. I don't
entirely understand why
this isn't in the mbean spec.
David Jencks
On 2001.04.10 21:12:52 -0400 [EMAIL PROTECTED]
wrote:
Hey,
There shouldn't even be a log msg about the
missing method since if you
invoke a
method that does not exist on an MBean you will
get a
ReflectionException and
these are simply ignored. All MBeans show up on
the management page
because
this page is about MBeans and cares nothing
about service abstractions.
Scott, that is what I thought too. But how is he
getting this
stacktrace:
[Jetty]
java.lang.NoSuchMethodException: init()
at
com.mortbay.Jetty.JMX.ModelMBeanImpl.invoke(ModelMBeanImpl.java)
at
com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
at
com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at
org.jboss.util.ServiceControl.init(ServiceControl.java:59)
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.init(Main.java:202)
at org.jboss.Main$1.run(Main.java:107)
at
java.security.AccessController.doPrivileged(Native
Method)
at org.jboss.Main.main(Main.java:103)
___
Jboss-development mailing list
[EMAIL PROTECTED]
