Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as often 
as I change underwear.


Ouch, that must smell.

I don't see a need to slow down development even 
further, at this point if the previous vote is considered valid, we 
don't even have a development branch, and a few months of work got 
thrown out the window


Right, so I guess my own stuff in the sandbox was not even considered, 
since the sandbox is sooo not nice enough for your great work :( The 
right way to do things is to reach a rather precise agreement before 
doing things, and the sandbox is the right place for that.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

What new in Tomcat 6.0 ?

[Ashish Jain]

Hi All!!

 I am new to Tomcat. Can someone tell me what is new in Tomcat 6.0 compared
to the last version.

Thanks in advance

Regards
Ashish

Re: [VOTE] Make released versions RTC

[Jim Jagielski]

On Sep 5, 2007, at 5:51 AM, Remy Maucherat wrote:


Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as  
often as I change underwear.


Ouch, that must smell.

I don't see a need to slow down development even further, at this  
point if the previous vote is considered valid, we don't even have  
a development branch, and a few months of work got thrown out the  
window


Right, so I guess my own stuff in the sandbox was not even  
considered, since the sandbox is sooo not nice enough for your  
great work :( The right way to do things is to reach a rather  
precise agreement before doing things, and the sandbox is the right  
place for that.




In httpd and apr-land, sandboxes are mostly single-developer places,  
where

the rest of the team can see what's going on and review
stuff. trunk is the place where more communal development is done
and where that kind of agreement process is reached.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Jim Jagielski wrote:


On Sep 5, 2007, at 5:51 AM, Remy Maucherat wrote:


Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as 
often as I change underwear.


Ouch, that must smell.

I don't see a need to slow down development even further, at this 
point if the previous vote is considered valid, we don't even have a 
development branch, and a few months of work got thrown out the window


Right, so I guess my own stuff in the sandbox was not even considered, 
since the sandbox is sooo not nice enough for your great work :( The 
right way to do things is to reach a rather precise agreement before 
doing things, and the sandbox is the right place for that.




In httpd and apr-land, sandboxes are mostly single-developer places, where
the rest of the team can see what's going on and review
stuff. trunk is the place where more communal development is done
and where that kind of agreement process is reached.


Yes, it's exactly what I was saying. Trunk is currently based on Filip's 
ideas, and as a result it should be moved to the sandbox (which is 
somehow characterized as "trowing everything away"; since I was working 
on my own stuff in the sandbox, I cannot help but conclude that my own 
development was trash, and I was unfortunately right to move it away :( ).


In a regular branch like trunk, I expect collaboration, discussion and 
announcements of upcoming changes, etc, which did not happen.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Make released versions RTC

[Henri Gomez]

Well what's the consensus on Java projects, like Xerces, Xalan or Lucene ?

2007/9/5, Remy Maucherat <[EMAIL PROTECTED]>:
> Jim Jagielski wrote:
> >
> > On Sep 5, 2007, at 5:51 AM, Remy Maucherat wrote:
> >
> >> Filip Hanik - Dev Lists wrote:
> >>> yes, it is also easily abused by folks who throw around vetoes as
> >>> often as I change underwear.
> >>
> >> Ouch, that must smell.
> >>
> >>> I don't see a need to slow down development even further, at this
> >>> point if the previous vote is considered valid, we don't even have a
> >>> development branch, and a few months of work got thrown out the window
> >>
> >> Right, so I guess my own stuff in the sandbox was not even considered,
> >> since the sandbox is sooo not nice enough for your great work :( The
> >> right way to do things is to reach a rather precise agreement before
> >> doing things, and the sandbox is the right place for that.
> >>
> >
> > In httpd and apr-land, sandboxes are mostly single-developer places, where
> > the rest of the team can see what's going on and review
> > stuff. trunk is the place where more communal development is done
> > and where that kind of agreement process is reached.
>
> Yes, it's exactly what I was saying. Trunk is currently based on Filip's
> ideas, and as a result it should be moved to the sandbox (which is
> somehow characterized as "trowing everything away"; since I was working
> on my own stuff in the sandbox, I cannot help but conclude that my own
> development was trash, and I was unfortunately right to move it away :( ).
>
> In a regular branch like trunk, I expect collaboration, discussion and
> announcements of upcoming changes, etc, which did not happen.
>
> 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]

[Proposal] Add flag to escape JSP's EL by default

[mraible]

Hello all,

I'm working for a client that's using a proprietary Servlet/JSP-based
framework that runs on Tomcat. They have their own custom JSP compiler and
they're looking to move to a standard JSP compiler. One of the things their
compiler supports is automatic escaping of XML in expressions. For example,
${foo} would be escaped from  -> . JSP EL does not do
this. It *doesn't* escape by default and instead requires you to wrap your
expressions with  if you want escaping.

I'd like to ask what developers think about adding a flag (similar to
trimSpaces in web.xml) that allows users to change the escaping behavior
from false to true? 

I think this is a good option to have as it allows security-conscious
organizations to paranoid and escape all content by default.

Thanks,

Matt

Related: http://raibledesigns.com/rd/entry/java_web_frameworks_and_xss



-- 
View this message in context: 
http://www.nabble.com/-Proposal--Add-flag-to-escape-JSP%27s-EL-by-default-tf4388103.html#a12510904
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What new in Tomcat 6.0 ?

[Mark Thomas]

Ashish Jain wrote:
> Hi All!!
> 
>  I am new to Tomcat. Can someone tell me what is new in Tomcat 6.0 compared
> to the last version.

This question should be posted to the users list. See
http://tomcat.apache.org/lists.html

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Make released versions RTC

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Jim Jagielski wrote:


On Sep 5, 2007, at 5:51 AM, Remy Maucherat wrote:


Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as 
often as I change underwear.


Ouch, that must smell.

I don't see a need to slow down development even further, at this 
point if the previous vote is considered valid, we don't even have 
a development branch, and a few months of work got thrown out the 
window


Right, so I guess my own stuff in the sandbox was not even 
considered, since the sandbox is sooo not nice enough for your great 
work :( The right way to do things is to reach a rather precise 
agreement before doing things, and the sandbox is the right place 
for that.




In httpd and apr-land, sandboxes are mostly single-developer places, 
where

the rest of the team can see what's going on and review
stuff. trunk is the place where more communal development is done
and where that kind of agreement process is reached.


Yes, it's exactly what I was saying. Trunk is currently based on 
Filip's ideas, and as a result it should be moved to the sandbox 
(which is somehow characterized as "trowing everything away"; since I 
was working on my own stuff in the sandbox, I cannot help but conclude 
that my own development was trash, and I was unfortunately right to 
move it away :( ).

you start to sound like you believe yourself by this point.
After my vacation, I'll pull out the emails you wrote, where, even 
though it was a veto, you clearly specified to leave it in.
I will also pull out the email, where I offered to elaborate more, and 
you pretty much declined.
Then I will pull out the email where I offered to pull out the much 
debated Comet implementation, so that trunk can move forward.
And if you wish, I can pull out even more examples. Just let me know how 
much time and proof it needs to take before your willing to re-evaluate 
your accusatory statements.




In a regular branch like trunk, I expect collaboration, discussion and 
announcements of upcoming changes, etc, which did not happen.
you're having a control issue, and your manifesting it by wanting to get 
rid of trunk, even though several people have politely and respectfully 
asked for it to remain. Mainly the Geronimo folks who would want it in 
their distribution. Getting rid of trunk, simply means that Geronimo has 
one more obstacle to get around, sounds like it would benefit someone 
else, doesn't it?


Besides annotations and comet, the changes in trunk are of a bug 
fix/feature improvement type, and discussing every minor detail would be 
equivalent to RTC. Currently we are using CTR, hence you get the option 
to review anything that has been done.


I've never ignored your emails, nor have I not answered anytime you 
asked for an explanation. Take the virtual loader for example, huge 
improvements to a component that wasn't really working, but was included 
in the main distribution. Simply because you "didn't like it" was your 
explanation, doesn't make it immensely useful for very large 
installation of Tomcat.


I'll be back next week for more community fun, Tomcat has always put the 
"fun" back into dys*fun*ctional :), it's an honor to participate

Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43316] New: - message jsp.error.beans.property.conversion missing in resourcebundle

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43316

   Summary: message jsp.error.beans.property.conversion missing in
resourcebundle
   Product: Tomcat 5
   Version: 5.5.0
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We are using jBoss 4.0.5, so I don't know exactly, which tomcat-version is
integrated (but it is a version >= 5.5.0)

If an exception is thrown in class org.apache.jasper.runtime.JspRuntimeLibrary
at line 885 (method getValueFromPropertyEditorManager), a localized message is
created.

The message key "jsp.error.beans.property.conversion" seems to be missing,
because the log-output only contains the following stacktrace:

org.apache.jasper.JasperException: jsp.error.beans.property.conversion
at
org.apache.jasper.runtime.JspRuntimeLibrary.getValueFromPropertyEditorManager(JspRuntimeLibrary.java:885)
at
org.apache.jsp.WEB_002dINF.pages.portfolio.positions.positions_jsp._jspx_meth_ov_chartTyp1_0(positions_jsp.j
at
org.apache.jsp.WEB_002dINF.pages.portfolio.positions.positions_jsp._jspx_meth_s_iterator_0(positions_jsp.jav
at
org.apache.jsp.WEB_002dINF.pages.portfolio.positions.positions_jsp._jspService(positions_jsp.java:308)
.

There is absolutely no info about the attributes name, value or class. This
makes it really painful, to find the reason of this exception.

The exception is thrown like this:

 throw new JasperException(
  Localizer.getMessage("jsp.error.beans.property.conversion",
   attrValue, attrClass.getName(), attrName,
   ex.getMessage()));

so, if you add the message to the resourcebundle, this would be great.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]