Re: RV-Predict bugs
I don’t understand your transformation. foo is certainly a class member. I
thought bar was a local variable, thus inaccessible to anything outside the
method and thread being executed. Your transformation makes them look like
they are the same kind of thing?
I’m also not quite sure where the “rematerialization” chuck mentions is
happening, although I don’t know what it is exactly. I’m also not seeing why
this transformation couldn’t be done by a JIT compiler rather than the cpu.
My uneducated mental model of the original is
int foo (memory)
load foo into register r1
if r1 == 0 {
write 42 into r1
store r1 to foo
}
load foo into register r2
return r2
so the optimizer thinks, hmm, lets do all the loads at once to increase the
chances that the cache won’t have to be reloaded…. flip a coin and pick r2 to
load first….. hmm, we might be changing the value so we’ll update r2 if we do.
int foo (memory)
load foo into register r2
load foo into register r1
if r1 == 0 {
write 42 into r1
// better update r2 also
copy r1 into r2
store r1 to foo
}
return r2
Is there some reason the JIT compiler can’t do this transformation? I don’t
see how in-processor optimizations apply nor do I see how LLVM rules apply. I
thought JIT behavior was only controlled by what the JLS said.
Still hoping to learn more…
david jencks
> On Sep 16, 2015, at 4:50 AM, Mark Thomas <ma...@apache.org> wrote:
>
> On 16/09/2015 06:38, David Jencks wrote:
>> At this point I tend to agree with Ylong and Jeremy. I’m very far
>> from being an expert but I thought 14.2 meant that the result of
>> execution of a single thread had to be the same as if it executed the
>> given instructions in the order supplied. I didn’t think it meant it
>> had to execute those particular instructions, I thought it could pick
>> whatever instructions it wanted as long as the result would be the
>> same as if the given instructions were executed in the given order.
>> If there’s only one thread, Jeremy’s transformed code obviously
>> produces the same result as the original. To me saying it ‘has
>> different logic” and “has a timing window” might be true but don’t
>> directly mean that if violates the ch. 14 semantics.
>>
>> Hoping to learn more….
>
> Same here. I'm finding this discussion extremely useful. I'm not trying
> to find reasons to dismiss or minimise the bugs reported by RV-Predict.
> You'll notice that, with one exception that I currently believe is a
> false positive, that all the bugs have been fixed. And if the basis for
> declaring that issue false positive is found to be faulty it will get
> fixed too.
>
> I am trying to better understand a) exactly what the issue is and b) how
> likely the issue is. That requires an understanding of both the theory
> (JLS/JMM) and how the theory is applied in practice to produce a JVM.
>
> To re-cap. The assertion is that
>
> ===
>
> String foo;
>
> doSomething() {
> if (foo == null) {
>foo = calculateNewValue();
> }
> return foo;
> }
>
> ===
>
> can be transformed (by the complier?) to
>
> ===
>
> String foo;
> String bar;
>
> doSomething() {
> bar = foo;
> if (foo == null) {
>foo = calculateNewValue();
>bar = foo;
> }
> return bar;
> }
>
> ===
>
> Ignoring re-ordering this transformation creates an obvious concurrency
> issue (foo is changed from null to non-null after its value is copied to
> bar and before foo is tested for null).
>
> The questions I have are:
>
> 1. Is such a transformation legal? I assume the answer is yes but I've
> been struggling to find the language in the JLS that permits this. Is it
> 17.4 "An implementation is free to produce any code it likes, as long as
> all resulting executions of a program produce a result that can be
> predicted by the memory model."?
>
> 2. Why would something make a transformation like this? This brings us
> back to the question of theoretical issues vs. practical issues which
> helps us judge the severity of any given issue.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: RV-Predict bugs
At this point I tend to agree with Ylong and Jeremy. I’m very far from being
an expert but I thought 14.2 meant that the result of execution of a single
thread had to be the same as if it executed the given instructions in the order
supplied. I didn’t think it meant it had to execute those particular
instructions, I thought it could pick whatever instructions it wanted as long
as the result would be the same as if the given instructions were executed in
the given order. If there’s only one thread, Jeremy’s transformed code
obviously produces the same result as the original. To me saying it ‘has
different logic” and “has a timing window” might be true but don’t directly
mean that if violates the ch. 14 semantics.
Hoping to learn more….
david jencks
> On Sep 15, 2015, at 9:58 PM, Yilong Li <yilong...@runtimeverification.com>
> wrote:
>
> Your argument seems to assume that reordering is the only code
> transformation that can be done by compiler or hardware. I don't agree that
> you call this transformation a red herring. It might not be practical but
> it's certainly valid. Does it violate the intra-thread semantics you
> mentioned in JLS Chaptor 14? No. Is it possible for the transformed method
> to return 0? Yes.
>
> Yilong
>
> On Tue, Sep 15, 2015 at 6:39 PM, Caldarale, Charles R <
> chuck.caldar...@unisys.com> wrote:
>
>>> From: David Jencks [mailto:david_jen...@yahoo.com.INVALID]
>>> Subject: Re: RV-Predict bugs
>>
>>> I have been having a hard time believing the reordering claims, but
>> finally I went to Jeremy's
>>> blog post. To recap, he says
>>
>>> if (hash == 0) {
>>> int h = //compute hash
>>> hash = h;
>>> }
>>> return hash;
>>
>>> can be reordered to
>>
>>> r1 = hash;
>>> if (hash == 0) {
>>> r1 = hash = // calculate hash
>>> }
>>> return r1;
>>
>>> Obviously this last version is susceptible to returning 0.
>>
>>> It looks to me like the 2nd version is not a reordering of the java
>> statements of the first version.
>>
>> Correct; it's different logic, and thus a bit of a red herring. It
>> introduces a timing window not present in the original code; it's not an
>> example of a speculative read.
>>
>> - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received this in error, please contact the sender and delete the e-mail and
>> its attachments from all computers.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: RV-Predict bugs
I have been having a hard time believing the reordering claims, but finally I
went to Jeremy’s blog post. To recap, he says
if (hash == 0) {
int h = //compute hash
hash = h;
}
return hash;
can be reordered to
r1 = hash;
if (hash == 0) {
r1 = hash = // calculate hash
}
return r1;
Obviously this last version is susceptible to returning 0.
It looks to me like the 2nd version is not a reordering of the java statements
of the first version. I conclude that you cannot reason about reordering based
on java, you have to look at reordering at the byte code level. I’m not that
familiar with the byte code but can easily believe that byte code for the 2nd
version is a reordering of byte code for the first version.
I’ve gotten pretty good at recognizing double checked locking and checking to
see if the variable is synchronized, but I have some doubts I’ll be able to
recognize patterns like this consistently. I think that the only practical way
to detect these is through analysis tooling, so I’m glad to see it exists.
thanks
david jencks
> On Sep 15, 2015, at 6:33 PM, Yilong Li <yilong...@runtimeverification.com>
> wrote:
>
> On Tue, Sep 15, 2015 at 3:09 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 15/09/2015 22:55, Yilong Li wrote:
>>
>>> Fine. Let's do your example:
>>> T2R4 (out of order read returns null)
>>> T1R1 (returns null)
>>> T1W2 (writes non-null value)
>>> T1R4 (reads new non-null value)
>>> T2R1 (reads new non-null value)
>>>
>>> First of all, when reasoning with JMM, you should not move T2R4 to the
>>> front. This is forbidden by the intra-thread semantics so I move it back
>> to
>>> the bottom:
>>> T1R1 (returns null)
>>> T1W2 (writes non-null value)
>>> T1R4 (reads new non-null value)
>>> T2R1 (reads new non-null value)
>>> T2R4 (out of order read returns null)
>>>
>>> Intra-thread semantics ensures the following HB order:
>>> T1R1 < T2W2 < T1R4
>>> T2R1 < T2R4
>>
>> I assume you mean:
>> T1R1 < T*1*W2 < T1R4
>> above
>>
>
> correct
>
>
>>
>>> T2R4 is allowed to read null because 1) T2R4 is not ordered before the
>>> write of null (let's call it INIT) by JVM during object initialization;
>> and
>>> 2) there is no intervening write w' such that INIT < w' < T2R4. You see,
>>> T1W2 is *not* an intervening write because there is no HB order between
>>> T1W2 & T2R4.
>>>
>>> Let me know if it is still not clear enough.
>>
>> Sorry, still not clear enough.
>>
>> I understand that the JMM allows this behaviour. I don't understand how
>> this could happen in a JVM implementation.
>>
>> If T2R1 has read a non-null value how could a T2R4, a read from the same
>> thread that happens at some later point in time, read a previous value
>> for the same field?
>>
>> That would imply that the two reads were implemented differently since
>> they would have to be looking at different memory locations. What is
>> going on here?
>>
>
> Please go back and check the compiler transformation I stole from Jeremy's
> article. That transformation actually introduces a new shared memory
> location (i.e., field r1). How likely is a compiler going to take advantage
> of such transformation? I don't know, probably very unlikely. But let me
> clarify something: I am not trying to prove that this is a very harmful
> data race in order to justify the importance/usefulness of RV-Predict from
> the beginning. It's on the your discretion whether you care more about the
> JLS or the JVM implementation. I am simply trying to explain two things: 1)
> this *is* a bug according to JMM and 2) there is a correct version that is
> at least as efficient as the original (buggy) one.
>
> Yilong
>
>
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
Re: apis @asf
My recollection of history (no doubt biased and inaccurate)…. Geronimo originally needed maven-accessible and plausibly maven-metadata'd jars, and tomcat was extremely maven-unfriendly at the time (and wasn't set up to easily consume maven artfiacts). I think we (geronimo) copied the first one (servlet 2.3??), and I think I recall adding the stuff for at least one of the later versions myself. Later on Geronimo needed osgi bundles… If there's any interest in trying to minimize the number of places spec api code is kept I still sort of like the idea of it all being in one place, maybe we could investigate something like giving any other-project committer with interest in working on a spec jar commit rights in geronimo. I don't think spec jar releases have ever been a big timing/delay problem. thanks david jencks On May 16, 2014, at 7:32 AM, Mark Thomas ma...@apache.org wrote: On 16/05/2014 07:59, Romain Manni-Bucau wrote: Hello guys, Hope I didnt miss a thread dealing with it, if so please just redirect me. Tomcat made the choice to do its own API jars. That's not a big deal by itself but wonder why not putting them with all EE api jars of Apache, ie in geronimo specs subproject: http://svn.apache.org/repos/asf/geronimo/specs/trunk/ I suspect it stems from the fact the Tomcat was originally the reference implementation for a number of those. It concerns mainly: * el * websocket * jsp * servlet Just to give you a bit more background, this question doesn't come from nowhere. In TomEE we use geronimo API for almost everything excepted some tomcat provided apis (servlet, jsp) until today. But since recent Tomcat 7 got - thanks to Tomcat 8 - a refactoring of EL part, geronimo-el and tomcat-el were no more compatible. In other words TomEE was broken cause AstValue was refactored and method matching more dedicated to BeanELResolver in tomcat but not in geronimo. Doesn't that simply mean that the refactoring in Tomcat has exposed a bug in the Geronimo EL API? Wonder if we should/can try to get something consistent accross ASF. Assuming that Geronimo is using the Tomcat implementations I wonder why the project felt the need to produce their own API JARs. Or are they just (old?) copies taken from Tomcat originally? wdyt? From experience with re-using components from Commons, Tomcat would almost certainly want to keep a local copy - even if that was an svn copy of some common version - else releases can start to experience noticeable delays waiting on a release of a dependency. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
Geronimo's xbean-finder also supplies this functionality using asm.
david jencks
On Jun 14, 2013, at 9:55 AM, sebb seb...@gmail.com wrote:
On 14 June 2013 17:35, Christopher Schultz ch...@christopherschultz.net
wrote:
Mark,
On 6/14/13 12:21 PM, Mark Thomas wrote:
On 14/06/2013 16:57, Christopher Schultz wrote:
Mark,
On 6/14/13 3:16 AM, Mark Thomas wrote:
On 14/06/2013 03:31, Christopher Schultz wrote:
It might be nice if this were not a one-of-many decision, but if a
client could choose more than one type. A bit-mask or a list of
scan-types would be nice. I could see the same type of scanner being
used for multiple different purposes.
That is what ServletContainerIniiializers are for.
Well, crap. I had never seen those before.
I'm curious, though. Thinking about this the other day with a colleague
who was complaining about some kind of Spring configuration that
evidently loaded every class available on the classpath and kept them in
memory (thus leading to heap and PermGen issues), I concluded that the
only sane way to do this kind of probing would be to probe everything in
a ClassLoader that was intended to be discarded after the probing as to
avoid loading classes unnecessarily.
If an SCI retains a reference to any of the Class objects in the
SetClass parameter, that hypothetical throw-away ClassLoader is no
longer thrown-away.
The early Tomcat 7 implementations did it like this - loaded every class
and then examined the class object. More recent implementations use BCEL
to look at the byte code. It is faster and uses less memory. We also use
caching to ensure each class is only processed once.
That functionality sounds like it might be useful as a general purpose
library item, possibly as part of a utility jar for Commons BCEL.
For example JMeter has to scan classes for certain interfaces on
startup. It's current implementation is a bit wasteful.
Cool. What Classloader gets used to actually load the Class objects,
though?
BCEL reads class files as files.
http://commons.apache.org/proper/commons-bcel/
In the pathological case of @HandlesType('java.lang.Object')
that means everything gets loaded into .. the WebappClassLoader?
One could imagine a case where an SCI wants to look at everything, but
then only ends up caring about 2% of what's been loaded. Is that just
the price you have to pay for inspecting everything -- that you
seriously waste PermGen? (at least for current Oracle JVMs)
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: security-role-ref and security constraints
On Apr 21, 2013, at 3:56 PM, Jeremy Boynes jboy...@apache.org wrote: On Apr 19, 2013, at 11:04 PM, David Jencks david_jen...@yahoo.com wrote: IMO you have misinterpreted roles in the ee specs. The specs including the servlet spec define application roles and base the declarative security constraints on them. Then you can map strings that bits of the application like, at least ejbs and servlets, to these declared security roles using a security-role-ref. The role-link has to be one of the declared application roles. For web apps the security-role-ref is defined on servlets. The application roles no matter where defined are scoped to the entire application not just one web app or web fragment. If a security-role-ref is not defined for a string, and you call isUserInRole with that string, the string is assumed to be a defined application role. Mark does bring up a gap here though. Before 3.0, the only reference to a role from code would be in the parameter value passed to isUserInRole(), and the assembler was responsible for listing all of those in web.xml; the deployer was responsible for linking them to actual roles in security-role elements, and then linking those to groups/principals in the authorization system in a container-specific manner. Declarative security (security-constraint/auth-constraint) did not require a linkage mechanism as the deployer could modify the value in the auth-constraint declaration in web.xml. With 3.0 annotations, however, the auth-constraint is now declared in code and the deployer has no mechanism to link its roleNames() to an actual role. Not quite following you here. I thought you'd declare all your roles using the @DeclareRoles annotation or in @AllowRoles inside constraints. These are equivalent to security-role elements in web.xml. If for some reason you don't like the role names in the annotations you can always override them in web.xml just like you can override other non-cdi annotations. Otherwise the deployer can link the principal names to the role names just like with web.xml. Option b) sounds like a potential solution but as you say that is not something the spec currently allows. The spec could be extended to allow this, and I think that would even be a compatible change given the existing requirement for security-role-ref to default to a security-role with the same name if no explicit link is specified. How is this different from the existing possibility to define a proprietary mapping between principal names and application role names? thanks david jencks There is a scoping issue for role ref names but that is not new - 2.x libraries can also conflict by using the same value in calls to isUserInRole(). Based on the JACC WebRoleRefPermission, where the constructor arguments are the servlet name and the role name, I've concluded that the a filter gets the same isUserInRole behavior as the servlet the request ends up at after going through the filter. I think this is a satisfactory solution, and it's passed quite a few ee tcks by now. It's also quite easy to implement :-). I think talking to Ron Monzilla if you disagree with it would be the way to go. As the spec stands with security-role-ref/@DeclareRoles only allowed on Servlets and not on Filters I'd come to the same conclusion. It is a weird coupling though as the role reference is made by the filter and not the servlet, the servlet author does not know a-priori what filters will be applied or vice versa. Again, more of an issue now we have annotation based config. IMO, getting the spec to clarify this, and potentially allowing filters to declare role references would be useful. I've assumed the same model would apply for calls to isUserInRole() from within listeners e.g. request or request attribute? Or from within an extension-mapped servlet like the JSP servlet? Then you presumably have an external security system such as ldap with some defined entities such as groups, and these usually get represented as Principals, perhaps in a Subject.. These are not application roles. You need to map the externally defined entities to the application roles. +1, although falling back to mapping application roles to groups in the absence of configuration by the deployer is temptingly convenient (although with the new-group problem you mention). ... On Apr 19, 2013, at 2:28 PM, Mark Thomas ma...@apache.org wrote: ... Tomcat's current behaviour looks to be specification compliant but there appears to me to be an issue here the the Servlet EG needs to address. Before I move this issue there what do folks think about this? Is there an issue or am I missing the obvious? Seems to me there's ambiguity there that would be worth clarifying. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
Re: security-role-ref and security constraints
Hi Mark, I hope my being tired doesn't come across as being unpleasant… if so I apologize in advance. I think a lot of the security discussion in the servlet spec is vague and misleading. I think the JACC spec provides a firmer basis for thinking about how security is supposed to work. IMO you have misinterpreted roles in the ee specs. The specs including the servlet spec define application roles and base the declarative security constraints on them. Then you can map strings that bits of the application like, at least ejbs and servlets, to these declared security roles using a security-role-ref. The role-link has to be one of the declared application roles. For web apps the security-role-ref is defined on servlets. The application roles no matter where defined are scoped to the entire application not just one web app or web fragment. If a security-role-ref is not defined for a string, and you call isUserInRole with that string, the string is assumed to be a defined application role. Based on the JACC WebRoleRefPermission, where the constructor arguments are the servlet name and the role name, I've concluded that the a filter gets the same isUserInRole behavior as the servlet the request ends up at after going through the filter. I think this is a satisfactory solution, and it's passed quite a few ee tcks by now. It's also quite easy to implement :-). I think talking to Ron Monzilla if you disagree with it would be the way to go. Then you presumably have an external security system such as ldap with some defined entities such as groups, and these usually get represented as Principals, perhaps in a Subject.. These are not application roles. You need to map the externally defined entities to the application roles. IIUC tomcat has chosen to only support mappings where the principal name equals the name of the application security role. IIRC the last time I looked many years ago tomcat did not verify that all the security roles used in security constraints or by isUserInRole calls were actually declared application roles. From my limited recollection of tomcat internals, I don't understand why tomcat doesn't verify that security roles that are used are declared, and why there isn't a more flexible mapping from e.g. groups to application roles. For your specific example admin and sysuser are distinct application roles available for use across the entire application and the problem is that there is no way in tomcat to map the hr-manager principal representing an ldap group to roles with different names. Your option (b) is IMO definitely and very clearly not spec compliant. I think (a) is correct, by providing a more flexible way to map between principals and application roles. I've always thought that even a default map between principals and roles using name equality was somewhat dangerous in the case that you don't want to assign any groups to a particular role. The ldap administrators could not know about the role and create a matching group and suddenly there are users in that role. A little googling to try to remind myself about security-role-refs turned up http://docs.oracle.com/javaee/5/tutorial/doc/bncav.html#bncax which indicates very clearly that Sun thinks groups are not roles and that you need a flexible mapping between them. (see the sun-web-app snippet at the bottom). thanks david jencks On Apr 19, 2013, at 2:28 PM, Mark Thomas ma...@apache.org wrote: Currently, Tomcat only checks against security-role-ref elements if there is a call to isUserInRole(). Prior to Servlet 3.0 this made sense. The person deploying the web application has control over web.xml and hence the security roles (those used in security constraints) but no control over application roles (those used by developers in Servlets with isUserInRole()) and therefore needed a mechanism to map the application roles to security roles. This mechanism is usually used to map application roles to security roles that exist in an external authentication and authorisation system such as an LDAP directory. For example, the application role admin in the HR application may get mapped to the hr-manager role that exists in the LDAP directory. With Servlet 3.0 plugability features the picture changes a little. Now a fragment may define security constraints that use a security role that does not match the organisations security roles and can't be modified in the application's web.xml. For example, an HR application with two fragments may define a role admin in fragment A and sysuser in fragment B both of which need to be mapped to the hr-manager role. Oh, and just to throw a spanner in the works, if a Filter uses isUserInRole() there is no way to map the application role to a security role. I'm currently unsure how this issue should be addressed. The options as I see them are: a) There is an obvious solution I have missed. b) Check security-role
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Umm, a few years ago I was quite interested in implementing it for tomcat, but couldn't raise any support over here. I still think the geronimo-tomcat-jaspic integration could be adapted to tomcat standalone pretty easily, although I don't think I'll have time to work on it. thanks david jencks On Feb 6, 2013, at 10:29 AM, Mark Thomas ma...@apache.org wrote: On 06/02/2013 15:45, Ron Monzillo wrote: I have posted the question to the TomEE and Caucho/Resin user's lists. It would also help to know what the level of interest is from Tomcat users and developers. For users@, yours is the first post ever to mention JASPIC. We'll see what reaction your post gets. For dev@, it is safe to say it is an itch no-one has wanted to scratch so far because it hasn't been implemented. User demand could change that but so far there hasn't been any. I anticipate that there are Tomcat users and developers who are committed to other approaches, but I'd like to make sure the use of JASPIC has been presented for consideration by the Tomcat community. It has been on our radar for well over 3 years. As I keep saying, so far no-one seems to be that interested in either using it or implementing it. I would also like to know if anyone has already done or is interested in doing the work to integrate the JASPIC profile in the Tomcat code base. I believe the Geronimo folks have had this implemented for a number of years. If JASPIC support was going to be added to Tomcat, that is probably where we'd start. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. To repeat.. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script underhttps://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19 david jencks On Dec 19, 2011, at 10:20 AM, Mladen Turk wrote: On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. Amount of work we invest in build.xml is negligible compared to the rest of the codebase, and I expect maven will provide such environment. If not, meaning we would need a couple of developers hacking pom's all the time, then a big -1. Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Thanks for your brevity, Mark On Dec 19, 2011, at 11:24 AM, Mark Thomas wrote: On 19/12/2011 18:47, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. I'm curious. What are the benefits of doing this over using the JARs that Tomcat already publishes to Maven central? Is there something wrong / missing with those JARs? If so, it can probably be fixed. Geronimo originally needed a way we could track to apply patches. I don't know that we have needed any patches recently, but we now need osgi bundles. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. How does building with Maven encourage interaction with other communities over and above the interaction we see via publishing the JARS to Maven central that we already publish? I generally wont work on projects that aren't maven based because the project layout and build system usually takes too long for me to understand to be worth it for the possible contribution I might make. Now that Geronimo has a mavenized tomcat, I can consider working on tomcat problems in the mavenized copy and if I think it's worth the trouble try to generate a patch against the original tomcat source. I think the standardization maven brings makes projects much more friendly to outsiders looking to contribute. thanks david jencks To repeat.. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script underhttps://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19 If we switch, I'm sure that that will be useful. What I have yet to see, is a good reason to switch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On Dec 19, 2011, at 1:06 PM, jean-frederic clere wrote: On 12/19/2011 07:47 PM, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. So starting with what is in the geronimo repo, how much work would it to have a mavenized Tomcat? I did this work and suggested tomcat look at it several years ago, and don't remember all the details, some other people have been maintaining it recently. IIRC the maven projects generate pretty much the same jars as the ant build, possibly plus one more to get around the circular dependencies among the jars. So to generate a maven multimodule project to build the jars, 20 min to configure the script that builds the project, then you have a mavenized tomcat project checked in that builds pretty much the same jars as the ant build. I don't really know what else the ant build generates. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. We already publish artifacs, do you need more of them? I think the benefit might be more on the order of encouraging people who ask where did this jar come from-- I wanna fix something. For people familiar with maven, there is IMO a much higher barrier to contributing to tomcat than a well-structured maven project. (BTW I must add that I'm delighted that the tomcat community seems much more receptive to outside input than it did several years ago -- community unfriendliness seems to be totally missing now :-) ). thanks david jencks Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
I'll try to keep it short because I really don't want to spend time re-beating this dead horse. The last time I looked a couple years ago the jars constructed out of the single source tree could not be compiled separately in any order. I was told this wasn't a problem, at which point I realized discussion was useless. Maven prevents problems like this through the project structure. If this situation is not a problem to the tomcat community, then the other possible benefits of using maven are not likely to be interesting either. thanks david jencks On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). In summary, I see a lot of differences but no benefits. Changing to Maven would mean big changes along with some disruption. For the community to make those changes and accept that disruption there needs to be something in return. So far, I haven't seen anything that I would class as a benefit to the community (e.g. faster build process, simpler releases, fewer bugs, etc.). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
I forgot to mention that geronimo has been re-releasing several versions of tomcat built with maven. We have a script to set up a maven multi module project structure and distribute the tomcat source code from tomcat svn into the maven projects. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19 thanks david jencks On Dec 17, 2011, at 1:12 PM, David Jencks wrote: I'll try to keep it short because I really don't want to spend time re-beating this dead horse. The last time I looked a couple years ago the jars constructed out of the single source tree could not be compiled separately in any order. I was told this wasn't a problem, at which point I realized discussion was useless. Maven prevents problems like this through the project structure. If this situation is not a problem to the tomcat community, then the other possible benefits of using maven are not likely to be interesting either. thanks david jencks On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). In summary, I see a lot of differences but no benefits. Changing to Maven would mean big changes along with some disruption. For the community to make those changes and accept that disruption there needs to be something in return. So far, I haven't seen anything that I would class as a benefit to the community (e.g. faster build process, simpler releases, fewer bugs, etc.). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing zips to the maven repo
On Oct 14, 2011, at 4:06 AM, Mark Thomas wrote: On 14/10/2011 09:15, Konstantin Kolinko wrote: 2011/10/14 David Blevins david.blev...@gmail.com: We've been using plain Tomcat zips for creating TomEE in the OpenEJB maven build for a while now. So far that has been done by publishing the Tomcat zips to a maven repo in svn. Not the best idea to have them in svn, so we're trying to get them in the actual maven repo. Can't maven be taught to download them from proper ASF mirrors? +1 There is already a world-wide distribution system in place for the file(s) concerned so it makes sense that it should be used. Adding the full .zip archive to any Maven repo just seems wrong to me (and using the ASF svn server for this is definitely a very bad idea) but if the folks managing the main Maven repo are happy with this then I have no objection. Since the requirements for this are driven by the OpenEJB project and - as far as I am aware - they are the only folks with this requirement, I suggest that OpenEJB runs with this and publishes the .zip to the main Maven repo under the OpenEJB group id. To ensure that no confusion is caused by this publishing I would ask that: - the zip published is an exact copy of that on the mirror system - the zip is not made available via Maven any earlier than it is available via the mirrors I really hope that just because the main tomcat developers don't see the benefits of the maven ecosystem they don't throw away this opportunity to make tomcat relate better to it and make life significantly easier for projects that are built using maven and use tomcat as an integration test prerequisite. I've seen quite a few projects where a lot of the build is not automated because you have to track down an appropriate tomcat distro, unpack it, start it, and tell the maven build where it is then you can run the build including the integration tests that use this tomcat server you installed by hand. It the distro were in the maven central repo, this could all be automated easily without using little-known download a single file from a non-standard location techniques. Publishing to maven central the official tomcat distro under any other groupid than the tomcat one seems calculated to confuse everyone in every way possible. If using a non-tomcat groupId is the only choice I'd keep the openejb copy in apache svn. thanks david jencks Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing zips to the maven repo
On Oct 14, 2011, at 9:18 AM, Mark Thomas wrote: On 14/10/2011 17:09, David Jencks wrote: If using a non-tomcat groupId is the only choice I'd keep the openejb copy in apache svn. That is not an option that is acceptable to the ASF infrastructure team. In this context, it's pretty much equivalent to an ant based build putting a bunch of jars used in the build in a lib directory in svn. Has infra prohibited that? thanks david jencks Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Is caching tags in SimpleTags a good idea?
Thanks for your response! On Oct 12, 2011, at 9:56 PM, Konstantin Kolinko wrote: 2011/10/12 David Jencks david_jen...@yahoo.com: I've been working with someone who has deeply nested SimpleTags (generated from jsp source) that use a lot of regular Tags. By default the jasper generated code for the SimpleTags caches the plain Tags. Since SimpleTags per spec are never cached and are always single-use, it seems pretty implausible that caching the plain tags in a SimpleTag would produce a performance benefit and indeed profiling shows it is slower than just turning off all tag caching. Does anyone have any arguments against eliminating caching for tags used in generated SimpleTags? If not I'll work on a patch. I am not sure that caching plain tags at all is good for performance, but the feature is implemented because the spec requires it. I haven't been able to find any spec language that requires caching of plain tags, can you point me to it? I thought they just had to be cacheable, not that the container had to cache them. To be more precise, it depends on a web application. I am not surprised that turning off caching improves performance. If you have a single SimpleTag that generates the whole JSP page using a lot of plain tags, I think the benefits of caching would be the same as for a JSP page, regardless of recycling the tag. Well, that makes some sense :-) Maybe we'll stick with the enable pooling option for the code generation. I would like to hear some details why in you case the caching does not work. It works, but there are something like 40 simple tags each with several plain tags used once to generate the jsp page. There's noticeable overhead creating the tag cache objects for the simple tags. How did you turn off the caching? There are two ways: a) system property b) enablePooling option of JspServlet that affects the java code that is generated for the page. we changed the code generation. If you would implement a feature, I think it would be something like that enablePooling option of JspServlet that affects what Java code is generated. http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html many thanks! david jencks Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Is caching tags in SimpleTags a good idea?
I've been working with someone who has deeply nested SimpleTags (generated from jsp source) that use a lot of regular Tags. By default the jasper generated code for the SimpleTags caches the plain Tags. Since SimpleTags per spec are never cached and are always single-use, it seems pretty implausible that caching the plain tags in a SimpleTag would produce a performance benefit and indeed profiling shows it is slower than just turning off all tag caching. Does anyone have any arguments against eliminating caching for tags used in generated SimpleTags? If not I'll work on a patch. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JspRuntimeContext JspServlet - Using SpringSource's Jasper 5.5.23 implementation in Http Service?
Hi Misha, You won't get far with only osgi httpservice support. IMO, practically speaking, you need osgi WAB support that also implements jsp support.You probably also want many of the osgi ee specs as implemented e.g. in apache aries. Geronimo includes all of these. There may well be other projects that support WABs, but I don't know what they are, and I don't know of any that also include so much of the osgi ee support. There are a bunch of problems in servlet related specs like jsp and jsf that osgi has not addressed in standards yet such as tld file caches and faces-config.xml discovery that geronimo has more or less working solutions for. If you run into these kinds of problems any solution will be proprietary. thanks david jencks On Nov 6, 2010, at 10:27 AM, Misha Koshelev wrote: Hi David and all: Thank you for the reference to the Geronimo project. http://geronimo.apache.org/ From what I understand, this is a specific Web server, and we would be tie end users to this (or another specific) Web server if we were to go this route. Our lead developers, however, would very much like to preserve _independence_ from the specific Web server on which OpenMRS is running, see, e.g., http://tickets.openmrs.org/browse/TRUNK-1596?focusedCommentId=162538page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_162538 http://tickets.openmrs.org/browse/TRUNK-1596?focusedCommentId=163079page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_163079 What I mean by proxying is a servlet bridge, such as: http://www.eclipse.org/equinox/server/http_in_container.php http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheServletBridge Perhaps my original email was a little too long-winded and the main question got lost... so I'll try to be concise: could someone possible explain JspRuntimeContext and JspServlet, and, specifically, how (or when) those are invoked to lead to proper Jsp processing of a servlet? Or, more importantly, to my understanding, if you have an HTTP Service that does _not_ include Jasper, how does one go about adding JspServlet and/or JspRuntimeContext to add this support (I mean in theory at least, like the JspServlet servlet has to be registered to handle all *.jsp requests or something like that... I don't believe this is correct but I just mean a general theoretical understanding would be quite helpful). Thank you! Yours Misha On Sat, Nov 6, 2010 at 2:15 AM, David Jencks david_jen...@yahoo.com wrote: I don't understand the diagram you show nor what you mean by bridging, but you might want to consider looking at geronimo 3. We have tomcat and jasper running in an osgi environment and can deploy WABs and also EE wars as osgi bundles. I believe you can (as of a few days ago) look up the bundle/bundle context in jndi and get it injected into your ee components. Whether or not this is something you want to look into I'd suggest you look into a container that supports WABs. thanks david jencks On Nov 5, 2010, at 9:02 PM, Misha Koshelev wrote: Dear All: My sincerest apologies if this is the wrong forum for this question. I was unable to find a better place for Jasper API support/questions. I am working on a ticket to make the OpenMRS medical records system run in an OSGi environment. http://tickets.openmrs.org/browse/TRUNK-1596 SUMMARY: My simple question - is there, at the very least, some clear explanation of JspRuntimeContext and JspServlet (besides http://tomcat.apache.org/tomcat-5.5-doc/jasper/docs/api/org/apache/jasper/compiler/JspRuntimeContext.html http://tomcat.apache.org/tomcat-5.5-doc/jasper/docs/api/org/apache/jasper/servlet/JspServlet.html ) or, more importantly, is there any clear guide or suggestions for how to use these within a non-JSP aware server to have proper JSP support, esp. with regard to taglibs (as, at the very least, the Jsp file seems to be processed and include directives seem to be occurring - which seems strange if Jasper is not functioning at all, although this is the case at least based on the logs). Any help much appreciated DETAILS: We are able to use Spring Web extender http://static.springsource.org/osgi/docs/current/reference/html/web.html to successfully make OpenMRS run within an OSGi environment http://tickets.openmrs.org/secure/attachment/34857/1596-latest.patch we would like to have a proxy setup, i.e., Tomcat - WAR - OSGi - OSGified OpenMRS - module 1 - module 2 etc. I am currently trying to thus move to using an OSGi HTTP Service implementation, as this allows bridging as above. I have found Apache Felix HTTP Service http://felix.apache.org/site/apache-felix-http-service.html to be quite nice for this purpose. I
Re: svn commit: r1028940 - in /tomcat/trunk/java/org/apache/jasper: EmbeddedServletOptions.java JspC.java Options.java compiler/JspRuntimeContext.java resources/LocalStrings.properties servlet/JspServ
Would you consider putting the time unit (seconds) in the param name or at
least in _all_ the javadoc? Without documentation I would expect the natural
time unit to be minutes.
thanks
david jencks
On Oct 29, 2010, at 4:22 PM, rj...@apache.org wrote:
Author: rjung
Date: Fri Oct 29 23:22:35 2010
New Revision: 1028940
URL: http://svn.apache.org/viewvc?rev=1028940view=rev
Log:
Add new JSP init parameter jspIdleTimeout.
If set 0 (default -1), a background task
will unload all JSPs being idle longer than this
time in seconds.
Modified:
tomcat/trunk/java/org/apache/jasper/EmbeddedServletOptions.java
tomcat/trunk/java/org/apache/jasper/JspC.java
tomcat/trunk/java/org/apache/jasper/Options.java
tomcat/trunk/java/org/apache/jasper/compiler/JspRuntimeContext.java
tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties
tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
Modified: tomcat/trunk/java/org/apache/jasper/EmbeddedServletOptions.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/EmbeddedServletOptions.java?rev=1028940r1=1028939r2=1028940view=diff
==
--- tomcat/trunk/java/org/apache/jasper/EmbeddedServletOptions.java (original)
+++ tomcat/trunk/java/org/apache/jasper/EmbeddedServletOptions.java Fri Oct
29 23:22:35 2010
@@ -189,11 +189,17 @@ public final class EmbeddedServletOption
/**
- * The maxim number of loaded jsps per web-application. If there are more
+ * The maximum number of loaded jsps per web-application. If there are
more
* jsps loaded, they will be unloaded.
*/
private int maxLoadedJsps = -1;
+/**
+ * The idle time after which a JSP is unloaded.
+ * If unset or less or equal than 0, no jsps are unloaded.
+ */
+private int jspIdleTimeout = -1;
+
public String getProperty(String name ) {
return settings.getProperty( name );
}
@@ -391,14 +397,22 @@ public final class EmbeddedServletOption
}
/**
- * Should any jsps be unloaded? If set to a value greater than 0
eviction of jsps
- * is started. Default: -1
- * */
+ * Should jsps be unloaded if to many are loaded?
+ * If set to a value greater than 0 eviction of jsps is started.
Default: -1
+ */
public int getMaxLoadedJsps() {
return maxLoadedJsps;
}
/**
+ * Should any jsps be unloaded when being idle for to long?
+ * If set to a value greater than 0 eviction of jsps is started.
Default: -1
+ */
+public int getJspIdleTimeout() {
+return jspIdleTimeout;
+}
+
+/**
* Create an EmbeddedServletOptions object using data available from
* ServletConfig and ServletContext.
*/
@@ -689,6 +703,17 @@ public final class EmbeddedServletOption
}
}
}
+
+String jspIdleTimeout = config.getInitParameter(jspIdleTimeout);
+if (jspIdleTimeout != null) {
+try {
+this.jspIdleTimeout = Integer.parseInt(jspIdleTimeout);
+} catch(NumberFormatException ex) {
+if (log.isWarnEnabled()) {
+
log.warn(Localizer.getMessage(jsp.warning.jspIdleTimeout,
+this.jspIdleTimeout));
+}
+}
+}
// Setup the global Tag Libraries location cache for this
// web-application.
Modified: tomcat/trunk/java/org/apache/jasper/JspC.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/JspC.java?rev=1028940r1=1028939r2=1028940view=diff
==
--- tomcat/trunk/java/org/apache/jasper/JspC.java (original)
+++ tomcat/trunk/java/org/apache/jasper/JspC.java Fri Oct 29 23:22:35 2010
@@ -447,6 +447,10 @@ public class JspC implements Options {
return -1;
}
+public int getJspIdleTimeout() {
+return -1;
+}
+
/**
* {...@inheritdoc}
*/
Modified: tomcat/trunk/java/org/apache/jasper/Options.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/Options.java?rev=1028940r1=1028939r2=1028940view=diff
==
--- tomcat/trunk/java/org/apache/jasper/Options.java (original)
+++ tomcat/trunk/java/org/apache/jasper/Options.java Fri Oct 29 23:22:35 2010
@@ -222,9 +222,15 @@ public interface Options {
public MapString, TagLibraryInfo getCache();
/**
- * The maxim number of loaded jsps per web-application. If there are more
+ * The maximum number of loaded jsps per web-application. If there are
more
* jsps loaded, they will be unloaded. If unset or less than 0, no jsps
* are unloaded.
*/
public int getMaxLoadedJsps
Re: [VOTE] Release Apache Tomcat 7.0.4
On Oct 20, 2010, at 5:03 AM, Mark Thomas wrote: On 20/10/2010 06:39, Jess Holle wrote: On 10/20/2010 5:45 AM, Mark Thomas wrote: On 19/10/2010 08:56, Mark Thomas wrote: Ping. Just a gentle reminder that there are ~2 days left for this vote. So far we have 1 vote for beta and no other votes. Sorry - it should have said ~1 day above. I've been traveling and got my dates mixed up. I'll leave the vote open for another 24 hours or so. Currently there are 4 votes for beta (2*PMC, 1*committer, 1*contributor) so we need at least 1 more PMC vote in order to proceed with this release. As someone trying to figure out when to take the plunge into Tomcat 7, but needing something that is definitely stable, is there any sort of list as to what hurdles remain to be cleared before considering Tomcat 7 is considered stable? My own view is that to be considered stable, Tomcat 7 needs to meet the following criteria: 1. Implement all aspects of Servlet 3.0, JSP 2.2, EL 2.2 2. Pass all unit tests with all three HTTP connectors 4. Pass all relevant TCKs with the security manager enabled - Servlet TCK with all three HTTP connectors and both AJP connectors - JSP TCK with any connector - EL TCK (doesn't use web requests) 4. Have no 'significant' open bugs 5. Have reasonable adoption 6. Have a couple of releases with no 'serious' bugs emerging In term of progress: 1. Done (to the best of my knowledge). I don't think tomcat is processing security constraints added through ServletRegistration. I added some hooks in one of my patches so the info got to an appropriate class but only implemented the actual processing in geronimo. see https://issues.apache.org/bugzilla/show_bug.cgi?id=50015 thanks david jencks 2. It does. 3. It does (as have all 7.0.x releases). 4. There is currently 1 (yes one!) open bug without a patch across 5.5.x, 6.0.x and 7.0.x so I think we can call this one done. 5. Based on some analysis of download requests and the number and quality of bug reports I am happy that there is reasonable adoption at this stage. 6. I see this as the only thing between 7.0.x and stability. Serious is subjective but the sort of things I would include are: - anything that requires a major refactoring to fix - anything that breaks typical use cases As an example, I would consider another bug 49884 serious due to both the async issues it caused and the scale of the refactoring required to fix. I wouldn't consider another 50072 serious mainly because that issue has been present in the 6.0.x code base and hasn't been a problem (at least not one folks have reported). So in summary, if 7.0.4 and 7.0.5 go well, things are looking good for 7.0.6. HTH, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [OT] Difficulty creating working patch - renamed file.
On Sep 28, 2010, at 7:23 AM, Wesley Acheson wrote: HI All, I'm not actually sure how OT this is or if the question belongs here. This is semi duplicating some comments seen in a bug. However I think its useful for anyone trying to create future patches who is inexperienced like me, so I'm sort of double posting. I'm trying to create a patch. However part of that patch is renaming a file then modifying its contents. However when a .patch is created in eclipse it appears to record the delete then record the changes to the new filename. However as It hasn't got the new filename in SVN when that patch is applied it breaks. I've no idea how to record this properly as It appears that the patches are always made against SVN directly. So I can't provide a patch to rename the file then another patch to modify its contents. Finally the question. How to create a patch that involves moving or renaming a file and changing its contents. From what I hear the best advice is use git, not svn. However that's usually difficult at apache. It's really unfortunate that svn can't generate usable patches if you've svn mv'ed any files. What I try to do in this situation is to supply a script with the svn mv commands along with the patch from svn diff. Part of the patch won't apply (the part that empties the moved files) but the part that shows the modifications of the moved files should. Supplying an svn script for the file move rather than a patch means that svn history will be preserved. A patch just from svn mv won't result in proper svn history (and I think also won't actually add the content to the files at the new location) david jencks Wes - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Which IDE?
On Sep 26, 2010, at 11:08 AM, Wesley Acheson wrote: Commiters, patch authors. Do you use an IDE to modify tomcat source code? If you do which one? IDEA Asking again in releation to bug 50001. Trying to see what ide's should be supported. My experience with IDE specific files is that checking them into svn usually causes far more problems that it solves. Maybe you'll be lucky and solve more than you cause. If I'm the only IDEA user I'd appreciate your not putting IDEA specific files in svn. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NamingContext Possible Bug
For reference, the EE 6 platform spec explains that usually a new instance
should be returned on each lookup in section 5.2.4 page 67 Sharing of
Environment Entries. The servlet 3.0 spec section 15.2.2 page 174 indicates
that this applies to servlet containers that are part of an EE
technology-compliant implementation. I guess this means that unless tomcat
implements web profile they don't have to support this? It still seems like a
good idea to me.
thanks
david jencks
On Sep 22, 2010, at 10:36 PM, Gurkan Erdogdu wrote:
Hello,
I want to bring this question again.
Why do we change NamingEntry type from REFERENCE to ENTRY? I think that each
lookup must return a new instance. But in this case, it returns the same
bound
object instance.
Let's says that we have a Servlet
MyServlet{
private @Resource(name=MyResource) myResource;
...
public blabla(){
new InitialContext().lookup(myResource);
}
}
myResource has injected by the container before @PostConstruct is called.
After
that I would like to get a new resource object in blabla() method. It returns
the same injected resource instance instead of creating a new resource.
I think that it must return a different instance from myResource. JNDI tree
of
the Servlet contains MyResource/ResourceRef binding. Therefore each lookup
to
MyResource must return a ResourceRef. Becuase it is a reference, context
must call NamingManager.getObjectInstance again to create a new instance.
If this is a bug, I will open an issue.
Thanks;
--Gurkan
- Original Message
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: dev@tomcat.apache.org
Sent: Tue, September 21, 2010 6:30:43 PM
Subject: NamingContext Possible Bug
Hello folks,
In NamingContext implementation, if lookup() is a Reference, current
implementation caches the result of the NamingManager # getObjectInstance via
following statements and changes the type of the entry. In the following
lookups, same object is returned. I would like to write ObjectFactory that
returns new instance for each time lookup is called on its reference. But
with
the current implementation, it is not possible to write such an object
factory
because of aferomentioned sitaution. I think that entry must be stay as
Reference instead of changing entry type.
WDYT?
NamingContext class:
protected Object lookup(Name name, boolean resolveLinks)
throws NamingException {
.
} else if (entry.type == NamingEntry.REFERENCE) {
try {
Object obj = NamingManager.getObjectInstance
(entry.value, name, this, env);
if (obj != null) {
entry.value = obj;
entry.type = NamingEntry.ENTRY; --- CHANGES type of
the naming entry
}
return obj;
} catch (NamingException e) {
throw e;
} catch (Exception e) {
log.warn(sm.getString
(namingContext.failResolvingReference), e);
throw new NamingException(e.getMessage());
}
}
...
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AsyncListeners and resource injection
On Sep 15, 2010, at 10:51 PM, David Jencks wrote:
On Sep 15, 2010, at 9:58 PM, David Jencks wrote:
I think this is how AsyncContextImpl creates async listeners (lines 228ff)
@Override
public T extends AsyncListener T createListener(ClassT clazz)
throws ServletException {
T listener = null;
try {
listener = clazz.newInstance();
} catch (InstantiationException e) {
ServletException se = new ServletException(e);
throw se;
} catch (IllegalAccessException e) {
ServletException se = new ServletException(e);
throw se;
}
return listener;
}
but the 3.0 spec section 15.5 page 179 says
Annotations must be supported on the following container managed classes
that implement the following interfaces and are declared in the web
application deployment descriptor or using the annotations defined in
Section 8.1, “Annotations and pluggability” on page 8-61 or added
programmatically.
and includes AsyncListener in the table following.
So shouldn't this be using the instance manager to create the instance so
the resource injection machinery can do its stuff?
Secondly, if you do try to register an AsyncListener with the
ServletContext so it can be scanned for annotations, aside from not actually
scanning it, it quickly gets to this code (ApplicationContext lines 1262 ff)
@Override
public T extends EventListener void addListener(T t) {
if (!context.getState().equals(LifecycleState.STARTING_PREP)) {
throw new IllegalStateException(
sm.getString(applicationContext.addListener.ise,
getContextPath()));
}
// TODO SERVLET3
// throw UnsupportedOperationException - if this context was passed to
the
// {...@link
ServletContextListener#contextInitialized(javax.servlet.ServletContextEvent)}
// method of a {...@link ServletContextListener} that was not declared
// in web.xml, a web-fragment or annotated with {...@link WebListener}.
boolean match = false;
if (t instanceof ServletContextAttributeListener ||
t instanceof ServletRequestListener ||
t instanceof ServletRequestAttributeListener ||
t instanceof HttpSessionAttributeListener) {
context.addApplicationEventListener(t);
match = true;
}
if (t instanceof HttpSessionListener
|| (t instanceof ServletContextListener
newServletContextListenerAllowed)) {
context.addApplicationLifecycleListener(t);
match = true;
}
if (match) return;
throw new IllegalArgumentException(sm.getString(
applicationContext.addListener.iae.wrongType,
t.getClass().getName()));
}
which doesn't accept AsyncListeners. (of course it shouldn't do anything
with then).
Thoughts?
thanks
david jencks
BTW I opened bug 49937 with fixes that work for me for these problems.
david jencks
The situation seems to be more complicated than I thought at first.
As noted above, section 15.5 clearly indicates annotation based resource
injection is supported for all servlet related listeners including
AsyncListener, and that these can be specified in the xml deployment
descriptor, via annotation, or by adding programatically.
However
4.4.3 indicates that an AsyncListener cannot be added programatically
4.4.3.5 indicates that resource injection is not supported for listeners added
programatically unless the listener is a managed bean. I think this directly
contradicts 15.5.
8.1.4 indicates that an AsyncListener cannot be annotated with @WebListener
11.3.2 says
Listener classes are declared in the Web application deployment descriptor
using the listener element. They are listed by class name in the order in which
they are to be invoked. Unlike other listeners, listeners of type AsyncListener
may only be registered (with a ServletRequest) programmatically.
I can't figure out what this is supposed to mean. It might mean that you
aren't allowed to list an AsyncListener in your web.xml, or it might mean that
you can, but to use it you have to explicitly add it to an AsyncContext.
Despite the contradictions in the spec, it seems pretty clear that an
asyncListener can be a managed bean and thus be subject to resource injection.
It might also be possible for it to be listed in web.xml, have a @WebListener
annotation, and be added programatically so it can be scanned for normal ee
resource injection annotations (depending on how much weight you put on 15.5
compared with the other sections). So, I think that the
AsyncContext.createListener method should use the instance manager in any case.
I think it makes sense to relax the restrictions on @WebListener and
programatically adding AsyncListeners
AsyncListeners and resource injection
I think this is how AsyncContextImpl creates async listeners (lines 228ff)
@Override
public T extends AsyncListener T createListener(ClassT clazz)
throws ServletException {
T listener = null;
try {
listener = clazz.newInstance();
} catch (InstantiationException e) {
ServletException se = new ServletException(e);
throw se;
} catch (IllegalAccessException e) {
ServletException se = new ServletException(e);
throw se;
}
return listener;
}
but the 3.0 spec section 15.5 page 179 says
Annotations must be supported on the following container managed classes that
implement the following interfaces and are declared in the web application
deployment descriptor or using the annotations defined in Section 8.1,
“Annotations and pluggability” on page 8-61 or added programmatically.
and includes AsyncListener in the table following.
So shouldn't this be using the instance manager to create the instance so the
resource injection machinery can do its stuff?
Secondly, if you do try to register an AsyncListener with the ServletContext
so it can be scanned for annotations, aside from not actually scanning it, it
quickly gets to this code (ApplicationContext lines 1262 ff)
@Override
public T extends EventListener void addListener(T t) {
if (!context.getState().equals(LifecycleState.STARTING_PREP)) {
throw new IllegalStateException(
sm.getString(applicationContext.addListener.ise,
getContextPath()));
}
// TODO SERVLET3
// throw UnsupportedOperationException - if this context was passed to
the
// {...@link
ServletContextListener#contextInitialized(javax.servlet.ServletContextEvent)}
// method of a {...@link ServletContextListener} that was not declared
// in web.xml, a web-fragment or annotated with {...@link WebListener}.
boolean match = false;
if (t instanceof ServletContextAttributeListener ||
t instanceof ServletRequestListener ||
t instanceof ServletRequestAttributeListener ||
t instanceof HttpSessionAttributeListener) {
context.addApplicationEventListener(t);
match = true;
}
if (t instanceof HttpSessionListener
|| (t instanceof ServletContextListener
newServletContextListenerAllowed)) {
context.addApplicationLifecycleListener(t);
match = true;
}
if (match) return;
throw new IllegalArgumentException(sm.getString(
applicationContext.addListener.iae.wrongType,
t.getClass().getName()));
}
which doesn't accept AsyncListeners. (of course it shouldn't do anything with
them).
Thoughts?
thanks
david jencks
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AsyncListeners and resource injection
On Sep 15, 2010, at 9:58 PM, David Jencks wrote:
I think this is how AsyncContextImpl creates async listeners (lines 228ff)
@Override
public T extends AsyncListener T createListener(ClassT clazz)
throws ServletException {
T listener = null;
try {
listener = clazz.newInstance();
} catch (InstantiationException e) {
ServletException se = new ServletException(e);
throw se;
} catch (IllegalAccessException e) {
ServletException se = new ServletException(e);
throw se;
}
return listener;
}
but the 3.0 spec section 15.5 page 179 says
Annotations must be supported on the following container managed classes that
implement the following interfaces and are declared in the web application
deployment descriptor or using the annotations defined in Section 8.1,
“Annotations and pluggability” on page 8-61 or added programmatically.
and includes AsyncListener in the table following.
So shouldn't this be using the instance manager to create the instance so the
resource injection machinery can do its stuff?
Secondly, if you do try to register an AsyncListener with the ServletContext
so it can be scanned for annotations, aside from not actually scanning it, it
quickly gets to this code (ApplicationContext lines 1262 ff)
@Override
public T extends EventListener void addListener(T t) {
if (!context.getState().equals(LifecycleState.STARTING_PREP)) {
throw new IllegalStateException(
sm.getString(applicationContext.addListener.ise,
getContextPath()));
}
// TODO SERVLET3
// throw UnsupportedOperationException - if this context was passed to
the
// {...@link
ServletContextListener#contextInitialized(javax.servlet.ServletContextEvent)}
// method of a {...@link ServletContextListener} that was not declared
// in web.xml, a web-fragment or annotated with {...@link WebListener}.
boolean match = false;
if (t instanceof ServletContextAttributeListener ||
t instanceof ServletRequestListener ||
t instanceof ServletRequestAttributeListener ||
t instanceof HttpSessionAttributeListener) {
context.addApplicationEventListener(t);
match = true;
}
if (t instanceof HttpSessionListener
|| (t instanceof ServletContextListener
newServletContextListenerAllowed)) {
context.addApplicationLifecycleListener(t);
match = true;
}
if (match) return;
throw new IllegalArgumentException(sm.getString(
applicationContext.addListener.iae.wrongType,
t.getClass().getName()));
}
which doesn't accept AsyncListeners. (of course it shouldn't do anything
with then).
Thoughts?
thanks
david jencks
BTW I opened bug 49937 with fixes that work for me for these problems.
david jencks
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Can jsp-file be a JspServlet init-param?
On Sep 8, 2010, at 11:48 PM, Mark Thomas wrote: On 09/09/2010 00:54, David Jencks wrote: I've recently rewritten the geronimo-jetty integration to work off the servlet 3 *Registration classes. This works great except for servlets backed by jsp files, since there's no way to tell the servlet container through the ServletRegistration interface that its actually something with this extra jsp file name that needs to be added through some special process into the request. That looks like an oversight in the 3.0 spec. I'm not sure why you think that. A servlet extension mechanism such as a jsp engine can use the servlet 3 API to add servlets directly. I think it would make more sense to completely remove any mention of jsp from web.xml and the servlet spec and run jsps off a separate configuration file. However, its easy to subclass the JspServlet so it gets the jsp file value from an init param, and of course its easy to set the init param from the web.xml. This appears to work fine. Is there some reason I've missed that this is a bad idea? Well, it would be container specific rather than defined by the spec but since the spec offers no way to define it, I don't see there is a choice. The existing way of using a servlet request attribute to feed the jsp file to the instance of the jsp servlet set up for a particular servlet element is also not mentioned in the spec. It does need some special attention on each request. My proposal moves all the jsp-aware code in catalina to the deploy phase and allows treating these explicitly set up JspServlet instances just like any other servlet. If not, would the jasper community consider a patch to modify the JspServlet so it directly looks for such an init-param? Patches always get considered. excellent, see https://issues.apache.org/bugzilla/show_bug.cgi?id=49916 If I've understood the tomcat build this passes all the tests and also appears to cause no tck problems in the geronimo-tomcat integration. And would the tomcat community consider simplifying the runtime code to use this init-param instead of a Constants.JSP_FILE request attribute? As usual, it would depend on the patch. thanks! david jencks Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Can jsp-file be a JspServlet init-param?
I've recently rewritten the geronimo-jetty integration to work off the servlet 3 *Registration classes. This works great except for servlets backed by jsp files, since there's no way to tell the servlet container through the ServletRegistration interface that its actually something with this extra jsp file name that needs to be added through some special process into the request. However, its easy to subclass the JspServlet so it gets the jsp file value from an init param, and of course its easy to set the init param from the web.xml. This appears to work fine. Is there some reason I've missed that this is a bad idea? If not, would the jasper community consider a patch to modify the JspServlet so it directly looks for such an init-param? And would the tomcat community consider simplifying the runtime code to use this init-param instead of a Constants.JSP_FILE request attribute? thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, Valve - Filter conversion, and container-managed authentication/authorization
On Apr 29, 2010, at 9:48 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Tomcat 7, Valve - Filter conversion, and container- managed authentication/authorization I guess my question would be how much of servlet 3 has been implemented in TC7 at this point? Similarly, what's the status of JSR 196? It seems to be languishing, to put it kindly. Geronimo has a provider implementation, which we use, jetty has built in support, geronimo's tomcat fork has support which we've offered back to tomcat, glassfish has support, IIUC JBoss has had support for many years (well before the spec was approved). I'm a little unclear on the exact status in ee6 but think that support for the servlet profile is required so I'd expect the commercial vendors to support it as well in their ee6 releases. There does seem to be remarkable reluctance on the part of users to consider trying it. Do you have any idea why? thanks david jencks - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, Valve - Filter conversion, and container-managed authentication/authorization
I'd be curious how many of the features in securityfilter can be done with servlet 3 (which includes the ability for an app to programatically force a login) and jaspic (jsr 196) which provides for pluggable authentication dialogs between client and server (to overly simplify it). It looks to me as if all the features in your brief description are now supported by ee specs, which also offer the advantages of container managed authorization. thanks david jencks On Apr 28, 2010, at 10:49 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, Hello, I'm Chris Schultz, the maintainer of the securityfilter project (http://securityfilter.sourceforge.net/) and active member of the tomcat-user mailing list. I've been loosely following the plans for Tomcat 7 and was interested to see that there's an effort to convert existing Tomcat Valve components into Filters, I suppose to make them more flexible and also to increase portability. For those unfamiliar with the project, securityfilter is a filter-based implementation of authentication and authorization that aims to comply with the Java Servlet Specification while offering features above and beyond it. Most of our users have abandoned container-managed auth provided by containers such as Tomcat because of missing features (not specified by the servlet spec) such as barge-in logins, customized after-login pages, and customizability that doesn't tie the web application to any specific container. I inherited the existing securitfyilter code base from Max Cooper and I've been trying to improve the compliance with the servlet spec and to ensure support for the more recent versions of the spec (sf is mostly 2.3 compliant, but we're trying to fill-in all the holes). After adding a few features to the 2.x code base, I'm considering a full re-write of the code for a 3.x version that is more flexible than the current implementation. I was thinking that, as Tomcat contemplates a conversion of container-managed auth from a Valve to a Filter, securityfilter could possibly factor-into that conversion. I'd be happy to convert sf into an Apache commons/incubator project and have Tomcat use it for authentication and authorization. Mark Thomas has indicated his interest in discussing this possibility on the development list, so I'm presenting it to the group. I'd be happy to give more details about my current plans for sf, etc. but I figured that if there was significant interest in the Tomcat/ASF communities, we could discuss what feature set ought to be available. Please let me know if the community is interested in adopting securityfilter and, ultimately, using it in Tomcat. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvYdS8ACgkQ9CaO5/Lv0PCRygCgwJ3Sw9g5YRbgHh/RQqLXdzXz 8IwAoJBEk06BovBRtADh9WfAQMx/F2Zp =dcy8 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, Valve - Filter conversion, and container-managed authentication/authorization
On Apr 28, 2010, at 4:14 PM, Pid wrote: On 28/04/2010 23:40, David Jencks wrote: I'd be curious how many of the features in securityfilter can be done with servlet 3 (which includes the ability for an app to programatically force a login) and jaspic (jsr 196) which provides for pluggable authentication dialogs between client and server (to overly simplify it). It looks to me as if all the features in your brief description are now supported by ee specs, which also offer the advantages of container managed authorization. Srv 3.0 /does/ cover some of the functions of securityfilter, but IMHO the latter's been a home for things that the spec doesn't cover, but that are common requirements anyway. It could now be a source of Tomcat integration with technologies like OpenID OAuth for example, if the existing experience of operating as a Filter rather than a Valve wasn't of enough interest. I'm well aware of the limitations of servlet 2.5 without jaspic. However, to use one of your examples, it's easy to write an OpenID jaspic server authentication module that lets you do container managed authentication and authorization using openid (see the geronimo-jaspi-openid component). There's also a SPNEGO auth module somewhere. Rather than telling me that old specs don't support a lot of stuff securityfilter does, I'd like to know specifically what securityfilter does that the new specs don't support. At this point I have no opinion on whether it would be a good idea for securityfilter to move to apache. One incubator project that might be somewhat related is Shiro (formerly jsecurity). I have no idea how similar the projects are. thanks david jencks p thanks david jencks On Apr 28, 2010, at 10:49 AM, Christopher Schultz wrote: All, Hello, I'm Chris Schultz, the maintainer of the securityfilter project (http://securityfilter.sourceforge.net/) and active member of the tomcat-user mailing list. I've been loosely following the plans for Tomcat 7 and was interested to see that there's an effort to convert existing Tomcat Valve components into Filters, I suppose to make them more flexible and also to increase portability. For those unfamiliar with the project, securityfilter is a filter-based implementation of authentication and authorization that aims to comply with the Java Servlet Specification while offering features above and beyond it. Most of our users have abandoned container-managed auth provided by containers such as Tomcat because of missing features (not specified by the servlet spec) such as barge-in logins, customized after-login pages, and customizability that doesn't tie the web application to any specific container. I inherited the existing securitfyilter code base from Max Cooper and I've been trying to improve the compliance with the servlet spec and to ensure support for the more recent versions of the spec (sf is mostly 2.3 compliant, but we're trying to fill-in all the holes). After adding a few features to the 2.x code base, I'm considering a full re-write of the code for a 3.x version that is more flexible than the current implementation. I was thinking that, as Tomcat contemplates a conversion of container-managed auth from a Valve to a Filter, securityfilter could possibly factor-into that conversion. I'd be happy to convert sf into an Apache commons/incubator project and have Tomcat use it for authentication and authorization. Mark Thomas has indicated his interest in discussing this possibility on the development list, so I'm presenting it to the group. I'd be happy to give more details about my current plans for sf, etc. but I figured that if there was significant interest in the Tomcat/ASF communities, we could discuss what feature set ought to be available. Please let me know if the community is interested in adopting securityfilter and, ultimately, using it in Tomcat. Thanks, -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote: On 04/01/2010 02:46, Tim Whittington wrote: No need to re-post. A ping would have sufficed. We've experienced similar issues integrating lots of third party libraries (Tomcat being one of them) into our OSGi runtime. Thanks for your input. I can't speak for the other Tomcat committers but I know very little about OSGI so it is useful to have input from those more experienced. Essentially this boils down to OSGi liking extension functionality to be provided by instantiation in the providing bundles, and publication using OSGi services. (i.e. pure OSGi services or declarative services etc.). Put another way, the concepts of global application classloaders where Class.forName works (ala Java EE etc.) break down in OSGi. Libraries that use the TCCL in preference to Class.forName help, but in cases like the one you describe where there's no direct invocation from the bundle that has access to the classes it doesn't help. Fragment bundles (and Eclipse specific buddy classloaders) also help, and we've had to use them with tools like Hibernate, but they're less than ideal. I think the conclusion you've reached is correct - either fragment bundles (which is a sub-optimal solution) or a pluggable extension loading framework could be the solution. OK. The consensus amongst those that know OSGI seems to be some form for pluggable extension point. I believe we ran into issues like this when integrating Tomcat 5.5 into our OSGi runtime - we had to patch up the web app ClassLoaders at runtime to make taglib loading work. In that case we were able to wrap the ClassLoaders with the help of some declarative metadata in bundles containing taglibs. If you can tell which bundles can contain implementions of whatever it is you're trying to instantiate, you can construct a ClassLoader spanning those bundles yourself and use that (you'd only want to use it for loading these extensions, as it defeats the purpose/ nature of OSGi to some extent to do this). It might be that the web application bundles would be all you need (and the upcoming OSGi Enterprise Spec will give you a standard way of locating these), and that'd probably be a reasonable limitation, or you could accomodate applications partitioned to a finer degree by some additional marker to include other bundles. The other, more OSGi approach would be for listeners to be published as OSGi services with target properties, that are then just looked up by name by the OSGi version of the extension loader (as opposed to instantiating them). i.e. an instance of the Listener interface is published by a bundle as an OSGi service with a property tomcatClassName=org.myproject.impl.MyListener. The extension loader then looks up the service with a property filter on 'tomcatClassName' to find the available extension. OSGi apps using Tomcat would simply publish these using Declarative Services or similar, and this would be a very natural approach for an OSGi app. Using Services does seem more in the spirit of OSGI. With this latter approach you have delightful lifecycle management issues because of the dynamic nature of OSGi (extension bundles starting after the Tomcat bundles for instance). We solve some of these with a combination of declarative only metadata (using the Eclipse Extension Registry) to advertise extension existence on bundle resolution, and Declarative Services to instantiate and publish the actual extension, and some by having the framework accept dynamic injection of extensions (Listeners come and go). Glad I don't have to worry about those issues :) The main purpose of the InstanceManager is meet some of the requirements for annotations support. As such, it is only used for instances that may have annotations. There is one InstanceManager instance per web application. One thing that isn't clear to me is whether the requirement is for an extension point for web application related instances (ie things that in a J2EE environment would be bundled in the WAR) or for container related instances such as LifecycleListeners. The current patch in bug 48414 seems to focussed on Tomcat internals and I don't understand how the line was drawn between what to access via the InstanceManager and what not to. Thanks for taking another look at this subject. I've been thinking of the InstanceManager as the extension point for creating objects by reflection rather than as the annotation handler, perhaps because of how the Geronimo InstanceManager happens to be implemented. So, it seems to me that adding a newSystemInstance method to it for creating objects that are expected to come from the system rather than application classes is reasonable. I'll try to come up with a patch using this additional method in the next day or two. thanks again! david jencks Mark
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
I've uploaded a couple patches to https://issues.apache.org/bugzilla/show_bug.cgi?id=48414 with a new newSystemInstance method. I'm not sure why this doesn't need to be in a protected block like much of the code that creates objects for the app, but the original code wasn't in such a block so I'm assuming it's not really needed. thanks david jencks On Jan 5, 2010, at 9:41 AM, David Jencks wrote: On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote: On 04/01/2010 02:46, Tim Whittington wrote: No need to re-post. A ping would have sufficed. We've experienced similar issues integrating lots of third party libraries (Tomcat being one of them) into our OSGi runtime. Thanks for your input. I can't speak for the other Tomcat committers but I know very little about OSGI so it is useful to have input from those more experienced. Essentially this boils down to OSGi liking extension functionality to be provided by instantiation in the providing bundles, and publication using OSGi services. (i.e. pure OSGi services or declarative services etc.). Put another way, the concepts of global application classloaders where Class.forName works (ala Java EE etc.) break down in OSGi. Libraries that use the TCCL in preference to Class.forName help, but in cases like the one you describe where there's no direct invocation from the bundle that has access to the classes it doesn't help. Fragment bundles (and Eclipse specific buddy classloaders) also help, and we've had to use them with tools like Hibernate, but they're less than ideal. I think the conclusion you've reached is correct - either fragment bundles (which is a sub-optimal solution) or a pluggable extension loading framework could be the solution. OK. The consensus amongst those that know OSGI seems to be some form for pluggable extension point. I believe we ran into issues like this when integrating Tomcat 5.5 into our OSGi runtime - we had to patch up the web app ClassLoaders at runtime to make taglib loading work. In that case we were able to wrap the ClassLoaders with the help of some declarative metadata in bundles containing taglibs. If you can tell which bundles can contain implementions of whatever it is you're trying to instantiate, you can construct a ClassLoader spanning those bundles yourself and use that (you'd only want to use it for loading these extensions, as it defeats the purpose/nature of OSGi to some extent to do this). It might be that the web application bundles would be all you need (and the upcoming OSGi Enterprise Spec will give you a standard way of locating these), and that'd probably be a reasonable limitation, or you could accomodate applications partitioned to a finer degree by some additional marker to include other bundles. The other, more OSGi approach would be for listeners to be published as OSGi services with target properties, that are then just looked up by name by the OSGi version of the extension loader (as opposed to instantiating them). i.e. an instance of the Listener interface is published by a bundle as an OSGi service with a property tomcatClassName=org.myproject.impl.MyListener. The extension loader then looks up the service with a property filter on 'tomcatClassName' to find the available extension. OSGi apps using Tomcat would simply publish these using Declarative Services or similar, and this would be a very natural approach for an OSGi app. Using Services does seem more in the spirit of OSGI. With this latter approach you have delightful lifecycle management issues because of the dynamic nature of OSGi (extension bundles starting after the Tomcat bundles for instance). We solve some of these with a combination of declarative only metadata (using the Eclipse Extension Registry) to advertise extension existence on bundle resolution, and Declarative Services to instantiate and publish the actual extension, and some by having the framework accept dynamic injection of extensions (Listeners come and go). Glad I don't have to worry about those issues :) The main purpose of the InstanceManager is meet some of the requirements for annotations support. As such, it is only used for instances that may have annotations. There is one InstanceManager instance per web application. One thing that isn't clear to me is whether the requirement is for an extension point for web application related instances (ie things that in a J2EE environment would be bundled in the WAR) or for container related instances such as LifecycleListeners. The current patch in bug 48414 seems to focussed on Tomcat internals and I don't understand how the line was drawn between what to access via the InstanceManager and what not to. Thanks for taking another look at this subject. I've been thinking of the InstanceManager as the extension point for creating objects by reflection rather than as the annotation handler, perhaps
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
I'd like to encourage a little more discussion on this topic. Mark commented on the bugzilla entry to the effect, IIUC, that he thought this was a geronimo problem. I did some more experimentation and I'm pretty sure it has nothing to do with geronimo specifically, but relates to how Class.forName works in osgi. I've concluded from my experiments that Class.forName in osgi will only load classes from the current bundle and not from any bundles wired to the current bundle through package-imports. I think this means that with the current code all listeners have to be in the same jar as the catalina.jar classes or in a fragment bundle attached to it. I haven't tried using a fragment bundle so I don't know if it would actually work. So, my conclusion is that the current code forces: if you want listeners that don't come with tomcat, you have to put them in a fragment bundle or repackage all of tomcat to include them. Is this really the policy tomcat wants to adopt towards osgi environments? I would think that delegating all reflective class loading to a pluggable component would be a more extension-friendly approach. BTW, has anyone tried to find out if the split into catalina.jar and coyote.jar works in osgi? thanks david jencks On Dec 19, 2009, at 5:12 PM, David Jencks wrote: In the tomcat-7 geronimo/osgi integration we've run into a problem when tomcat loads listener classes using Class.forName. Using the InstanceManager to just create the objects works fine for us. In geronimo at the moment the InstanceManager has access to both application and system classes, so it can load just about anything that is supplied as a listener class. If listeners are supposed to only be system classes, perhaps adding another method to InstanceManager to create system objects would be appropriate. If changing this is unacceptable for some reason we do have a couple of other solutions available such as overriding the method or adding the geronimo listener classes in a fragment bundle, but I think using the InstanceManager would be a more elegant solution. See https://issues.apache.org/bugzilla/show_bug.cgi?id=48414 (patch included) and https://issues.apache.org/jira/browse/GERONIMO-4992 Many thanks! david jencks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Problem loading classes with Class.forName() in StandardContext.createWrapper()
In the tomcat-7 geronimo/osgi integration we've run into a problem when tomcat loads listener classes using Class.forName. Using the InstanceManager to just create the objects works fine for us. In geronimo at the moment the InstanceManager has access to both application and system classes, so it can load just about anything that is supplied as a listener class. If listeners are supposed to only be system classes, perhaps adding another method to InstanceManager to create system objects would be appropriate. If changing this is unacceptable for some reason we do have a couple of other solutions available such as overriding the method or adding the geronimo listener classes in a fragment bundle, but I think using the InstanceManager would be a more elegant solution. See https://issues.apache.org/bugzilla/show_bug.cgi?id=48414 (patch included) and https://issues.apache.org/jira/browse/GERONIMO-4992 Many thanks! david jencks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem using maven jspc plugin with tomcat 7 and jstl
Mark, I've verified that your fix in rev 890479 works great for this. Many thanks for fixing it so quickly! david jencks On Dec 14, 2009, at 11:25 AM, Mark Thomas wrote: On 14/12/2009 03:58, David Jencks wrote: I can verify by experiment that the 2nd solution fixes the problem with jspC. I agree that there's a strong case to be made for moving DefaultJarScanner to org.apache.tomcat but doing so introduces a lot of dependencies from that package to org.apache.tomcat.util.res.StringManager org.apache.juli.logging.LogFactory org.apache.catalina.startup.Constants I could resolve these but the results would probably not be consistent with whatever policy tomcat has on dependencies. However if this would be helpful I'll be happy to supply a patch. I'm in the middle of fixing this now. I'm going with option 2 since when I looked into the refactoring for option 1 last night there is more required than I really want to do at this stage of Tomcat 7 development. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Problem using maven jspc plugin with tomcat 7 and jstl
Jar scanning for tld files seems to have been refactored recently in
rev 817685 (sept 22 2009) with the introduction of the jasper
JarScannerFactory.
I'm getting a stack trace:
[INFO] [jspc:compile {execution: default}]
Created dir: /Users/david/projects/geronimo/server/trunk/plugins/
activemq/activemq-portlets/target/jsp-source
[INFO] Compiling JSP source files to /Users/david/projects/geronimo/
server/trunk/plugins/activemq/activemq-portlets/target/jsp-source
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] The absolute uri: http://java.sun.com/jsp/jstl/core cannot be
resolved in either web.xml or the jar files deployed with this
application
[INFO]
[INFO] Trace
org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core
cannot be resolved in either web.xml or the jar files deployed with
this application
at
org
.apache
.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:
51)
at
org
.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:
409)
at
org
.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:
116)
at
org
.apache
.jasper
.compiler
.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:322)
at
org
.apache
.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:154)
at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:430)
at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:494)
at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1440)
at org.apache.jasper.compiler.Parser.parse(Parser.java:136)
at
org
.apache.jasper.compiler.ParserController.doParse(ParserController.java:
239)
at
org
.apache.jasper.compiler.ParserController.parse(ParserController.java:
103)
at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:171)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:
333)
at org.apache.jasper.JspC.processFile(JspC.java:1005)
at org.apache.jasper.JspC.execute(JspC.java:1154)
at
org
.codehaus
.mojo
.jspc.compiler.tomcat6.JspCompilerImpl.compile(JspCompilerImpl.java:111)
(we've configured the jspc plugin to use jasper from tomcat 7)
The jsp generation used to work fine with tomcat 6.0.20.
It looks to me as if the problem is that no JarScanner is installed
in the ServletContext used by JspC. (There definitely isn't one
installed, and I think that is the cause of the problem). So, jasper
cant find the jstl jar which is in the classloader all this is running
with.
I don't see how it would be possible for a JarScanner to get installed
so I'm wondering if there is a bug and what a way to fix it or work
around it might be.
JspC.execute has at line 1115
if( context==null ) {
initServletContext();
}
and proceeds directly to call processFile at line 1154 leading to the
error.
Going back a bit
protected void initServletContext() {
try {
context =new JspCServletContext
(new PrintWriter(System.out),
new URL(file: + uriRoot.replace('\\','/') + '/'));
tldLocationsCache = new TldLocationsCache(context);
sets the context and supplies it to TkdLocationsCache which eventually
goes fishing for the JarScanner.
I don't see any opportunities for integration code to add a JarScanner
to the context without subclassing perhaps JspC.
Before proposing any code changes it would be great to have some
advice on how this is supposed to work and confirmation that my
theories on what is wrong are reasonable.
thanks
david jencks
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem using maven jspc plugin with tomcat 7 and jstl
On Dec 13, 2009, at 12:46 PM, Mark Thomas wrote: On 13/12/2009 09:50, David Jencks wrote: It looks to me as if the problem is that no JarScanner is installed in the ServletContext used by JspC. (There definitely isn't one installed, and I think that is the cause of the problem). So, jasper cant find the jstl jar which is in the classloader all this is running with. Your analysis looks spot on to me. I don't see how it would be possible for a JarScanner to get installed so I'm wondering if there is a bug and what a way to fix it or work around it might be. Yep, it's a bug. Before proposing any code changes it would be great to have some advice on how this is supposed to work and confirmation that my theories on what is wrong are reasonable. The motivation behind the original change was to: - make TLD handling consistent between Jasper and Tomcat (there are some edge case anomalies in 6.0.x) - reduce code duplication (there is still a lot of duplication between TldLocationCache and o.a.c.startup.TldConfig) Something to keep in mind is that Jasper should not have any dependencies on Tomcat. At the moment, there are a few shared interfaces in o.a.tomcat but no implementation. The options I can think of off-hand are: - refactor the DefaultJarScanner to o.a.tomcat (or a sub-package) and add it to the tomcat-api.jar (maybe rename the jar) - copy the DefaultJarScanner to the o.a.jasper package The second option is the simplest but I like the first as it provides a basis for removing some of the other duplication (eg around TLDs) between Tomcat core and Jasper. I can verify by experiment that the 2nd solution fixes the problem with jspC. I agree that there's a strong case to be made for moving DefaultJarScanner to org.apache.tomcat but doing so introduces a lot of dependencies from that package to org.apache.tomcat.util.res.StringManager org.apache.juli.logging.LogFactory org.apache.catalina.startup.Constants I could resolve these but the results would probably not be consistent with whatever policy tomcat has on dependencies. However if this would be helpful I'll be happy to supply a patch. BTW I really appreciate that the classes formerly in org.apache got moved to org.apache.tomcat many thanks david jencks Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPNEGO/NEGOTIATE implementation for Apache Geronimo
On Dec 9, 2009, at 5:03 AM, Ashish Jain wrote: Hi folks, Can you please suggest if there is anyway to disable the prompt for username and password when using basic authentication?? That's browser behavior, so the only thing you can do from the server side is not use plain BASIC auth. Are you using a SPNEGO enabled browser on a platform where it can recognize your (client side) kerberos login? Do you have a link to a description of how SPNEGO is supposed to work? thanks david jencks Thanks and Regards Ashish On 11/13/09, Costin Manolache cos...@gmail.com wrote: On Fri, Nov 13, 2009 at 6:44 AM, Mark Thomas ma...@apache.org wrote: Ashish Jain wrote: 4) Does this require code changes to BasicAuthenticator FormAuthenticator, AuthenticatorBase of tomcat. Basic and form - no. Base - maybe. Please provide your comment and suggestions. My instinct (that may be wrong) is that you'll need a new authenticator. If you get this working then I'd certainly consider it for inclusion in Tomcat. An OpenID would be nice too :-) Costin Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 3.0 annotations ?
We use xbean-finder for this in geronimo/openejb/etc. http://repo2.maven.org/maven2/org/apache/xbean/xbean-finder/3.5/ https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder We also have a servlet 3.0 spec jar I've been trying to keep up to date with the glassfish javadocs. https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/specs/geronimo-servlet_3.0_spec/1.0-EA-SNAPSHOT/ https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec thanks david jencks On Aug 4, 2009, at 11:11 AM, Costin Manolache wrote: Hi, anyone working on the @Filter, @Servlet annotation scanner for tomcat-trunk ? If I'm understanding it correctly, tomcat will have to read all files in classes and lib and look for the annotation - and I would guess the only reasonable option is looking at bytecode. I checked BCEL - seems reasonably easy, but if anyone has different code - I would rather reuse it in tomcat-lite :-) BTW - there is a typo in javax.servlet.ServletRegistration - should be Dynamic, not Dynmaic. I can fix it next time I get some free time... Costin - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 3.0 annotations ?
On Aug 4, 2009, at 1:18 PM, Filip Hanik - Dev Lists wrote: does it load all the classes? IIUC no, it uses asm for byte-code inspection without loading classes. thanks david jencks I think byte code check might make more sense if that is the case Filip On 08/04/2009 01:50 PM, David Jencks wrote: We use xbean-finder for this in geronimo/openejb/etc. http://repo2.maven.org/maven2/org/apache/xbean/xbean-finder/3.5/ https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder We also have a servlet 3.0 spec jar I've been trying to keep up to date with the glassfish javadocs. https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/specs/geronimo-servlet_3.0_spec/1.0-EA-SNAPSHOT/ https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec thanks david jencks On Aug 4, 2009, at 11:11 AM, Costin Manolache wrote: Hi, anyone working on the @Filter, @Servlet annotation scanner for tomcat-trunk ? If I'm understanding it correctly, tomcat will have to read all files in classes and lib and look for the annotation - and I would guess the only reasonable option is looking at bytecode. I checked BCEL - seems reasonably easy, but if anyone has different code - I would rather reuse it in tomcat-lite :-) BTW - there is a typo in javax.servlet.ServletRegistration - should be Dynamic, not Dynmaic. I can fix it next time I get some free time... Costin - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Jaspic (jsr 196) support in tomcat
While looking into some problems with the tomcat integration in geronimo around ejb web service security and the jacc integration I realized the simplest way to fix all the problems at once was to rewrite web security including jaspic support. The new implementation is at https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat6/src/main/java/org/apache/geronimo/tomcat/security and it needs a couple ContextConfig classes in the parent directory to get installed and work. The main idea here is to replace the Realm with a SecurityValve that delegates authentication decisions to an authenticator and authorization decisions to an authorizor. The authenticator is similar in concept to the jaspic ServerAuthContext but more adapted to servlets. The authorizor exposes the authorization decisions called for by the jaspic spec servlet profile. I have authenticators for the build in auth methods and also a jaspic adapter. So far I have only a jacc authorizer but it should be easy to adapt the old code to write one that uses the tomcat constraint objects. The part that doesn't fit very well is that the Realm concept is used to implement isUserInRole. I wrote a Realm implementation that uses JACC for this. If I were to consider a patch to tomcat for this I would eliminate the Realm concept and have a new interface for the isUserInRole decision. I have not yet tried running the jaspic tck on this so don't know how many bugs there are in the jaspic adapter. Regular security seems to work OK. Most likely I will spend a little time on this in the next few days. I developed most of the ideas for the web-adapted interface and adapter working on the jetty jaspic integation. In particular jetty wanted to be able to run without the jaspic api jar, and since this seemed like it might be desirable for tomcat as well, no jaspic classes are used outside the jaspic adapter. I think it would be great if the tomcat community integrated some version of this code in perhaps tomcat 7 but I do not expect to be providing any patches to tomcat for this. I'm happy to talk about the code, but I'm more likely to see discussion on the geronimo dev list. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Remove Realm from GenericPrincipal
On Jul 16, 2009, at 5:16 PM, Mark Thomas wrote: As a result of looking into https://issues.apache.org/bugzilla/show_bug.cgi?id=40881, I discovered that the only use made of the Realm attribute of GenericPrincipal is to control whether or not a debug message is logged in RealmBase.hasRole() Given that the Realm is the reason that GenericPrincipal is not Serializable, I'd like to propose the following changes for Tomcat 7. 1. Remove the Realm from GenericPrincipal 2. Make GenericPrincipal Serializable 3. Take advantage of this to simplify the Cluster code As a by product, this should also address bug 40881 by allowing any Realm that uses any Serializable Principal to work with clustering. Thoughts? I'm not sure exactly how the GenericPrincipal fits into tomcat security, but you might want to consider that jaspic requires that whatever Principal is set up by the authentication context (and communicated to the server through the somewhat bizarre mechanism of a callback handler) must be the principal returned from getUserPrincipal. My conclusion from this is that a reasonable architecture involves some kind of UserIdentity object that contains the identity info including the principal but that trying to enforce usage of a particular principal class is not a good idea. cf the jaspic integration I mentioned the other day. thanks david jencks Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
One way to maintain a tomcat fork built with maven (was: Mavenized tomcat build)
I'd like to apologize for the miscommunication engendered by this thread. It's very clear to me that what I thought I was communicating did not get through. This attempt to clarify will probably not fare any better :-( I don't expect tomcat to consider changing its build system and certainly don't want to participate in any discussion of the tomcat build system. I don't expect tomcat to release anything from trunk or any branch in particular. I do suspect that there are projects that, like geronimo, use maven and are faced with maintaining a tomcat fork. For such projects, (NOT TOMCAT ITSELF) the tools we developed at geronimo might be useful. Once again, this is NOT a proposal for tomcat to use maven. If you guys happen to decide you want to I'd be happy to give advice, but I'm not proposing it and don't want to talk about whether it would be a good idea. On Jul 11, 2009, at 8:38 AM, Costin Manolache wrote: I think there are few separate issues: 1, If there is a patch that needs to be applied by geronimo to use tomcat or they are blocked by missing something from a release - we should review this again. I think we can do a tomcat-geronimo release specifically for them as worse case ( well, we did it for j2ee ref impl in the old days - all we need is a branch ), or make sure it gets in the next release, Personally, since geronimo now has a working method of maintaining a fork of the 6.0 branch including the needed patches from trunk, I would prefer to see any development effort expended on servlet 3.0 features. If tomcat 7 supports servlet 3.0 and is based on trunk geronimo won't need a fork any more. 2. For Maven support - if maven can support building tomcat, I don't see any problem. But moving the code around and changing code just so we can be built by maven - I don't like that. The current patch is even worse - it seems to create 2 different source trees for tomat, and since maven can also checkout the source and people may use the maven-source... Once again, this was never intended to be about the tomcat build system. 3. For having maven-like 'modules' with strict build and runtime dependencies - been there. There are plenty of large projects using tomcat approach - i.e. allow circular dependencies between packages and build either one big jar or few jars. I think the benefits of more reuse and code sharing are bigger than the problems - i.e. mostly not able to break into many directories and build with maven, and arcane ways to break circular dependencies. I'm still mystified by this. I have no problems with circular package dependencies within a single jar but I really don't understand why you'd have 2 jars neither of which can be used without the other. Wouldn't it be simpler for everyone to just have one jar? Costin On Fri, Jul 10, 2009 at 11:43 PM, Mladen Turkmt...@apache.org wrote: Filip Hanik - Dev Lists wrote: If Geronimo needs a better way to download and integrate Tomcat's JAR's lets focus on that, and not make this into another Maven vs ANT topic, cause I don't think that was the intention. Agreed. However we should really find a way to deal with eclipse repository since they tend to change the download system quite often (only external dependency). Since we cannot copy that to the ASF due to license issue we could reuse the backup system on tomcat.heanet.ie (like we did for Tomcat Native until ASF resolved the crypto software issues) to allow the historic builds. I somehow doubt Maven can solve this problem anyhow, and downloading a repo with 10+ eclipse JDT's would be insane just to build eg. 6.0.20 in 5 years from now. ? maven only downloads the dependencies you require, not entire repos. Probably I don't understand what you are saying. Other things is trivial, just testing the dist.apache.org with archive.apache.org as fallback for the remaining dependencies. I didn't mention this before either but I don't understand why tomcat is rebuilding the eclipse code. The released eclipse jdt jar available from maven central seems to work fine. thanks david jencks Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Mavenized tomcat build
I am well aware that the tomcat developers regard ant as the one true build system, so please note that I am not suggesting that tomcat adopt maven. However I think it is just barely conceivable that other projects are facing the same sort of problems as geronimo and might find this mavenization technique useful or that the tomcat developers might want to address some of the difficulties I encountered. Backgound... More than two years ago the tomcat community accepted a proposal I made to make annotation processing more flexible and work better with the geronimo integration, and applied it to trunk. I naively thought that this meant it would eventually get released in a 6.x tomcat. Since then geronimo has been shipping with patched tomcat jars that are based on a released tomcat 6.0.x version with the annotation processing changes patched in. However our process for producing these jars broke and our method for distributing the jars creates a lot of problems with maven infrastructure. The cleanest solution appears to be for geronimo to set up a maven build that produces the tomcat jars we need under a geronimo groupId. Problem... Geronimo needs a repeatable process for getting tomcat source code into a maven project preserving svn history so we can then apply patches and know what we are building. Results I wrote a maven archetype to set up the basic structure of a mavenized tomcat build and a bunch of bash scripts to svn cp the tomcat source from a tag into this maven project framework. The contents of the maven subprojects attempts to follow the contents of the jars shipped by tomcat, although this is not completely possible (see below). Archetype: source https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype snapshot https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/tomcat-parent-archetype/1.0-SNAPSHOT Sample result projects, patched with what I think are the annotation handling changes: https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-6.0.18 https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-6.0.20 snapshot https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/ Difficulties... One of the great features of an ant build such as that used by tomcat where all the classes are compiled at once and then distributed into jars is that the contents of the resulting jars can be completely randomized and have circular dependencies so that they all have to be loaded in the same classloader. AFAICT Tomcat has taken full advantage of this impressive feature with the catalina and coyote jars; at any rate I couldn't figure out how to disentangle them. So I combined them in the mavenized project. :-) well, seriously, you might want to look into fixing this in tomcat 7. I don't know of any practical way to enforce or check this other than using a maven like project layout whether you use maven, ant, ivy, or something else. Maybe an ant expert can come up with something. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
jaxb alternative to digester
Geronimo's tomcat integration has up till recently used tomcat server components wrapped in geronimo gbean components, and server configuration through gbean configuration. This is less flexible and less convenient than server.xml configuration, and we've had several requests to provide configuration via server.xml. However, we need to typically use subclasses of the tomcat server classes. Unfortunately I have an unreasoning hatred of digester formed when I tried to debug what it was doing. After a little bit of thought I came up with an alternative jaxb based system. There' s a schema I reverse engineered from digester rules, and a bunch of classes modified from ones jaxb generated from the schema. After generating the classes I added some build methods that go through the jaxb model tree and construct the tomcat components and wire them together. This seems to work fine and I find it easy to modify and debug and understand what it's doing. In case anyone is interested in looking at this it's in our geronimo- tomcat6 module in the model package. The schema is under src/main/ xsd. https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat6 thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Mavenized tomcat build
On Jul 10, 2009, at 5:01 PM, Filip Hanik - Dev Lists wrote: On 07/10/2009 05:19 PM, Yoav Shapira wrote: On Fri, Jul 10, 2009 at 6:26 PM, David Jencksdavid_jen...@yahoo.com wrote: I am well aware that the tomcat developers regard ant as the one true build Having now used Maven 2.x for a couple of years, it Works. +1 for trying it for Tomcat. -1, my lunch is not long enough to download the internet ;) This discussion has been had many times, I've tried to look at it from many different perspectives, but have yet not seen a reason to switch. but we do publish our JARs to the Maven repo for other projects that are using Maven http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/tomcat/ If Geronimo needs a better way to download and integrate Tomcat's JAR's lets focus on that, and not make this into another Maven vs ANT topic, cause I don't think that was the intention. I thought I made it pretty clear we need you to make a release from trunk. Like I said its been more than 2 years since tomcat accepted the annotations patch with no trunk release but general agreement that the patch couldn't go into the 6.0.x branch. david jencks Filip Yoav - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
I don't really know what you guys are talking about but it might be you are looking for a cross-platform multiplexing asynchronous message exchange system. If so you might look into activemq's openwire transport. IIUC they have a message grammar that is compiled into code for various platforms including java, .net, c++, etc. thanks david jencks On Apr 4, 2009, at 8:42 AM, Costin Manolache wrote: On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk mt...@apache.org wrote: Costin Manolache wrote: So in essence you have a new protocol but the sole difference is how you describe it. The API can be something like: - legacyRequest(RequestMessage) - whatever we have in the current AJP protocol - getServerLoad() and whatever new we wanted to add Instead of defining AJP extensions, we just pick one of the marshalling libs and use them for encoding the new methods. Again, you are presuming a new protocol and IMO everyone here are just getting nasty red spots on their faces when you do such a thing ;) My understanding was that some people want to add features to mod_jk to support extended load balancing, eventually the fancy async stuff, etc. I can't see how this can be done without proto changes - current AJP won't work. And this is quite specific to tomcat, you can't dump it on incubator. What I'm trying to suggest is that a 'new protocol' ( as in - enhanced AJP, AJP2.0, etc ) is not a good idea. Instead the extensions needed should be done by using existing libraries and protocols, and when this is stable the AJP protocol should be deprecated (thus reducing the code size). Thrift/protobufs can be used quite easily on top of an existing transport, as payload, and can represent all the messages you want. Costin - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
On Apr 4, 2009, at 3:01 PM, Xie Xiaodong wrote:
Hello, Dear All,
First, thank you very much for you valuable comments, Mark.
I've revised my project plan based on the comments of Mark, since
I could
not edit my proposal any longer, I wrote the revised version of
project plan
in a comment of my proposal, you can find it for certain by
searching the
Show Student Proposal page with xiaodong xie wrote. Sorry for this
inconvenience.
I am now getting myself familiar with the Servlet Container
Profile of
JSR-196 in order to move the Authentication funcationality of valve
into
some independent structure consistence with JSR-196. This part will
be added
into my project proposal in some comment later.
Any more comments, feedback and criticism to my proposal are
welcomed.
While it is possible to implement the built in auth methods (BASIC,
DIGEST, FORM, CLIENT_CERT) as jaspi auth modules it's not as
efficient as having a more tomcat-specific auth method. The important
part is really having a validate request method called before the web
resource constraint check and a secure response method called after
the request has been processed. There are a lot of opportunities for
improved caching if you don't follow the jaspi model exactly, mostly
by letting the authenticator return the user identity rather than
passing in a brand new Subject instance for each request.
I recommend that the valve or filter look something like this:
check user data constraints
Status status = validate request
if (status == success) {
check web resource constraints
process request
secure response
}
//otherwise the validate request call will have set up an appropriate
response to continue the authentication message exchange
validate request and secure response are delegated to some kind of
authenticator similar to but more efficient than a jaspi auth context
constraint checking can either be (abstract) methods on the (base)
valve or delegated to some other object. The point here is to easily
support both constraint based checking (as done in tomcat today) and
jacc based permission checking (as done in geronimo and presumably
other javaee integrations such as jboss)
thanks
david jencks
--
Sincerely yours and Best Regards,
Xie Xiaodong
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
On Apr 1, 2009, at 9:20 PM, Rahul Saxena wrote: Is Tomcat currently supports JSR 196?? no. I've been planning to work on jsr 196 for tomcat but haven't had much time. I implemented support for jetty. Geronimo has a jsr 196 provider implementation but I haven't been able to pry the tck out of sun yet. I'd doubt there would be a lot of trouble doing the server bits of jsr 196 in a filter. However note that, unlike with web.xml specified filters, authentication occurs once before the request gets to the first web.xml specified filter and does not occur again for dispatches. If you can arrange for this with a filter then the rest of the jsr 196 implementation should not be too hard. thanks david jencks On Thu, Apr 2, 2009 at 3:02 AM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: If we derive several servlets form s generic servlet and then if we specify a filter for that generic servlet, will that filter work for all derived servlets or not??? Filters and servlets are independent. Any filter should work with any servlet. Mark Rahul Saxena B.Tech Part III Computer Science And Engineering IT BHU - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
On Apr 2, 2009, at 12:32 AM, Rahul Saxena wrote: JSR 196 can be implemented only at the service levelIs it true?? not sure exactly what you mean each web app needs something to do its authentication, whether it be a standard FORM/BASIC/DIGEST/ CLIENT_CERT auth thingy or a jsr 196 auth thingy. The auth thingy gets called once per request before the request gets to any filters or servlets. thanks david jencks -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r746321 - in /tomcat/trunk/java: javax/servlet/resources/web-app_2_4.xsd org/apache/catalina/startup/WebRuleSet.java
umm, concatinate concatenate
david jencks
On Feb 20, 2009, at 10:17 AM, ma...@apache.org wrote:
Author: markt
Date: Fri Feb 20 18:17:29 2009
New Revision: 746321
URL: http://svn.apache.org/viewvc?rev=746321view=rev
Log:
Fix spelling
Modified:
tomcat/trunk/java/javax/servlet/resources/web-app_2_4.xsd
tomcat/trunk/java/org/apache/catalina/startup/WebRuleSet.java
Modified: tomcat/trunk/java/javax/servlet/resources/web-app_2_4.xsd
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/resources/web-app_2_4.xsd?rev=746321r1=746320r2=746321view=diff
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/java/javax/servlet/resources/web-app_2_4.xsd
(original)
+++ tomcat/trunk/java/javax/servlet/resources/web-app_2_4.xsd Fri
Feb 20 18:17:29 2009
@@ -99,7 +99,7 @@
file must not contain multiple elements of session-config,
jsp-config, and login-config. When there are multiple elements of
welcome-file-list or locale-encoding-mapping-list, the container
- must concatinate the element contents. The multiple occurance
+ must concatinate the element contents. The multiple occurrence
of the element distributable is redundant and the container
treats that case exactly in the same way when there is only
one distributable.
Modified: tomcat/trunk/java/org/apache/catalina/startup/
WebRuleSet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/WebRuleSet.java?rev=746321r1=746320r2=746321view=diff
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/java/org/apache/catalina/startup/WebRuleSet.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/startup/WebRuleSet.java
Fri Feb 20 18:17:29 2009
@@ -539,7 +539,7 @@
throws Exception {
if (isLoginConfigSet){
throw new IllegalArgumentException(
-login-config element is limited to 1 occurance);
+login-config element is limited to 1 occurrence);
}
isLoginConfigSet = true;
}
@@ -560,7 +560,7 @@
throws Exception {
if (isJspConfigSet){
throw new IllegalArgumentException(
-jsp-config element is limited to 1 occurance);
+jsp-config element is limited to 1 occurrence);
}
isJspConfigSet = true;
}
@@ -581,7 +581,7 @@
throws Exception {
if (isSessionConfigSet){
throw new IllegalArgumentException(
-session-config element is limited to 1 occurance);
+session-config element is limited to 1 occurrence);
}
isSessionConfigSet = true;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r731967 - in /tomcat/trunk: ./ java/javax/servlet/ java/javax/servlet/annotation/ java/javax/servlet/http/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/a
cf
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec
Is there a new draft of 3.0 or is this for the first public draft?
thanks
david jencks
On Jan 6, 2009, at 7:15 AM, ma...@apache.org wrote:
Author: markt
Date: Tue Jan 6 07:15:32 2009
New Revision: 731967
URL: http://svn.apache.org/viewvc?rev=731967view=rev
Log:
First attempt at updating the javax.servlet package for the 3.0 spec
It compiles and runs but 99.9% of the implementation is stubbed out
and marked with TODO SERVLET3
Added:
tomcat/trunk/java/javax/servlet/AsyncContext.java (with props)
tomcat/trunk/java/javax/servlet/AsyncEvent.java (with props)
tomcat/trunk/java/javax/servlet/AsyncListener.java (with props)
tomcat/trunk/java/javax/servlet/DispatcherType.java (with props)
tomcat/trunk/java/javax/servlet/SessionCookieConfig.java (with
props)
tomcat/trunk/java/javax/servlet/SessionTrackingMode.java (with
props)
tomcat/trunk/java/javax/servlet/annotation/
tomcat/trunk/java/javax/servlet/annotation/InitParam.java (with
props)
tomcat/trunk/java/javax/servlet/annotation/ServletFilter.java
(with props)
tomcat/trunk/java/javax/servlet/annotation/WebServlet.java
(with props)
tomcat/trunk/java/javax/servlet/annotation/
WebServletContextListener.java (with props)
Modified:
tomcat/trunk/TOMCAT-7-RELEASE-PLAN.txt
tomcat/trunk/build.properties.default
tomcat/trunk/java/javax/servlet/ServletContext.java
tomcat/trunk/java/javax/servlet/ServletRequest.java
tomcat/trunk/java/javax/servlet/ServletRequestWrapper.java
tomcat/trunk/java/javax/servlet/http/Cookie.java
tomcat/trunk/java/org/apache/catalina/connector/Request.java
tomcat/trunk/java/org/apache/catalina/connector/RequestFacade.java
tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
tomcat/trunk/java/org/apache/catalina/core/
ApplicationContextFacade.java
tomcat/trunk/java/org/apache/catalina/core/Constants.java
tomcat/trunk/java/org/apache/catalina/core/DummyRequest.java
tomcat/trunk/java/org/apache/jasper/servlet/JspCServletContext.java
Modified: tomcat/trunk/TOMCAT-7-RELEASE-PLAN.txt
URL:
http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-7-RELEASE-PLAN.txt?rev=731967r1=731966r2=731967view=diff
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/TOMCAT-7-RELEASE-PLAN.txt (original)
+++ tomcat/trunk/TOMCAT-7-RELEASE-PLAN.txt Tue Jan 6 07:15:32 2009
@@ -22,8 +22,10 @@
=
1. Update trunk with new API from Servlet Spec 3.0 PR
+ - Done
2. Provide NOOP implementations with TODO SRV3 markers so it will
build
+ - Done
3. Implement all the new Servlet 3 features
Modified: tomcat/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=731967r1=731966r2=731967view=diff
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/build.properties.default (original)
+++ tomcat/trunk/build.properties.default Tue Jan 6 07:15:32 2009
@@ -25,7 +25,7 @@
#
-
# - Vesion Control Flags -
-version.major=6
+version.major=7
version.minor=0
version.build=0
version.patch=0
Added: tomcat/trunk/java/javax/servlet/AsyncContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/AsyncContext.java?rev=731967view=auto
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/java/javax/servlet/AsyncContext.java (added)
+++ tomcat/trunk/java/javax/servlet/AsyncContext.java Tue Jan 6
07:15:32 2009
@@ -0,0 +1,33 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one or more
+* contributor license agreements. See the NOTICE file distributed
with
+* this work for additional information regarding copyright ownership.
+* The ASF licenses this file to You under the Apache License,
Version 2.0
+* (the License); you may not use this file except in compliance
with
+* the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an AS IS BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package javax.servlet;
+
+/**
+ * @since 3.0
+ * $Id$
+ * TODO SERVLET3
+ */
+public interface AsyncContext {
+ServletRequest getRequest();
+ServletResponse getResponse();
+boolean hasOriginalRequestAndResponse();
+void forward();
+void forward(String path);
+void forward(ServletContext context, String path);
+void complete();
+void
Re: svn commit: r729688 - in /tomcat/trunk: build.xml res/maven/catalina.pom res/maven/jasper.pom res/maven/mvn-pub.xml
Since you are putting this in a separate jar, what would you think of
using a package name appropriate for the tomcat project, since these
classes are tomcat/jasper specific and not a product of apache as a
whole?
thanks
david jencks
On Dec 27, 2008, at 2:17 PM, ma...@apache.org wrote:
Author: markt
Date: Sat Dec 27 14:17:49 2008
New Revision: 729688
URL: http://svn.apache.org/viewvc?rev=729688view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46344
Put the org.apache classes in a separate jar
Maven changes need validating.
Modified:
tomcat/trunk/build.xml
tomcat/trunk/res/maven/catalina.pom
tomcat/trunk/res/maven/jasper.pom
tomcat/trunk/res/maven/mvn-pub.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=729688r1=729687r2=729688view=diff
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Sat Dec 27 14:17:49 2008
@@ -73,6 +73,7 @@
property name=catalina-ha.jar value=${tomcat.build}/lib/
catalina-ha.jar/
property name=catalina-ant.jar value=${tomcat.build}/lib/
catalina-ant.jar/
property name=tomcat-coyote.jar value=${tomcat.build}/lib/
tomcat-coyote.jar/
+ property name=tomcat-api.jar value=${tomcat.build}/lib/tomcat-
api.jar/
property name=jasper.jar value=${tomcat.build}/lib/jasper.jar/
property name=jasper-el.jar value=${tomcat.build}/lib/jasper-
el.jar/
@@ -198,8 +199,11 @@
include name=org/apache/juli/** /
/patternset
- patternset id=files.catalina
+ patternset id=files.tomcat-api
include name=org/apache/* /
+ /patternset
+
+ patternset id=files.catalina
include name=org/apache/catalina/** /
include name=org/apache/naming/** /
!-- Modules --
@@ -235,7 +239,6 @@
/patternset
patternset id=files.jasper
-include name=org/apache/* /
include name=org/apache/jasper/** /
/patternset
@@ -335,12 +338,15 @@
!-- Catalina GroupCom/Tribes JAR File --
jarIt jarfile=${catalina-tribes.jar} filesId=files.catalina-
tribes/
- !-- Catalina Cluster/HA JAR File --
+!-- Catalina Cluster/HA JAR File --
jarIt jarfile=${catalina-ha.jar} filesId=files.catalina-ha/
!-- Catalina Ant Tasks JAR File --
jarIt jarfile=${catalina-ant.jar} filesId=files.catalina-
ant/
+!-- Tomcat API JAR File --
+jarIt jarfile=${tomcat-api.jar} filesId=files.tomcat-api/
+
!-- Protocol handlers - Coyote --
jarIt jarfile=${tomcat-coyote.jar} filesId=files.tomcat-
coyote/
Modified: tomcat/trunk/res/maven/catalina.pom
URL:
http://svn.apache.org/viewvc/tomcat/trunk/res/maven/catalina.pom?rev=729688r1=729687r2=729688view=diff
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/res/maven/catalina.pom (original)
+++ tomcat/trunk/res/maven/catalina.pom Sat Dec 27 14:17:49 2008
@@ -48,5 +48,11 @@
version@MAVEN.DEPLOY.VERSION@/version
scopecompile/scope
/dependency
+dependency
+ groupIdorg.apache.tomcat/groupId
+ artifactIdtomcat-api/artifactId
+ version@MAVEN.DEPLOY.VERSION@/version
+ scopecompile/scope
+/dependency
/dependencies
/project
Modified: tomcat/trunk/res/maven/jasper.pom
URL:
http://svn.apache.org/viewvc/tomcat/trunk/res/maven/jasper.pom?rev=729688r1=729687r2=729688view=diff
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/res/maven/jasper.pom (original)
+++ tomcat/trunk/res/maven/jasper.pom Sat Dec 27 14:17:49 2008
@@ -64,5 +64,11 @@
version@MAVEN.DEPLOY.VERSION@/version
scopecompile/scope
/dependency
+dependency
+ groupIdorg.apache.tomcat/groupId
+ artifactIdtomcat-api/artifactId
+ version@MAVEN.DEPLOY.VERSION@/version
+ scopecompile/scope
+/dependency
/dependencies
/project
Modified: tomcat/trunk/res/maven/mvn-pub.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn-pub.xml?rev=729688r1=729687r2=729688view=diff
=
=
=
=
=
=
=
=
==
--- tomcat/trunk/res/maven/mvn-pub.xml (original)
+++ tomcat/trunk/res/maven/mvn-pub.xml Sat Dec 27 14:17:49 2008
@@ -135,6 +135,7 @@
doMavenDeploy artifactId=servlet-api/ !--Deploy Servlet
api--
doMavenDeploy artifactId=el-api/ !--Deploy expression
lanaguage api--
doMavenDeploy artifactId=jsp-api/ !--Deploy JSP api--
+doMavenDeploy artifactId=tomcat-api / !--Deploy Tomcat
api--
doMavenDeploy artifactId=juli jarFileName=tomcat-juli.jar/
!--Deploy JULI--
doMavenDeploy artifactId=tribes jarFileName=catalina-
tribes.jar/ !--Deploy Tribes--
doMavenDeploy artifactId=jasper-el/ !--Deploy Jasper EL--
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h
Re: NTLMAuthenticator for Apache Tomcat 6.0.18 (Intranet within a Microsoft domain)
I'm a little confused about your goals
On Nov 10, 2008, at 11:41 AM, Christophe Dupriez wrote:
Hi Tomcat Developpers!
I wanted to:
* centralize the parameterization of user authentication at the
container level;
What do you mean by this and how is this expressed?
* have a simple NTLM authentication for intranet users;
* be able to run Tomcat in a Microsoft Active Directory network
where the server is secured (absolutely no login allowed to regular
users)
Do you mean that you want intranet users to have their local MAD login
propagated automatically to the tomcat server with no explicit tomcat
login required? If so the official way to support this is via
the JASPI spec (jsr 196) and (IIUC) a SPNEGO server authentication
module such as that at http://spnego.ocean.net.au/ (jboss might have
another one???)
At this point tomcat does not have a jaspi implementation although I
expect it to be a part of javaee 6, and I'm mostly interested in
trying to understand what you are trying to do rather than suggesting
an implementation strategy.
thanks
david jencks
There is a Microsoft “specification” (bug?) by which all LDAP binds
are evaluated on the Domain Server (like if the user was attempting
to login on the Domain Server).
It would be better to have binds evaluated as if they were
originating from the LDAP client machine (the Tomcat Server).
To circumvent this, I have been obliged to remove the binding (the
password checking) but to ensure that it is NTLM (and nothing else)
which provides the username.
The users are therefore automatically logged with the username used
to log on their PC.
The attached patch is for current Apache Tomcat sources (6.0.18).
It adds:
An NTLM Authenticator: nothing to configure except in the web.xml of
each application:
login-config
auth-methodNTLM/auth-method
realm-nameThisIsApassword/realm-name
/login-config
The realm-name is the “password” which ensures that authentication
is done by NTLM and no other method.
A very long password is strongly recommended.
A modified JNDI Realm with new parameters:
preAuthenticatedPassword=”ThisIsApassword”
This to suppress password checking if preAuthenticatedPassword is
provided.
userIdentification=”userPrincipalName” provides a standardized
username, whatever the retrieved user name (case of complex
userSearch patterns)
userNamePrefix and userNameSuffix
This to suppress a prefix and/or a suffix from username before
returning it to the application: good to suppress domain
identification, etc.
When you user complex userSearch pattern, this can be very useful.
Example:
userSearch=(|(sAMAccountName={0})([EMAIL PROTECTED])
(userPrincipalName={0}))
userIdentification=userPrincipalName userNamePrefix=”domain\” [EMAIL PROTECTED]
”
Hopes this can be useful to the community!
Please do not hesitate to ask me if something can be done to make
this contribution perennial.
Wishing you a very nice day,
Christophe Dupriez
Centre Antipoisons - Antigifcentrum
C/o Hôpital Central de la Base Reine Astrid
Rue Bruyn - 1120 Bruxelles - Belgique
tel 32-(0)2.264.96.36 fax 32-(0)2.264.96.46
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: InstanceManager javadoc
On Jun 29, 2008, at 9:43 AM, Costin Manolache wrote: Also, is there any documentation (or anyone who can explain) DefaultInstanceManager.processAnnotations() ? Sorry, I'm a bit confused, lots of calls and structures. I'm interested in particular in the 'injectionMap' - from what I read, the method takes the name of the field ( say 'foo' ), and even if it has no annotations it'll still inject it if something named 'foo' is found. The injectionMap would have something like foo-jndiNameForFoo. This seems pretty dangerous - my understanding was that you need to have an annotation in order to have the Resource injected. you can also set up injections via web.xml. Even without this how is this dangerous? The injection map isn't supplied by user code but by server code. I'm not sure if the standalone tomcat annotation support actually does anything. I wrote it to mimic the functionality of the original standalone support (which again IIRC didn't appear to connect to anything useful) when getting annotation/injection support to work in a way useful to geronimo. Geronimo uses xbean-reflect to handle object creation and configuration which is a very elegant solution IMO. I'll try to find some time to remind myself of how this works and comment on it but it may be a while. thanks david jencks I'll try searching the mail archives - the comments in the submits don't seem to have more info than the javadocs or comments... Again, sorry if it's something obvious. Costin On Sat, Jun 28, 2008 at 10:26 AM, Costin Manolache [EMAIL PROTECTED] wrote: Hi, Just one small 'feature' request: Since InstanceManager in tomcat6 is in such a package ( org.apache - do we even have permission to use this ??), could we have some javadocs ? What are the current plans for the annotation processing / dep injection ? Is this class the 'root' of all future annotation processing ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Apr 30, 2008, at 10:28 AM, Costin Manolache wrote: On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens [EMAIL PROTECTED] wrote: Regarding HttpService - I don't think it's a good idea for tomcat. One of the major problems with OSGI ( and we need to make sure we don't fall in this trap ) is the re-invention of common APIs - logging, servlet interfaces, etc. As a bit of background. The logging and Http Service API are from 1999. At that time there was no dominant common logging API (neither in Java SE nor in open source), and the Http Service API is 100% based on the, at that time, standard Servlet API (it uses javax.servlet.http), it only provides an API to dynamically register and unregister servlets, which is still lacking in the current Servlet API. Regarding 'dynamic register/unregister' - the servlet API defines one way to do this, i.e. war and the deployment. There is no standard API to install/uninstall/start/stop a .war umm, jsr-88?? david jencks - but HttpService is not that either. Runtime config changes ( adding/removing servlets without web.xml changes and re-deployment ) is not specified, but it's a whole different discussion for the JSR people to solve, I'm pretty sure it'll be different from HttpService. It would be quite inappropriate for tomcat to not use the standard deployment/configuration mechanism for servlets. So using or implementing any of the OSGI-re-defined service interfaces in tomcat would be a hard sale IMO. Well, I do not see that this is an dichotomy. By nature of being the RI, you must follow the JSR. However, it would not be hard to provide the Http Service as an additional component. If Tomcat provides an API to dynamically register servlets, it would be trivial for someone to provide an OSGi compatibility bundle, just like people are doing it today. But it would be a nice service to get this from the horse's mouth. I am sure people are willing to provide this code. A lot of people would like for tomcat to provide more jetty-like APIs for programmatic configuration ( and in a way it is already possible - just not easy ). As an API, HttpService is way off - in '99 and servlet 2.1 it may have been valuable. Let's keep HttpService for a different discussion :-) In reality, this is a rather crude approach because in well designed systems the coupling between bundles is minimal. At this point in time, services usually start to look more attractive because they provide an API to allow dynamic updates without crudely stopping all bundles in the module dependency graph (which in non-service based systems, and especially require- bundle based systems tends to become the whole system). And a service is just a POJO that is registered under one or more interfaces. By allowing it to withdrawn at any moment in time, as well as registered by multiple independent parties, OSGi provides a good abstraction of this dynamism. And there is no Java counterpart for this. Actually - JMX provides a lot of this dynamism. Tomcat is using a lot of JMX ( and hopefully will use more ), and provide very similar model with OSGI services. they fell in love and the service layer was a major part of their infatuation. They realized very quickly how they could leverage the services as beans in their model and the advantages of dynamism without rebooting. To clarify: updating webapps in tomcat without rebooting has been around for many years :-). Webapps are quite similar with the bundles - it would be interesting to see if we could use OSGI classloader instead of ours, but I don't think that's a real problem. People are looking for 'gapless' restart, i.e. users who have an active session continuing to use the old version ( or some magic way to migrate the session - but that's likely impossible in most real cases, i.e. if code changes happen ). OSGi alone can't solve this. A whole different class of users would like to see _less_ dynamism - i.e. embedding tomcat as a jar and using simple APIs and no class loaders or config files. In both high-end servers and low-end embedding this is a very important use case. The problem I would like to see solved in tomcat is breaking it up in modules - i.e. separating all the optional parts and having a way to ship a really minimal core and a good way to release and deploy add-on bundles. OSGi may be a good way to do this. I think the requirements are: - provide a way for different tomcat components and core to be packaged as OSGi bundles, using manifests and maybe optional activators if it can't be avoided ( as long as tomcat doesn't depend on it ). I think this is an easy sell, I can't think of any good technical reasons not to do it. - break tomcat release ( for 7.0 or 6.5 or whatever trunk will be released as ) into just core ( minimal servlet impl ) and bundles - find a easy way for people to download/install all modules
Re: Osgifing Tomcat
On Apr 24, 2008, at 11:11 PM, Henri Gomez wrote: I've heard various claims of this nature from osgi zealots, but when talking to apparent experts the only things resembling this they seemed to know about were grad student experiments that did not have production use as even a far-in-the-future goal. Do you know of any actual examples of this kind of behavior that actually work under load? We'll see how OSGI works underload with Glassfish v3. Are they planning to support gapless redeployment of web apps using only osgi features, with no other servlet container support? If so is can you point to an explanation of how they plan to do this? BTW, performance is only a point in an IT infrastructure, ease of deployment and administration is often more important (from my day to day experience) I think its entirely possible for a servlet container to support gapless redeployment of web apps. I don't see how this can be supplied or even helped by osgi itself. As far as I can see, osgi has a fairly nice classloader that unfortunately requires all jars to be osgi-ified (a process that will take years and, judging by the semantically similar info in maven poms, mostly result in wrong information) and a fairly limited service and service dependency model, plus a lot of hype. For instance I've seen this claim several times that osgi will by some magic make hot updates of production systems just work, but no one seems to be able to tell me how its supposed to work. The only actual info I've heard was about a student experiment that clearly would not work in a high-load environment. Personally I don't think this kind of feature will work as a component container feature without transactional memory; the only place I know of this being available is in haskell. just my highly biased $0.02 david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Apr 22, 2008, at 6:25 PM, Paul Benedict wrote: Is that enough so that web applications, either as a whole or in partial, can be upgraded without stopping them? It's my understanding that if web applications are loaded in an OSGi classloader, these kind of things are possible. I've heard various claims of this nature from osgi zealots, but when talking to apparent experts the only things resembling this they seemed to know about were grad student experiments that did not have production use as even a far-in-the-future goal. Do you know of any actual examples of this kind of behavior that actually work under load? thanks david jencks Paul On Tue, Apr 22, 2008 at 7:24 PM, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: Henri Gomez wrote: Hi to all, Did there is plans, ideas or interest around about OSGI-fing Tomcat ? I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt my original plan was just to make sure all the MANIFEST.MF for each file would have enough in it so that each JAR can be a OSGi bundle. after that, one can add on as much or as little as one wishes Filip Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug in forwarding HEAD requests
On Mar 7, 2008, at 12:46 PM, Mark Thomas wrote: David Jencks wrote: I wondered if there would be consensus that this is a bug +1 and the proposed fix is appropriate? +1 Please raise a BZ ticket so this doesn't get lost. https://issues.apache.org/bugzilla/show_bug.cgi?id=44562 I did not copy over the patch from the jira issue I can if desired. thanks! david jencks Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible bug in forwarding HEAD requests
A geronimo user has recently reported a problem forwarding/including
HEAD requests and it looks like a bug to me.
https://issues.apache.org/jira/browse/GERONIMO-3896
briefly...
tomcat complains:
Servlet.service() for servlet SimpleDispatchServlet threw exception
javax.servlet.ServletException: Original SevletResponse or wrapped
original ServletResponse not passed to
RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
at
org.apache.catalina.core.ApplicationDispatcher.checkSameObjects
(ApplicationDispatcher.java:985)
...
The relevant code seems to be in javax.servlet.http.HttpServlet
protected void doHead(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException
{
NoBodyResponse response = new NoBodyResponse(resp);
doGet(req, response);
response.setContentLength();
}
which is fine but
class NoBodyResponse implements HttpServletResponse {
rather than
class NoBodyResponse extends HttpServletResponseWrapper {
The patch attached to the jira issue makes this change and adapts
NoBodyResponse to be a subclass of HttpServletResponseWrapper and the
user reports that it fixes the problem. I don't know if there would
be formatting issues applying the patch to tomcat's copy of the spec
classes.
I wondered if there would be consensus that this is a bug and the
proposed fix is appropriate?
thanks
david jencks
Re: svn commit: r620848 - /tomcat/tc6.0.x/trunk/STATUS.txt
I thought this proposal was that at digester-configuration-time, trying to add the same rule twice would raise an exception. IIUC you are talking about digester-runtime behavior which I think everyone thinks is now fine. I'm not really familiar with digester but wondered how practical is is to recognize duplicate rules. thanks david jencks On Feb 12, 2008, at 4:42 PM, Tim Funk wrote: In that case - that would revert the functionality which caused the issue to arrive in the first place. The original bug had a problem because they had the same listener class declared multiple times and it was only being fired once. The fix was to log a duplicate listener message on the user config error. It turns out that WebRuleSet was also adding the same item twice. (accidently) and so the duplicate message was being. So if the digester rules are changed to ignore dups - the original bug fix would then be invalid and the user would again silently wonder why only one instance is being used. -Tim jean-frederic clere wrote: Tim Funk wrote: Not sure if I understand the question, the problem is our use of digester. We had 2 listener rules being created and each called addListener. So when an a listener was found - it was being processed twice. Yes. My idea was to prevent add twice the same rule in Digester additionally to the actual fix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Feb 10, 2008, at 2:42 PM, Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: On Sun, 2008-02-10 at 11:17 -0700, Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote: Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? I understand, you are not impacted by the behavior change, and as a result this allows you to be fair, I suppose. The issue is that the behavior of Tomcat has been different, in all prior releases, and changing it of all a sudden without any configuration capability because it feels nice to play spec lawyer is wrong to me. Similar decisions have been made in the past, and this did cause problems, it's simply faster to add the appropriate options right away. what about my suggestion, to add a flag to default to v1 cookies. they get quoted and old behavior will continue to work. This is the sort of configuration option which seems appropriate. essentially, browsers treated our previous v0 cookies as v1 when we quoted them. question, obviously it would be easiest for us to put the global flag in the javax.servlet.http.Cookie class directly -private int version = 0;// ;Version=1 ... means RFC 2109++ style +private int version = Integer.parseInt(System.getProperty (org.apache.catalina.cookie.version,1)); // ;Version=1 ... means RFC 2109++ style Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. I would hope that you would put this behavior in a non javax class since it's possible that tomcat may be used with other peoples servlet spec jars. I think consistent behavior independent of which spec jar you happen to pick would be desirable. thanks david jencks Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new year, new version? 6.0.16
Would this be from trunk or from a previous 6.0.x branch? I seem to recall some concerns about including the annotation processing changes that are now in trunk in a 6.0.x release and some thought that a version number more like 6.1 would be more appropriate. thanks david jencks On Jan 4, 2008, at 10:20 AM, Filip Hanik - Dev Lists wrote: we have a lot of updates added in, I think it may be good to set a date for our next release and work towards that Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Restricted listeners property file not found
Sorry, this is my fault. I attached a patch to fix it to http:// issues.apache.org/bugzilla/show_bug.cgi?id=44261. thanks david jencks On Jan 17, 2008, at 5:01 AM, Peter Rossbach wrote: Why this message was logged? 17.01.2008 13:57:45 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.15-trunk-pero 17.01.2008 13:57:45 org.apache.catalina.core.DefaultInstanceManager init SCHWERWIEGEND: Restricted listeners property file not found Testet with current tomcat 6 trunk. Regards Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r612992 - /tomcat/tc6.0.x/trunk/STATUS.txt
I don't think this is relevant to the 6.0.x branch, it depends on the new DefaultInstanceManager class which AFAIK is only in trunk. thanks david jencks On Jan 17, 2008, at 1:47 PM, [EMAIL PROTECTED] wrote: Author: pero Date: Thu Jan 17 13:47:24 2008 New Revision: 612992 URL: http://svn.apache.org/viewvc?rev=612992view=rev Log: Fix Restricted listeners property file not found message fix Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt? rev=612992r1=612991r2=612992view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jan 17 13:47:24 2008 @@ -52,3 +52,10 @@ http://svn.apache.org/viewvc?rev=612988view=rev +1: pero -1: + +* Fix Restricted listeners property file not found message fix + http://issues.apache.org/bugzilla/show_bug.cgi?id=44261 + http://svn.apache.org/viewvc?rev=612991view=rev + +1: pero + -1: + \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trunk development
On Dec 18, 2007, at 1:40 PM, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: 1. annotation dependency injection patch How does this compare to http://issues.apache.org/bugzilla/show_bug.cgi?id=43819 ? I don't see any relationship or overlap between EL and annotations/ dependency injection. What did you have in mind? thanks david jencks 2. cluster JMX configurations +1 3. any NIO improvements that haven't been ported +1 Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r593815 - /tomcat/tc6.0.x/trunk/STATUS
On Nov 10, 2007, at 2:12 PM, [EMAIL PROTECTED] wrote: Author: markt Date: Sat Nov 10 14:12:54 2007 New Revision: 593815 URL: http://svn.apache.org/viewvc?rev=593815view=rev Log: Add JSP schema fix Modified: tomcat/tc6.0.x/trunk/STATUS Modified: tomcat/tc6.0.x/trunk/STATUS URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS? rev=593815r1=593814r2=593815view=diff == --- tomcat/tc6.0.x/trunk/STATUS (original) +++ tomcat/tc6.0.x/trunk/STATUS Sat Nov 10 14:12:54 2007 @@ -53,3 +53,7 @@ -1: markt - only the double quoting part - see http://marc.info/? l=tomcat-devm=119454915422424w=2 for reasons -1: fhanik - I still think it needs some work, will discuss on dev list +* Fix licensing of JSP 2.1 schema + svn diff -c r593814 + +1: markt + -1: As noted in a reply to the commit email I think you have replaced the files Remy checked in with geronimo's copies of those files, so if I'm correct you have not improved the legal situation. thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r593815 - /tomcat/tc6.0.x/trunk/STATUS
On Nov 11, 2007, at 1:24 AM, David Jencks wrote: On Nov 10, 2007, at 2:12 PM, [EMAIL PROTECTED] wrote: Author: markt Date: Sat Nov 10 14:12:54 2007 New Revision: 593815 URL: http://svn.apache.org/viewvc?rev=593815view=rev Log: Add JSP schema fix Modified: tomcat/tc6.0.x/trunk/STATUS Modified: tomcat/tc6.0.x/trunk/STATUS URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS? rev=593815r1=593814r2=593815view=diff = = --- tomcat/tc6.0.x/trunk/STATUS (original) +++ tomcat/tc6.0.x/trunk/STATUS Sat Nov 10 14:12:54 2007 @@ -53,3 +53,7 @@ -1: markt - only the double quoting part - see http:// marc.info/?l=tomcat-devm=119454915422424w=2 for reasons -1: fhanik - I still think it needs some work, will discuss on dev list +* Fix licensing of JSP 2.1 schema + svn diff -c r593814 + +1: markt + -1: As noted in a reply to the commit email I think you have replaced the files Remy checked in with geronimo's copies of those files, so if I'm correct you have not improved the legal situation. As noted in my 2nd reply I was wrong and these files are not copies of Remy's checkin or suns originals. My apologies. david jencks thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
On Nov 9, 2007, at 2:23 PM, Mark Thomas wrote: Remy Maucherat wrote: On Fri, 2007-11-09 at 20:16 +, Mark Thomas wrote: Remy Maucherat wrote: On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ According to the release process, the 6.0.15 tag is: [X] Broken [ ] Alpha [ ] Beta [ ] Stable I am undecided about how to proceed with the release. The issues, although visible, do not sound very serious in the real world, so it would seem to be possible to release as stable. Just checking through the release, we still have a licensing issue so I don't believe we can proceed with the tag as is. See http://marc.info/?l=tomcat-devm=119170137616267w=2 for details. Remy - you commmitted the files originally so you are the only one who can answer the question about their provenance. If the source was such that the Sun license can be removed, great. If not, we can use the CDDL ones. I am happy to make the changes myself but I need to know which way to go. These sources can be found in the specification documents. That doesn't mean we can just copy them. Geronimo should also have the same files somewhere. I believe they use the CDDL ones but I'll check. I'll prepare a patch for 6.0.16 that uses whatever they use. Geronimo has gone to a lot of trouble and subjected our users to noticeable inconvenience to NOT ship any of the sun licensed xsds. We have not found any authority or reasoning that would let us do so. I believe the apache policy now allows us to put small numbers of CDDL schemas in apache svn and ship them but AFAIK we have not yet done so. thanks david jencks Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
On Aug 22, 2007, at 8:06 AM, [EMAIL PROTECTED] wrote: Remy Maucherat wrote: Yeah right. So to summarize, we have 3 committers who are happy campers (2 of them which don't contribute much, as far as I know), and the rest of the committers are either do not care or are unhappy. Most also want a change in the development process, and as long as there's agreement on that and it respects the ASF principles, we should be able to do that. Bah. In neither angry nor happy. My impression was trunk was going to be wacky new stuff which broke existing api's and configurations with 6.0. Much like 5.0 -- 5.5. In reality that didn't happen - we just got some comet changes. (I'm not saying this is good or bad - it's just and observation) While it's more fun to watch from the sidelines, I'm afraid I'll have to get involved here to point out that you are wrong about this. trunk contains an entirely new and incompatible with 6.0.x annotation processing framework which is in use in the Geronimo integration. Remy suggested and I agreed that it would not be appropriate for an api change of this magnitude to go in a 6.0.x revision. While Remy was certainly the committer most involved in applying these changes, IIRC there was some support from at least one other committer. In Geronimo we are anxiously awaiting an official tomcat release with these agreed upon api changes, so we tend to view the proposal eliminate trunk with some concern. thanks david jencks Now we are in a technical debate between comet implementation between Remy and Filips designs. This has seemed to migrate into a personal attack in a subtle manner. Such is life when coding. Disagreements occur, feeling are hurt and email is the worst method of communicating an emotional topic since words are amplified. (Sometime on purpose, other times by accident). My hope is this too shall pass and all is good again. Personally - I am not very clueful on comet other than the basics. I'd love to get the clue - but I can't find and work related projects to justify the time. That leaves me out in the cold due to this conversation. I feel any vote by me would be a bad vote because of my ignorance on the topic. It seems others are in the same situation. All that being said - I'd love to see Remy and Filip agree on comet and remove trunk. It would be a shame to see either leave due to these disputes. -Tim (Away for training in Boston this week (Kendall Square)) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP pre-compilation problem
Dunno, but I thought jetty was using jasper from glassfish not apache.
You might try using the maven jspc plugin from codehaus, it works for
us in geronimo.
With the latest version you can specify exactly which jasper version
you want to use, here's the snippet from the geronimo pom:
plugin
groupIdorg.codehaus.mojo.jspc/groupId
artifactIdjspc-maven-plugin/artifactId
version2.0-SNAPSHOT/version
executions
execution
goals
goalcompile/goal
/goals
configuration
warSourceDirectory${pom.basedir}/
src/main/webapp/warSourceDirectory
/configuration
/execution
/executions
!-- Use the Tomcat 6 JSP compiler, but with our
custom Jasper version --
dependencies
dependency
groupIdorg.codehaus.mojo.jspc/groupId
artifactIdjspc-compiler-tomcat6/
artifactId
version2.0-SNAPSHOT/version
exclusions
exclusion
groupIdorg.apache.tomcat/
groupId
artifactIdjasper/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdjasper/artifactId
version6.0.13-G543818/version
/dependency
/dependencies
/plugin
thanks
david jencks
On Jun 21, 2007, at 6:37 AM, Kevin Jackson wrote:
Hi all,
I'm working with mvn and the jetty jspc plugin for pre-compiling jsps
and I've come across this error:
[INFO] [jetty-jspc:jspc {execution: jspc}]
2007-06-21 11:15:18.969::INFO: Logging to STDERR via
org.mortbay.log.StdErrLog
java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
[Lorg.apache.jasper.compiler.JavacErrorDetail;
at org.apache.jasper.compiler.JDTJavaCompiler.compile
(JDTJavaCompiler.java:466)
at org.apache.jasper.compiler.Compiler.generateClass
(Compiler.java:317)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:
364)
at org.apache.jasper.JspC.processFile(JspC.java:1137)
at org.apache.jasper.JspC.execute(JspC.java:1306)
at org.mortbay.jetty.jspc.plugin.JspcMojo.compile
(JspcMojo.java:284)
at org.mortbay.jetty.jspc.plugin.JspcMojo.execute
(JspcMojo.java:213)
I've looked online (and to be honest I cannot find the JDTJavaCompiler
src, but I did find the JDTCompiler src @
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/
apache/jasper/compiler/JDTCompiler.java)
which had the following:
if (!problemList.isEmpty()) {
JavacErrorDetail[] jeds =
(JavacErrorDetail[]) problemList.toArray(new
JavacErrorDetail[0]);
errDispatcher.javacError(jeds);
}
From my limited knowledge of the codebase, this looks like a likely
candidate for the cause of the error message I'm seeing. I'm going to
swap the jspc plugin to (a slightly modified version of) the standard
mvn jspc plugin to see if the same error occurs.
I also checked the tomcat bugzilla and didn't find anything that
looked similar.
env info:
-tomcat version 6.0.13
-mvn version 2.0.7
-jetty jspc plugin version 6.1.0
-jdk6
Thanks,
Kev
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: emptySessionPath=
On Jun 4, 2007, at 8:43 AM, Joerg Heinicke wrote: Hi, I have a portal application and introduced recently emptySessionPath=true to have access to the same objects in the session in my servlets and my portlets, both sitting in the same webapp. First observation I made is the repeated use of the same session id despite invalidating the corresponding session. I found out that this is by intention [1], but it leaves a strange gut feeling. Why is a session id an arbitrary string, which is under normal circumstances really hard to guess - if I do not need to predict it at all since I know it when having access to the PC (without any XSS issue)? I only have to wait until the user logs in the next time to hijack his session, don't I? But ignoring that one for the moment and blaming the portlet spec [2] I found another issue ... From what I observed not all sessions assigned to this session id are invalidated. This seems to be true for different portals, I found at least uPortal [3], JetSpeed [4] and Liferay [5] (using it myself). Of course it's possible that the portals are to blame but I wonder if they manage the sessions themselves or if they don't only forward it to the application container. At least in Liferay the HttpSession for the portal is invalidated, but I can access objects in the session of my webapp (portlets + servlets). Here the reused session id gets also very critical. So I agree with Aaron Evans who reported this issue for JetSpeed [6]: I don't think this is a jetspeed problem but rather a tomcat/ tomcat SSO issue, but I was just wondering if others have seen this behaviour. And like his idea how it should work [7]. So actually there are two issues, (1) always using the same session id, (2) not invalidating all sessions associated with one session id. I wonder if there has changed anything for the former since that thread [1] since I'm using the most recent 5.5 release 23. Or if it is solvable at all. But the latter seems to be a real issue for me. Can you please comment on it? IMO the area of cross-context session management is basically not specified in the servlet and portlet specs. It certainly relies on a lot of extrapolation to make a usable product. My conclusions are that to make a usable portal possible, while deploying portlet applications as web apps, the servlet container has to create a cross context session id, and manage individual sessions for each web app context that uses this sessionId, and when one session is invalidated in this collection, invalidate all sessions for that sessionId. AFAICT this is consistent with the servlet spec, although it is certainly not specified behavior according to the servlet spec. In a little more detail: - sessions are indexed by sessionId and context-root (or other web app identifier) - invalidating one session (for a sessionId + context-root) invalidates all other sessions with that sessionId After a lot of discussion with the jetty devs I got them to implement this, but I've never been able to understand the discussions about the subject on the tomcat lists so I'm really not sure what the expected behavior of tomcat is. thanks david jencks Regards, Joerg [1] http://marc.info/?t=11077928475r=1w=4 [2] http://marc.info/?l=tomcat-devm=112092302521008w=4 [3] http://www.ja-sig.org/issues/browse/UP-1590 [4] http://issues.apache.org/jira/browse/JS2-582 [5] http://support.liferay.com/browse/LEP-1852 [6] http://www.mail-archive.com/[EMAIL PROTECTED]/ msg03195.html [7] http://www.mail-archive.com/[EMAIL PROTECTED]/ msg03203.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On May 24, 2007, at 10:10 AM, Remy Maucherat wrote: David Jencks wrote: I tend to agree that a new branch is more appropriate. However, earlier versions of the patch had a compatibility layer so the old api could continue to work. I'm happy to add that back in on request. I am examining the patch in detail as part of the new trunk branch (adjusting things like package names), and unfortunately it turns out I still dislike it due to design implications with Jasper. Modern JSPs now uses lots of tags, and especially lots of SimpleTags, which are not pooled. As a result, the InstanceManager design leads to replacing new MySimpleTag() with newInstance (String className) (which creates the instance in a much more expensive way). Maybe adding access to InstanceManager.newInstance (Object instance) would be a solution (in effect making InstanceManager an extension of the old AnnotationProcessor). To reorient myself to this these tags can have injected stuff, correct? So it would theoretically be possible to support constructor injection on them, with suitable constructor metadata? Are tags typically created once per jsp instance or once per request (or at some other frequency)? And your objection here is that new Foo(); is sufficiently faster than Class fooClass = cl.loadClass(Foo); Object foo = fooClass.newInstance(); that we should separate the object construction and injection phases? My thoughts at this time are that: - if tags are created once per jsp we're only talking a difference in startup time which is not important - it might be worth eliminating the loadClass call in any case - if tags use injection the cost of looking up the stuff to inject so far dwarfs the time to create the object that the single InstanceManager.newInstance method still makes sense - if a tag doesn't use injection and is created once per request (or more often) then it would be worth measuring the speed difference and possibly modifying the code generator to directly create the tags when there are no injections for it. I haven't done any speed measurements yet, have you? thanks david jencks Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On May 17, 2007, at 2:41 AM, Remy Maucherat wrote: David Jencks wrote: As far as I know I've addressed all the issues that were raised, but that might have a tenuous relationship to whether I actually did :-). I'd certainly appreciate review by tomcat committers before I completely forget how my patch works :-) The patch could see minor modifications when it is committed, but I am not going to ask you to do them. As for the actual commit, the problem is I don't know if it's appropriate to commit this in 6.0.x rather than in a new branch (at the moment, I would say no, as at least one project uses the API). I tend to agree that a new branch is more appropriate. However, earlier versions of the patch had a compatibility layer so the old api could continue to work. I'm happy to add that back in on request. thanks david jencks Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On May 16, 2007, at 1:10 PM, Paul McMahan wrote: On Apr 12, 2007, at 12:15 PM, Remy Maucherat wrote: David Jencks wrote: https://issues.apache.org/jira/secure/attachment/12355273/ GERONIMO-3010-4.patch In addition, this one combines the InstanceManager interfaces. I think this is a bad idea because it forces jasper to use an interface shared with catalina, which the previous patch does not. This makes catalina marginally more complicated when used as a standalone container for jasper but makes it possible to use jasper outside catalina without any catalina classes. Note also that the previous (3c) patch allows use of tomcat embedded in a container that supplies its own InstanceManager implementation without pulling in any jasper classes at runtime. This has 1 interface, 1 implementation. Thanks for the patch revisions. I will look into adding these features after the next stable release. Rémy Now that 6.0.13 has been released is it a good time to resume this discussion about annotation processing? I have been using David's patch in geronimo's Tomcat assembly for the last several weeks and it has proven to be quite stable. David, do you consider the latest patch to be feature complete as far as where the discussion left off? Have the issues that were raised in this discussion been addressed? As far as I know I've addressed all the issues that were raised, but that might have a tenuous relationship to whether I actually did :-). I'd certainly appreciate review by tomcat committers before I completely forget how my patch works :-) thanks david jencks Best wishes, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Apr 12, 2007, at 9:15 AM, Remy Maucherat wrote: David Jencks wrote: https://issues.apache.org/jira/secure/attachment/12355273/ GERONIMO-3010-4.patch In addition, this one combines the InstanceManager interfaces. I think this is a bad idea because it forces jasper to use an interface shared with catalina, which the previous patch does not. This makes catalina marginally more complicated when used as a standalone container for jasper but makes it possible to use jasper outside catalina without any catalina classes. Note also that the previous (3c) patch allows use of tomcat embedded in a container that supplies its own InstanceManager implementation without pulling in any jasper classes at runtime. This has 1 interface, 1 implementation. Thanks for the patch revisions. I will look into adding these features after the next stable release. Excellent, thanks! Would this be shortly after 6.0.11 is out or further in the future? If you have any guess about a date it would be much appreciated. thanks david jencks Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Mar 27, 2007, at 8:31 PM, David Jencks wrote: big snip Right now, it's mostly pita-win (it's a significant refactoring) :D You should IMO offer some incentive as part of this to justify the refactoring, such as support for web.xml annotation overrides in standalone Tomcat (as you can see, there's full support for annotations, but not overriding). i'll look into this... although I don't see the code involved as being very connected to what I've been proposing. i've worked on this some more and come up with a patch that I feel more or less comfortable showing to tomcat :-) at https:// issues.apache.org/jira/browse/GERONIMO-3010 or directly https:// issues.apache.org/jira/secure/attachment/12355053/GERONIMO-3010-3a.patch I'm happy to open a bugzilla entry and attach the patch to it as well, but I also need to keep the patch tracked in geronimo until there's more resolution as to its fate. This patch features: -- xml override of annotations. There's even a manual test via a new EnvEntryExample servlet which is present but not entirely integrated into the examples webapp. -- postCreate and preDestroy annotated methods are looked for on all superclasses per spec. -- Improved interface name of InstanceManager rather than LifecycleProvider, thanks David Blevins -- Jasper does not use any Catalina classes, and catalina only uses a jasper class if it creates its own InstanceManager: if you supply an InstanceManager yourself there is no classes dependency of catalina on jasper (although it appears that startup creates a JspServlet in a default web app???). This removes the need for sharing org.apache.AnnotationProcessor between catalina and jasper. -- jasper loads classes more directly, tomcat uses care in figuring out if security precautions are needed and which classloader should be used. Some more improvements are possible, for example the jasper generated classes are loaded twice. I'd rather make sure that the current state doesn't break a lot of the tck before making a lot more changes. Comments? thanks david jencks
Re: Annotation processing - Geronimo injection
On Apr 6, 2007, at 2:54 AM, Remy Maucherat wrote: David Jencks wrote: i've worked on this some more and come up with a patch that I feel more or less comfortable showing to tomcat :-) at https:// issues.apache.org/jira/browse/GERONIMO-3010 or directly https:// issues.apache.org/jira/secure/attachment/12355053/ GERONIMO-3010-3a.patch Thanks. I'm happy to open a bugzilla entry and attach the patch to it as well, but I also need to keep the patch tracked in geronimo until there's more resolution as to its fate. This patch features: -- xml override of annotations. There's even a manual test via a new EnvEntryExample servlet which is present but not entirely integrated into the examples webapp. -- postCreate and preDestroy annotated methods are looked for on all superclasses per spec. -- Improved interface name of InstanceManager rather than LifecycleProvider, thanks David Blevins Ok. -- Jasper does not use any Catalina classes, and catalina only uses a jasper class if it creates its own InstanceManager: if you supply an InstanceManager yourself there is no classes dependency of catalina on jasper (although it appears that startup creates a JspServlet in a default web app???). This removes the need for sharing org.apache.AnnotationProcessor between catalina and jasper. Submitting this in the patch makes me look at it and consider it, but I much prefer keeping a shared interface between Catalina and Jasper (because otherwise it's pretty obvious one of them becomes dependent on the other; and predictably, the main instance manager extends org.apache.jasper.instanceManagement.InstanceManager). IIRC everyone who commented on my previous patch complained that I had a shared class between catalina and jasper, so I changed it. If tomcat and jasper were truly independent, with no shared classes at all, you wouldn't be able to run jasper in tomcat without reflection or something that served as a container for both. I think my current implementation makes it clear why, as you note. I very slightly prefer the current implementation because it really does make it possible to run jasper in other servlet containers without any leakage of catalina classes. However I really don't care much, and am happy to go back to a single interface, but I won't put it in the org.apache package. Other smaller problems: - InstanceManagerFactory in Jasper is a bit too convoluted as far as I am concerned I'll see if I can think up a simpler way to do this. - I still don't know if I agree with removing the security checks out of Catalina, merging checks between filters and servlets, etc I think that the security checks and related code are really specific to the tomcat classloader and you shouldn't force them on containers embedding tomcat that use different classloaders. As far as uniformizing the code between servlets, filters, and listeners, I still don't understand the problem. You might well be right, but I'd really appreciate concrete details on why some checks are appropriate for servlets and not listeners or filters. Since all of these objects are only created once (except for single-thread-model servlets, which have all the checks anyway) I don't really see why a slight difference in startup speed would outweigh the simplicity of uniform code and relative ease of understanding of having the object creation policy in one place. - Class hierarchy for InstanceManager - meh (although I suppose it perfectly fits your needs, though ...) I agree... Geronimo implements its own InstanceManagers for tomcat and jasper, so we don't have that problem. I'd be perfectly happy to drop support for AnnotationProcessor entirely, but I kinda doubt you would like it so much :-) -- jasper loads classes more directly, tomcat uses care in figuring out if security precautions are needed and which classloader should be used. Some more improvements are possible, for example the jasper generated classes are loaded twice. I'd rather make sure that the current state doesn't break a lot of the tck before making a lot more changes. To be honest, this whole stuff may be 6.next material. We'll see. thanks! david jencks Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there a tomcat/jasper test suite?
On Apr 3, 2007, at 7:19 PM, Yoav Shapira wrote: Hi, On 4/3/07, David Jencks [EMAIL PROTECTED] wrote: Following Remy's suggestion I implemented web.xml overrides of annotations but although the result compiles I have no very good way to determine if it works. I looked around a bit but didn't see any unit tests or integration testsuite. What am I missing? Right now I can really only test the geronimo javaee integration with the javaee tck, but that doesn't use the code in question. If the standalone tck is the normal test method, is there some way I could get access to it? If you run ant tester on the main Tomcat build.xml, that will run the internal test suite. It covers many, but not all, of the same tests as the TCK. I appreciate the info but I'm having some trouble following these instructions $ grep https .svn/entries url=https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk; repos=https://svn.apache.org/repos/asf; $ ant tester Buildfile: build.xml BUILD FAILED Target `tester' does not exist in this project. Total time: 0 seconds $ ant -p Buildfile: build.xml Main targets: download Builds and download dependent components Default target: deploy In addition I don't see any targets in build.xml that look like they run any tests, and with the exception of a few tribes tests I haven't found anything that looks like a junit test in the source tree. Did I check out the wrong source or run the build from the wrong place? thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is there a tomcat/jasper test suite?
Following Remy's suggestion I implemented web.xml overrides of annotations but although the result compiles I have no very good way to determine if it works. I looked around a bit but didn't see any unit tests or integration testsuite. What am I missing? Right now I can really only test the geronimo javaee integration with the javaee tck, but that doesn't use the code in question. If the standalone tck is the normal test method, is there some way I could get access to it? thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Mar 25, 2007, at 7:40 PM, Remy Maucherat wrote: David Jencks wrote: I personally think the AnnotationProcessor is a very questionable idea and hope no one uses it. However, it is pretty common now. The point of the adapter is to show that tomcat can still support people who want to integrate via something like AnnotationProcessor. I certainly don't think tomcat should be using a AnnotationProcessor wrapped in a LifecycleProvider. I was basically trying to show that tomcat could work through an interface like LifecycleProvider, and that it would provide uniformity that is currently lacking, not trying to show a great new implementation of the interface. -- a little history and context -- I work on geronimo, and I started by getting annotation/injection support to work on our app client container and jetty integration, using some ideas I cribbed from OpenEjb and Xbean. With all of these projects it was a really natural fit to have an object creation service that, when given a class name, handed you back a fully baked object. The code tended to get simpler and more straightforward. Then I looked at MyFaces and realized that they could also simplify their code by using an object creation service where you say getLifecycleProvider().newInstance(className); rather than continual repetition of Object o = clazz.newInstance(); getAnnotationProcessor().inject(o); getAnnotationProcessor().postConstruct(o); At this point, I don't like the patch much either. I am not convinced by the proposed API (and the idea of an API change in 6.0.x) which is a bit more intrusive (a LifecycleProvider now would have to be given to Jasper for it to work), and how it is better than the continual (but explicit; quotes because it doesn't exactly happen that often) repetition where it does matter (as far as I can tell, not all the objects that may be instantiated may be annotated). AFAICT the objects that can be annotated are servlets, filters, listeners, and tags. The objects that AFAICT can't be annotated at present (unless jasper annotates some of its base classes, such as with postConstruct methods) are compiled jsps and some kind of object that jasper compiles out of tld files. I'm pretty sure that someone who had more than my 2 days acquaintance with jasper could in a couple of minutes point out how to avoid using LifecycleProvider or AnnotationProcessor on generated classes. I might be mistaken but I'm pretty sure the current code happily does call the AnnotationProcessor on such classes. It's easy enough for jasper to create its own LifecycleProvider if none is supplied, although my current patch has null checks and alternate code for this circumstance. At least one RI in JEE land (JSF) has independently adopted the same AnnotationProcessor interface that is in use in Tomcat. I see you like the LifecycleProvider API better, but are there really things you cannot do (or are hard to do) with the AnnotationProcessor API ? That would be the bar that would have to be cleared IMO to justify a change. Umm, could you explain how the jsf RI is independent? Of what? To me that would mean they had come up with an interface with the same three methods without having seen any examples of it. If you want to count projects on either side of the fence, I got the idea from OpenEjb, geronimo uses this idea, jetty is compatiible with it, and MyFaces has adopted it after starting with the AnnotationProcessor style interface. The AnnotationProcessor style can't support constructor dependency injection or factory methods. These are not envisioned by the specs but there's nothing preventing their support through additional metadata. An object creation service can. However, the main benefit I can see for tomcat is that by swapping which implementation you use at startup, you can specify the policy for object instantiation (such as security sensitve, annotation sensitive, neither, custom.) without any runtime cost. They agreed. Then I looked at Tomcat. I found that there was a lot of attention paid to all sorts of things such as security settings and whether the class was in tomcat for servlets, but no such attention paid for filters or listeners. I wondered if this was an oversight I guess I should Tomcat does not ship security sensitive filters and listeners, but has some funny servlets. For sure I will not want to be performing all these expensive checks for all instantiations, such as tags. That certainly makes sense, but I don't see how it relates to the current code in tomcat. From my reading the code that decides whether to perform the extra security stuff (SecurityUtil.isPackageProtectionEnabled()) doesn't depend on whether the object being instantiated is from the tomcat classloader. Therefore I thought it was reasonable to apply the same checks to all
Re: Annotation processing - Geronimo injection
On Mar 27, 2007, at 10:39 AM, Remy Maucherat wrote: David Jencks wrote: compiled jsps If you read the spec literally, they can't be annotated, but this is quite arbitrary IMO (as soon as they're mapped in web.xml, they can). Doh! Of course you're right. I just haven't seen a jsp with any java code in it for a while :-). This could be a challenge for deployment unless you've precompiled your jsps I'll have to think about this. I'm pretty sure that someone who had more than my 2 days acquaintance with jasper could in a couple of minutes point out how to avoid using LifecycleProvider or AnnotationProcessor on generated classes. Hem, that does look difficult to me. Umm, could you explain how the jsf RI is independent? Of what? I meant they came up with the same interface without talking to us. The AnnotationProcessor style can't support constructor dependency injection or factory methods. These are not envisioned by the specs but there's nothing preventing their support through additional metadata. An object creation service can. However, the main benefit I can see for tomcat is that by swapping which implementation you use at startup, you can specify the policy for object instantiation (such as security sensitve, annotation sensitive, neither, custom.) without any runtime cost. Ok. I note the constructor dependency injection (as well as the future proof destructor dependency injection :D). As I said in my email, I am not in favor of the unification of all instantiation checks, as the said checks have a cost and may not be needed (in particular for tags). Maybe I haven't been explaining my thinking very well. I suspect that for a very large percentage of web apps, the expensive checks are completely unnecessary even for servlets. Furthermore AFAICT its pretty easy to tell whether or not an app is going to need them before you start constructing servlets and other components. So, if the app doesn't need the fancy stuff, you can supply it with a LifecycleProvider that doesn't do any. If it does, you can supply it with one that does do the checks. Furthermore, there's no reason jasper and tomcat have to be using the same LifecycleProvider at the same time. Jasper can get one free of checks, tomcat can have one that refuses to load any classes :-). I still don't understand the point behind the fancy classloading code or why you insist that it should only apply to servlets. Is there some other code or documentation I could look at that might help explain your point of view? obvious win-win choice for both tomcat and geronimo. Right now, it's mostly pita-win (it's a significant refactoring) :D You should IMO offer some incentive as part of this to justify the refactoring, such as support for web.xml annotation overrides in standalone Tomcat (as you can see, there's full support for annotations, but not overriding). i'll look into this... although I don't see the code involved as being very connected to what I've been proposing. thanks david jencks Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
Thanks for your interest!
On Mar 24, 2007, at 9:26 PM, Fabien Carrion wrote:
Hi,
Here is my point of view.
I like the idea of create a new instance through various kinds of
magic to be replaced by nice code that can do the object creation
and injection in one step.
As I am still new on the code of Tomcat, having all the code
concentrated for the object creation and injection is a good idea. I
remember to have problem to find out where the filter, servlet...
objects were created when I did my first patch on the annotations. But
I have no solution to implement it on tomcat.
The patch doesn't seems to modify nothing on the catalina side
(ContextConfig.java, WebRuleSet.java, WebAnnotationSet.java). Just the
jasper side is taken in account.
I don't think an adapter between the LifecycleProvider interface
and the
AnnotationProcessor interface is a good idea. This is one layer more
between the code which does the work and the code which requires the
work. The adapter has to be maintained. It is more work for us.
I personally think the AnnotationProcessor is a very questionable
idea and hope no one uses it. However, it is pretty common now. The
point of the adapter is to show that tomcat can still support people
who want to integrate via something like AnnotationProcessor. I
certainly don't think tomcat should be using a AnnotationProcessor
wrapped in a LifecycleProvider. I was basically trying to show that
tomcat could work through an interface like LifecycleProvider, and
that it would provide uniformity that is currently lacking, not
trying to show a great new implementation of the interface.
-- a little history and context --
I work on geronimo, and I started by getting annotation/injection
support to work on our app client container and jetty integration,
using some ideas I cribbed from OpenEjb and Xbean. With all of these
projects it was a really natural fit to have an object creation
service that, when given a class name, handed you back a fully baked
object. The code tended to get simpler and more straightforward.
Then I looked at MyFaces and realized that they could also simplify
their code by using an object creation service where you say
getLifecycleProvider().newInstance(className);
rather than continual repetition of
Object o = clazz.newInstance();
getAnnotationProcessor().inject(o);
getAnnotationProcessor().postConstruct(o);
They agreed.
Then I looked at Tomcat. I found that there was a lot of attention
paid to all sorts of things such as security settings and whether the
class was in tomcat for servlets, but no such attention paid for
filters or listeners. I wondered if this was an oversight I
guess I should have asked but was kind of busy. So, I wanted to see
if I could get tomcat to work with an object creation service both
standalone and in geronimo. I haven't located any tests for tomcat
standalone so my criterion for tomcat working standalone so far is
it builds. I'm getting good results in geronimo with a geronimo
implementation of LifecycleProvider.
So, if there's interest in pursuing this in tomcat, my idea of a
possible path would be something like:
0. find a better name than LifecycleProvider :-)
1. Modify the code that creates and destroys these managed objects
so there is always a LifecycleProvider present. This eliminates a
lot of if (its there) { do it one way} else {do it another way} code.
2. Write a suitable variety of LifecycleProvider implementations. An
obvious simple one is clazz.newInstance() for newInstance, and {} for
destroyInstance. There can be one with the security code of the
current servlet construction code. There can be one that adapts to
an AnnotationProcessor for those who prefer to provide an
implementation of that interface. And there can be a native tomcat
implementation that does annotations. Of course I think the geronimo
implementation is close to ideal :-) and you're welcome to use it but
it may not suit all the standalone tomcat needs.
3. Make sure its convenient to configure both tomcat and jasper
(independently) with the LifecycleProvider instances of your choice.
Many thanks,
david jencks
Cheer's
Fabien
On 3/24/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
yo,
I've been in touch with the folks at Geronimo.
They use dependency injection, and have a suggestion on how they
would
like the annotation processor to be able to be injected into tomcat
Here is the email
http://marc.info/?l=geronimo-devm=117467149802844w=2
Here is the proposed patch:
https://issues.apache.org/jira/secure/attachment/12354097/
GERONIMO-3010-1.patch
I'd take out the word LifecycleProvider, and replace it with
something
else as it conflicts with our own idea of Lifecycle.
I'd like to get your feedback, this is a chance step for our two
communities to work together.
Filip
--
Fabien Carrion
() Campagne du ruban ASCII
Re: Annotation processing - Geronimo injection
On Mar 24, 2007, at 6:18 PM, Bill Barker wrote: Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/ GERONIMO-3010-1.patch A big huge -1 to the patch. It doesn't really provide anything to Tomcat that it isn't doing already. And to the extent that it is doing things differently, it is only adding complexity resulting in doing a much worse job. You might consider the idea of an object creation and destruction service rather than the current state of the patch which was not really intended for presentation as something to be applied as is to tomcat but as a demonstration that tomcat could be made to work with such a service. I figured that the first step was to investigate whether this was practical with minimal code changes in tomcat, and then think about how to further clean up the tomcat code. I've demonstrated to my own satisfaction that the idea can work, but the code could be simplified a lot. In its current state there is essentially no code that isn't already present in tomcat, although it's arranged slightly differently and is considerably more uniform. However, introducing a catalina dependancy into Jasper is a really huge no-no. Jasper is useful, and used without Tomcat. To break this would require a very good reason, which this patch certainly doesn't provide. How does this differ from the current org.apache.AnnotationProcessor? The only difference I can see is that I used the project namespace. I can't say I understand the thinking behind the package for org.apache.AnnotationProcessor. I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. Ya, I don't much like the name either but those postConstruct and preDestroy methods are often called lifecycle methods. I had to call it something. Any better ideas? ManagedObjectFactory? I'd like to get your feedback, this is a chance step for our two communities to work together. There's certainly interest on the geronimo side. Many thanks david jencks Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
