Alan,
The patches I have are against Jetty HEAD. But the problem is that the
rsync that Jason setup to update ibiblio is not working at the moment, so
Jetty-SNAPSHOT is not current.
As soon as that is fixed, I will apply my patches.
Until that time, you can build Jetty yourself or get the latest
I'm adding www.mortbay.org/maven as a repository and have put a new
5.1.G0 version there. Commit coming shortly.
cheers
Greg Wilkins wrote:
Alan,
The patches I have are against Jetty HEAD. But the problem is that the
rsync that Jason setup to update ibiblio is not working at the moment, so
Jetty
David Jencks wrote:
Well, not a lot, since I haven't figured out how servlets are deployed
in jetty. What I imagine is parsing web.xml, constructing a gbean for
each servlet, and registering it somehow with the webapp gbean or the
jetty container. Unfortunately on my last venture into jetty
+0
I have not played with the release - but I would like it to exist as
a basis of getting back onto the jetty 6 port.
cheers
+1
while I have some quibbles with the process it is much better to
have an agred well defined process than it is to have a constant debate
about a perfect one.
I think the wiki should clarify the patch process for release branches.
Personally I think that there are two processes:
New
All,
Jeff, Bill and I had done a lot of work trying to re-enter and check the 2.5
servlet specs
(see http://issues.apache.org/jira/browse/GERONIMO-1686).
However, dispite these efforts, these specs lack javadoc and jsp, plus they are
a little
out of date. The javadoc is a very important
[EMAIL PROTECTED] wrote:
#1 works for me.
Thanks,
Aaron
On 6/28/06, Greg Wilkins
[EMAIL PROTECTED] wrote:
All,
Jeff, Bill and I had done a lot of work trying to re-enter and check
the 2.5 servlet specs
(see http://issues.apache.org/jira/browse/GERONIMO-1686).
However
Alan D. Cabrera wrote:
Has anyone broached the subject w/ them?
I think this would be a good conversation to have but considering that they
don't even push tomcat 5 to any m2 repositories (at least not recent versions)
then I think it would be a long conversation.
I would like to move on
Jeff,
this suggestion is probably too late
but given the deficiencies of dialin, would it be possible for you to post a
short
summary of where your work with clustering is at?
Is there a page on the(a?) wiki about the approach you are taking?
I can see the tomcat clustering page
All,
I am going to give my own short report on the meeting. I'm not
intending to decent from Jules report - simply to give a short version
that highlights the important issues (for me).
We covered lots of clustering requirements and issues - made us all
realize how big and challenging a
Susan,
I am -0 on companies being included in the press release.
There are many companies associated with G, but I think that we should
not make this a marketting exercise for them.
But IF we are going to list companies then I would like Mort Bay listed
http://www.mortbay.com as the company
All,
Here are my comments on the Session API that were promised after apachecon
dublin.
This is also CC'd to the wadi list and some of the points are relevant to them
as well.
My own reason for focusing on the Session API when I think about clustering,
is that I like the idea of pluggable
Jules Gosnell wrote:
I pressed 'send' without counting to 10 first on the last response. Sorry.
No probs - no offence taken.
I've obviously done a bad job of explaining myself so far. Is this
clearer ?
Actually no - I preferred the slightly pissed off version for clarity :-)
I actually
This is my idea of how we could morph the currently proposed session APIs
into a cluster API.
I have created a spot for Cluster meta data - but I have not filled it out much.
The key difference is that the state Map is now indexed by session ID and
context ID.
This allows the state for
Filip,
sorry - but I missed this post before I sent my own API suggestion.
However, I think the good news is that your API view is very much
the same as my API view
We both start at Cluster and can discover meta data about Nodes.
Your Cluster provides a channel/message mechanism that I
Dain Sundstrom wrote:
I think we are starting to agree.
agreed :-)
I think that a Cluster interface with the stateless methods as proposed by
filip would be
good, plus a SessionManager interface with the stateful stuff.
Actually, I don't like SessionManager as a name... maybe StateManager?
Dain Sundstrom wrote:
On Jul 14, 2006, at 1:47 AM, Greg Wilkins wrote:
This is my idea of how we could morph the currently proposed session APIs
into a cluster API.
I have created a spot for Cluster meta data - but I have not filled it
out much.
The key difference is that the state Map
+1
this is just like big brother! voting projects out of the haus :-)
[EMAIL PROTECTED] wrote:
The current PMCs of both ActiveMQ and ServiceMix have overwhelmingly
voted to become Geronimo sub-projects.
The incubator proposals are here...
Joe Bohn wrote:
That's correct. In fact, at the moment I'm just trying to get a more
generic management implementation of the container stats in the style of
the JSR77 stats ... but I'm not really looking for the JSR77 servlet
stats right now. You mentioned in another note that you were
David Jencks wrote:
When I wrote the jetty deployer I studied the spec and could not find
any support for this kind of dynamic servlet that isn't listed in
web.xml, so I didn't try to put any in. If someone has a good argument
that it is consistent with the spec (I thought it was not), we
-0
As I have often said, in the long run the user should not care if they
are using jetty or tomcat and it was a mistake for us to expose
implementation detail as we have.
I have always preferred the web tier to be just called web
and then in future the developers will have the option to
Aaron Mulder wrote:
Well... is it possible to make this not specific to WADI? Perhaps
make it a generic clustering manager tag, and is just so happens
that the only classes we let you configure so far are the WADI ones?
Ideally, we'd put some generic interface in the Geronimo space, and
Sorry guys but
-1
I've just had a report of a security issue in Jetty that reveals the
contents of WEB-INF on win32 platforms.Happy f*#ing new year!
I have a fix and will be making a release very shortly. To avoid any
other issues, I will probably roll back the other changes in HEAD so
this afternoon (about 1500 PT).
Matt
Greg Wilkins wrote:
Sorry guys but
-1
I've just had a report of a security issue in Jetty that reveals the
contents of WEB-INF on win32 platforms.Happy f*#ing new year!
I have a fix and will be making a release very shortly. To avoid any
other
Even if we don't think about 2.0, there are two main ways in which we can
handle a stable
branch in source control:
1) We can have a 1.0 branch and as new features and bug fixes are tried and
tested
in the dev area(s), then these patches are moved to the 1.0 branch as patch
sets via
some QA
David,
I do not believe that the servlet spec well defines the behaviour of the
getUserPrincipal() method for un-secured resources.
I raised this with the EG during the 2.4 process and pointed out that
several containers implemented this differently. Specifically I wanted
to know that if
will track the
login state/credentials in a session, as suggested by the servlet spec
(also section 12.10).
Cheers, Jeppe
Greg Wilkins wrote:
David,
I do not believe that the servlet spec well defines the behaviour of
the getUserPrincipal() method for un-secured resources.
I raised
Alan D. Cabrera wrote:
It's my understading that we're going for JEE 5. I think that our
re-arch of security should go into that as well.
How do we want to stage this effort in terms of SVN organization? When
should we cut a 2.0 development branch?
Did we decide anything here?
Where/How
Jeff Genender wrote:
I am sorry Jules, I am -1 on the change and I stand firm on that.
Jeff,
I don't understand your total -1, nor the fact that you actually backed
out the change before anybody could reply to your email.
I sat in the room with Jules and Jan for three days while they worked
Jeff,
Can you please calm down? I'm trying to discuss your concerns, but
you appear to be taking offence that I'm doing so?
These are not my changes - I'm just an interested observer on this one
trying to interpret the arguments that have been put forward!
Greg, based on the fact that I
David,
I agree that it is not confusing to allow a plan to override context
path in application.xml
Generally speaking, I think it is valuable to have override mechanisms
for much of the configuration in the deployment bundles. This
goes for context path in application.xml and things like init
Jules Gosnell wrote:
I suggest -
Jan, Greg and I conceded that Jeff could have been more involved in
discussion before this change went in.
+1
We all agree to overlook all current technical differences.
I don't think overlook is the right word. Continue discussing
would be better. See
Matt Hogstrom wrote:
First, I see there is a structure for versioning like:
v.r.m[.f] where:
v = Version
r = Release
m = modification
f = fix (optional)
Another minor point - these names are a bit unwieldy and it is
difficult to say:
1.0 is the version of a Version release.
1.0.1
Matt,
good initiative!
I would like to see the philosophy include a bit of process about how
a version is create.
For example a believe a fix release should definitely be created by
the application of a few carefully QA'd patches to an existing released
branch of the code.
More over, I would
I would like to create a dev branch to start working on some
1.1 and 2.0 stuff.
But I don't think it is appropriate to pollute /branch with
private branches as it will be good to be able to go there and see
all the official branches:
/branch/1.0
/branch/1.1
without seeing
oliver karow wrote:
I played arround with geronimo 1.0 / Jetty 5.1.9 on Windows platform and
found two vulnerabilities:
thanks.
I've created http://issues.apache.org/jira/browse/GERONIMO-1474
cheers
lichtner wrote:
Were you thinking of doing it for every single change request, or only for
big ones?
I don't think it is needed for every single change request.
Anything that is destined for the next release can be done in
trunk.
But a good place for dev branches would be great for anything
David Jencks wrote:
On Jan 16, 2006, at 12:39 PM, Jeff Genender wrote:
I don't agree here. According to the Tomcat doc, the Host name is
Network name of this virtual host, as registered in your Domain Name
Service server. So it is a virtual host name. Where I think where the
code can
Jeff Genender wrote:
Aaron Mulder wrote:
All right, hang on.
Let's say you have App A that wants virtual hosts 1, 2, and 3 and App
B that wants virtual hosts 2, 3, and 4.
Tomcat can have Host123 listening on 1, 2, and 3 and Host234 listening
on 2, 3, and 4, and App A bound to Host123 and
Jeff Genender wrote:
I don't really see the disconnect between what you are saying,
there isn't - we are in strenuous agreement :-)
Aaron Mulder wrote:
It would be saying something like, there must be a
GBean to represent a virtual host, and that GBean must have a set of
host names associated with it, and any application can be associated
with that defined virtual host. For Tomcat, this would be
effectively a HostGBean
I still have some concerns about lack of technical and
administrative mechanisms and conventions for subprojects
within geronimo.But I'm sure they will all work out
and there is nothing like having code to crystalize thought:
+1
+1
I disagree that all contributions must go via the incubator. This is
clearly within the scope of servicemix and there is no need to
develope a community around this code.
cheers
Responding to this a bit late
I like the concept of a Session API that can hide
all the variations of session implementations from the web container.
Instead of having different session managers for the different
clustering mechanisms, I'd like to have one session manager
written to this
Dain Sundstrom wrote:
Wow, this is a lot to digest. I'll attempt, but we may want to deal
with these one by one...
Sorry about the length, but I'll try narrow this response
+ Does session ID x exist for context y
In this case, I would say you lookup the session x and then see if
Dain Sundstrom wrote:
Policy
==
So firstly we need SessionLocatoin.moveto(Server server),
I'm confused. Why would we need that?
There is an API to pull a session to a local node, but there
is no API to push a session to a specific node.
The use-case for the later if you have a load
All,
I'm tuning back into G after zoning out for a while
I'd like to started work on the jetty6 integration to
provide servlet 2.5
The goals of the jetty 6 integration will be:
+ 2.5 servlet API.
+ annotation support
+ Simplify integration using Jetty 6 interceptor friendly
Dain Sundstrom wrote:
Object value = session.getState(web:/context- + name);
Ok I get it now.
Don't have a deep - hard to replicate - structure.
Have a flat structure, but with a scoped name space!
I think this approach solves a lot of issues and probably
reduces the need for extra
Dain Sundstrom wrote:
My guess is we're going to need to add an event notification system to
the Session APIs. What do you think about just crib off of the servlet
ones. I think we could just smash the three session listener
interfaces into something like this:
public interface
Dain Sundstrom wrote:
My guess is we're going to need to add an event notification system to
the Session APIs. What do you think about just crib off of the servlet
ones. I think we could just smash the three session listener
interfaces into something like this:
public interface
James Strachan wrote:
I think a moveTo will also be useful for implementing shutdown
policies, where you want to gently take a node out of a cluster.
The policy should be able to be written independently of impl.
I don't think the non-web world needs it that much as there typically
Filip Hanik - Dev Lists wrote:
gentlemen, not a committer here, but wanted to share some thoughts.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
James Strachan wrote:
The Web tier is much more complex from a session perspective for all
the reasons you highlight - so am wondering if it'd be worth coming up
with a slightly different 'WebSession' API that has all the stuff you
need to wire it into Jetty (and ditto for Tomcat). Then we
.
cheers
I'll be submitting a patch early next week that has both of these api
projects.
Sorry for not entering a jira issue on it earlier
http://issues.apache.org/jira/browse/GERONIMO-1686
TTFN,
Bill Dudney
MyFaces - myfaces.apache.org
On Mar 2, 2006, at 12:55 AM, Greg
the appropriate scope for the release, but will be resolving this).
--kevan
On 8/23/05, *Greg Wilkins* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Kevan,
I'm just checking in a version that uses commons logging 1.0.4 and
we are now calling release on the context
it and it is
definitely one I should pay attention to.
I'm applying it now.
cheers
--
Greg Wilkins[EMAIL PROTECTED] US: +1 3104915462 IT: +39 3349267680
http://www.webtide.com UK: +44(0)2079932589 AU: +61(0)417786631
Hi,
I was trying to tidy up the Ajax code so that consumers closed when
sessions timeout (or long polls stop coming). But the queueConsumer
map in WebClient is static and key only by destination, which means:
+ You can only have one consumer per queue.I can imagine Ajax
apps that want
.
For the non-shared consumer, my current patch will close an idle
consumer that is not being long-polled anymore. Does a close
return any prefetched messages to the queue?
cheers
James Strachan wrote:
On 3/24/06, Greg Wilkins [EMAIL PROTECTED] wrote:
Hi,
I was trying to tidy up the Ajax
Just a heads up that I'd like to check in a refactor of the activemq-web
module.
Firstly, I've split it into activemq-web (a jar) and activemq-web-demo (a war).
I've made the jar dependent on the jetty-util.jar which is the portable
version of continuations and should work in other containers
[ http://issues.apache.org/jira/browse/GERONIMO-488?page=history ]
Greg Wilkins reassigned GERONIMO-488:
-
Assign To: Greg Wilkins (was: David Jencks)
jetty dispatch handling doesn't set component context, tx, or security
properly in geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-510?page=history ]
Greg Wilkins reassigned GERONIMO-510:
-
Assign To: Greg Wilkins
Jetty should use Geronimo thread pools
--
Key: GERONIMO-510
[ http://issues.apache.org/jira/browse/GERONIMO-488?page=history ]
Greg Wilkins reassigned GERONIMO-488:
-
Assign To: David Jencks (was: Greg Wilkins)
oops wrong issue
jetty dispatch handling doesn't set component context, tx, or security
[ http://issues.apache.org/jira/browse/GERONIMO-569?page=history ]
Greg Wilkins reassigned GERONIMO-569:
-
Assign To: Greg Wilkins
StackOverflowError when sending error page
--
Key: GERONIMO-569
[ http://issues.apache.org/jira/browse/GERONIMO-395?page=history ]
Greg Wilkins reassigned GERONIMO-395:
-
Assign To: Greg Wilkins
Error for /blojsom/: java.lang.StackOverflowError
-
Key
[
http://issues.apache.org/jira/browse/GERONIMO-569?page=comments#action_58912 ]
Greg Wilkins commented on GERONIMO-569:
---
The problem was a bug in jetty where the JSR154 filter was hiding the type of
the
dispatch.
This has been resolved
[
http://issues.apache.org/jira/browse/GERONIMO-395?page=comments#action_58913 ]
Greg Wilkins commented on GERONIMO-395:
---
This patch is not the correct approach, as it will violate the TCK.
The actual problem was due to a bug in jetty where
[ http://issues.apache.org/jira/browse/GERONIMO-1686?page=all ]
Greg Wilkins updated GERONIMO-1686:
---
Attachment: geronimo-spec-servlet-2.5.patch
This patch adds jetty version of the javax.servlet API to the main geronimo
spec repo.
While much work
[
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12370415
]
Greg Wilkins commented on GERONIMO-1686:
I've done some comparisons of the javax.servlet classes from geronimo to those
in jetty6.
The Jetty 6 classes
[
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12370491
]
Greg Wilkins commented on GERONIMO-1686:
javax/servlet/SingleThreadedModel.java should be
javax/servlet/SingleThreadModel.java
Servlet 2.5 and JSP 2.1 api
[
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12370806
]
Greg Wilkins commented on GERONIMO-1686:
Note that the jasper folks have already done the JSP API:
http://svn.apache.org/repos/asf/tomcat/jasper/tc6.0.x/src
[
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12370808
]
Greg Wilkins commented on GERONIMO-1686:
* GenericServlet calls super() when it does not need to.
More specifics would be good here. I've changed the code
[
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12370810
]
Greg Wilkins commented on GERONIMO-1686:
Mmmm having hassles applying patch with or without the -E
I'm ending up with two copies of each class in every java file
[
http://issues.apache.org/jira/browse/GERONIMO-510?page=comments#action_12357900
]
Greg Wilkins commented on GERONIMO-510:
---
In jetty 6, threadpools are easily plugable, so as soon as 1.0 is out the door
I'll work on a port to Jetty 6
Jetty connector missing many optional configurations
Key: GERONIMO-1338
URL: http://issues.apache.org/jira/browse/GERONIMO-1338
Project: Geronimo
Type: Improvement
Components: web
Reporter: Greg Wilkins
[ http://issues.apache.org/jira/browse/GERONIMO-1338?page=all ]
Greg Wilkins reassigned GERONIMO-1338:
--
Assign To: Greg Wilkins
Jetty connector missing many optional configurations
[
http://issues.apache.org/jira/browse/GERONIMO-1338?page=comments#action_12360230
]
Greg Wilkins commented on GERONIMO-1338:
added maxIdleTime, lowThreads and lowThreadsMaxIdleTime for the 1.0 release.
Will do full review after 1.0
Jetty
Reporter: Greg Wilkins
Assigned to: Greg Wilkins
Priority: Critical
Fix For: 1.x, 1.0.1
The 5.1.9 Jetty server used by geronimo 1.0 suffers from a security
vulnerability that allows a crafted URL to access the contents of WEB-INF when
the server is run on windows platforms. The 5.1.10
[ http://issues.apache.org/jira/browse/GERONIMO-1433?page=all ]
Greg Wilkins updated GERONIMO-1433:
---
Component: web
Security vulnerability of WEB-INF contents on windows platforms
.
Reporter: Greg Wilkins
Assigned to: Greg Wilkins
Fix For: 1.1
It is highly desirable that the HTTP connectors can be made dependent on the
correct startup of one or more webapplications. This is to prevent a server
with failed webapps to join a cluster, or for
it a server to join
Cross site scripting vulnerabilites
---
Key: GERONIMO-1474
URL: http://issues.apache.org/jira/browse/GERONIMO-1474
Project: Geronimo
Type: Bug
Components: console
Versions: 1.0
Reporter: Greg Wilkins
Fix
[ http://issues.apache.org/jira/browse/GERONIMO-2654?page=all ]
Greg Wilkins reassigned GERONIMO-2654:
--
Assignee: Greg Wilkins
Enabling Welcome App (context /) on geronimo-jetty6-jee5 assembly breaks
web-console (context /console
[
http://issues.apache.org/jira/browse/GERONIMO-2654?page=comments#action_12458278
]
Greg Wilkins commented on GERONIMO-2654:
The JettyContainImpl class is adding contexts to the server object.
It should instead add them
[
http://issues.apache.org/jira/browse/GERONIMO-2654?page=comments#action_12458646
]
Greg Wilkins commented on GERONIMO-2654:
I think I have found the problem.
The contextHandlerCollection is not correctly linked in. showing
[
http://issues.apache.org/jira/browse/GERONIMO-2654?page=comments#action_12458652
]
Greg Wilkins commented on GERONIMO-2654:
David,
I think the problem was that the hierarchy of handlerCollection to
contextHandlerCollection
[
http://issues.apache.org/jira/browse/GERONIMO-2654?page=comments#action_12458655
]
Greg Wilkins commented on GERONIMO-2654:
Oh - I see you also fixed the handler hierarchy.
I have just taken out the setServer calls and the 4 standard
[
http://issues.apache.org/jira/browse/GERONIMO-2654?page=comments#action_12458661
]
Greg Wilkins commented on GERONIMO-2654:
The 500 responses in the tests are because the ContextHandlerCollection sends a
500 if it has not contexts
[
https://issues.apache.org/activemq/browse/AMQ-884?page=comments#action_36837 ]
Greg Wilkins commented on AMQ-884:
--
This is a good idea. I will apply patch, test and commit soon
Ajax should support non-XML messages
[
http://issues.apache.org/jira/browse/GERONIMO-2163?page=comments#action_12432125
]
Greg Wilkins commented on GERONIMO-2163:
David,
when applying v6b I get an error:
patch: malformed patch at line 939: /module
Looking
[ http://issues.apache.org/jira/browse/GERONIMO-2163?page=all ]
Greg Wilkins updated GERONIMO-2163:
---
Attachment: GERONIMO-2163-v6c.patch
This is just an update to v6b so that it applies to r439349
WADI Integration for Jetty
[
http://issues.apache.org/jira/browse/GERONIMO-2163?page=comments#action_12434675
]
Greg Wilkins commented on GERONIMO-2163:
Jan and I went over the patch today and we are generally pleased with it.
I like the architecture
[
http://issues.apache.org/jira/browse/GERONIMO-2163?page=comments#action_12434824
]
Greg Wilkins commented on GERONIMO-2163:
Definitely a +1 from me.
WADI Integration for Jetty
--
Key
[
https://issues.apache.org/jira/browse/GERONIMO-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482062
]
Greg Wilkins commented on GERONIMO-2982:
I have not found the reference for this... but I recall
[
https://issues.apache.org/jira/browse/GERONIMO-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517795
]
Greg Wilkins commented on GERONIMO-1686:
Jetty has switched to directly using the source checked out from
[
https://issues.apache.org/jira/browse/GERONIMO-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Wilkins closed GERONIMO-1686.
--
Resolution: Fixed
changes appear to have been merged via other paths.
Servlet 2.5 and JSP
[ https://issues.apache.org/activemq/browse/AMQ-884?page=all ]
Greg Wilkins resolved AMQ-884.
--
Resolution: Fixed
Applied patch and tested against chat demo.
Also updated to jetty 6.0.0rc2
Ajax should support non-XML messages
95 matches
Mail list logo
