DO NOT REPLY [Bug 37195] New: - NPE in WebClassloader

[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=37195

   Summary: NPE in WebClassloader
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
OS/Version: other
Status: NEW
  Keywords: ErrorMessage
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,

I'm keep getting this message, when some   exception stopped application.  (eg.
OutOfMemory error)

java.lang.NullPointerException
at
org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1795)

It seems, that this classloader has been stopped, but the webapp itself not. 
It should raise a meaningful message instead, not a NPE.

-- 
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]

DO NOT REPLY [Bug 37186] - Add path/filename of xml config file that failed parsing at catalina startup

[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=37186


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|blank line at start at start|Add path/filename of xml
   |of tomcat-users.xml file|config file that failed
   |leads to failure of |parsing at catalina startup
   |UserDatabase|




--- Additional Comments From [EMAIL PROTECTED]  2005-10-21 13:03 ---
(In reply to comment #3)

> (In reply to comment #2)
> > declaration having to begin at the first char in the file.  If you have a 
> > moment to point me to a webpage that describes this, I would be grateful :)
> http://www.w3.org/TR/2004/REC-xml-20040204/#sec-well-formed

Thanks.  Yes I saw that and can see that it indicates that the XMLdecl has to 
be at the beginning, but was unsure about how that was to be read, related to 
this other section, which seems to imply that whitespace can optionally be 
added, and the parser is to ignore it (?):
http://www.w3.org/TR/2004/REC-xml-20040204/#sec-white-space

But I'm going off-topic now.  This is clearly an issue of my understanding of 
the spec doc rather than any bug in TC or org.xml.sax.

> > PS regarding my point 3

> This is already fixed. 
>.In 5.5.12 this definitely works.

OK then fair enough, that's point 3 resolved. I couldn't find any mention of 
it in the changelog or bugzilla either.

> IMO you could file your 1st suggestion (report the name of the broken file) 
in
> an enhancement request - or change this bug's status and description 
appropriately.

I agree based on the above.  I have changed the status/descr just now.

Thanks again :)


-- 
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]

Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization

[Yoav Shapira]

Brad,
Fixed means fixed in the source code repository.  It'll be included in the next
build, and that build will be ready when it's ready.  If you want it sooner,
build Tomcat from SVN trunk.

(This is how Tomcat and most other FOSS projects operate)

Yoav

--- Brad O'Hearne <[EMAIL PROTECTED]> wrote:

> Bill,
> 
> If I am reading this right, it says the bug is fixed. When will there  
> be a new release that contains this fix? (Sorry for my ignorance on  
> the organization of Tomcat builds).
> 
> B
> 
> On Oct 20, 2005, at 9:15 PM, Bill Barker wrote:
> 
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=37044
> >
> > - Original Message - From: "Brad O'Hearne"  
> > <[EMAIL PROTECTED]>
> > To: "Tomcat Developers List" 
> > Sent: Thursday, October 20, 2005 8:35 PM
> > Subject: Bug in RealmBase, JAASRealm, and/or Requestt object  
> > preventing proper role authorization
> >
> >
> >
> >> All,
> >>
> >> I have discovered a bug in role authorization when using a  
> >> JAASRealm and
> >> custom user / role principals. In a nutshell, successful  
> >> authentication in
> >> the JAASRealm over a custom JAAS login module results in the  
> >> JAASRealm
> >> pulling the user principal and role principals out of the  
> >> authenticated
> >> subject and wrapping them inside a GenericPrincipal object. The  
> >> generic
> >> principle object is then stored in the request. Then, when  
> >> permissions are
> >> being checked in RealmBase.hasResourcePermission(), the following  
> >> line of
> >> code is executed to retrieve the user principal:
> >>
> >>Principal principal = request.getUserPrincipal();
> >>
> >> This method didn't return the wrapping generic principle, it  
> >> returned my
> >> custom user principle. The code for the requests getUserPrincipal 
> >> () method is
> >> as follows:
> >>
> >>public Principal getUserPrincipal() {
> >>if (userPrincipal instanceof GenericPrincipal) {
> >>return ((GenericPrincipal)  
> >> userPrincipal).getUserPrincipal();
> >>} else {
> >>return (userPrincipal);
> >>}
> >>}
> >>
> >> Everything looks great so far, until you get to the logic which  
> >> actually
> >> checks the permissions. The RealmBase.hasRole() method starts with  
> >> this block
> >> of code (with an interesting opening comment):
> >>
> >>// Should be overriten in JAASRealm - to avoid pretty  
> >> inefficient
> >> conversions
> >>if ((principal == null) || (role == null) ||
> >>!(principal instanceof GenericPrincipal))
> >>return (false);
> >>
> >> When this statement executes, principal is not a GenericPrincipal,  
> >> by merits
> >> of the request's getUserPrincipal() method executed prior to  
> >> calling this
> >> method -- it is instead a custom user principal. This causes the  
> >> third part
> >> of the if condition to be true, causing the method to return  
> >> false, and the
> >> method to fail, and authorization to fail. So in other words,  
> >> whenever a
> >> custom principal is used, role authorization should be failing,  
> >> and since
> >> this is in RealmBase, not the JAASRealm subclass, I am assuming  
> >> that anyone
> >> with a custom principal isn't able to authorize any roles properly.
> >>
> >> The quick response might be to just use a GenericPrincipal type as  
> >> your custom
> >> principle. But this doesn't make sense either, because the hasRole  
> >> method is
> >> seeking the roles within the GenericPrincpal object (the user  
> >> principal)
> >> which must contain all the roles.  This is what is done by the  
> >> Realm code
> >> already. The problem is that the hasRole method needs the  
> >> GenericPrincipal
> >> wrapper that contains the roles, NOT the custom user principal  
> >> which does not
> >> contain the roles.
> >>
> >> It would be great if I am missing something But if not, I don't  
> >> know if where
> >> you want to consider the culprit for the bug, but it is certainly  
> >> a bug, and
> >> it breaks authorization. Please let me know what the options are  
> >> for getting
> >> this bug fixed, as it prevents container managed security in  
> >> Tomcat using
> >> JAAS.
> >>
> >> Thanks,
> >>
> >> Brad
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >
> >
> >
> > This message is intended only for the use of the person(s) listed  
> > above as the intended recipient(s), and may contain information  
> > that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended  
> > recipient, you may not read, copy, or distribute this message or  
> > any attachment. If you received this communication in error, please  
> > notify us immediately by e-mail and then delete all copies of this  
> > message and any attachments.
> >
> > In addition you should be aware that ordinary (unencrypted) e-mail

DO NOT REPLY [Bug 37100] - SEGV in mod_proxy_ajp

[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=37100


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-21 15:59 ---
Committed patch to trunk (r327185):
http://svn.apache.org/viewcvs.cgi?rev=327185&view=rev

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

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

Re: Sandbox ?

[Remy Maucherat]

Costin Manolache wrote:

Thanks !

I'll add few things I've worked on in the past - if people don't mind,
I'll create a sandbox/java and put everything in one tree, ant and
IDEs are smart enough to exclude/include different packages.

Let me know if any of this seems wrong:
- a smaller commons-logging impl, without any discovery tricks ( for runtime )


Another option is to rewrite using a robust platform (I favor 
java.util.logging). I don't know if that's really a possibility, though, 
as I didn't ask my boss about it ;)



- attempt to refactor util.buf to use ByteBuffers


And CharBuffer, I hope. So you'll be extending (ByteChunk extends 
ByteBuffer) ?


I'd like to add BufferedReader features to CharChunk (marking and 
readLine, as implementing these without owning the buffer is both hard 
and inefficient).



- coyote standalone
- a small demo for coyote standalone, using a rhino adapter.
- some additions to coyote - to make it a bit easier to use in standalone mode.


I have plans to use it to implement a coyote provider for JBoss 
remoting. This would be a good use case for your stuff.


Rémy

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

Re: Sandbox ?

[Costin Manolache]

On 10/21/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > Thanks !
> >
> > I'll add few things I've worked on in the past - if people don't mind,
> > I'll create a sandbox/java and put everything in one tree, ant and
> > IDEs are smart enough to exclude/include different packages.
> >
> > Let me know if any of this seems wrong:
> > - a smaller commons-logging impl, without any discovery tricks ( for 
> > runtime )
>
> Another option is to rewrite using a robust platform (I favor
> java.util.logging). I don't know if that's really a possibility, though,
> as I didn't ask my boss about it ;)
>

Well, that's what I'm  doing actually - I just hardcoded
java.util.logging ( well, I have 2 impl, one with println and one with
j.u.l ). The only thing is that I HATE the default formatting and
config - so I want to add a saner formatter, and use a
log4j.properties subset.



> > - attempt to refactor util.buf to use ByteBuffers
>
> And CharBuffer, I hope. So you'll be extending (ByteChunk extends
> ByteBuffer) ?

CharBuffer would go to MessageBytes.

I'm thinking more as an 'uses' - you create ByteBuffers ( maybe direct
buffers ), and
you set it in the ByteChunk. "Extend" is not the best choice - it
would be hard to work with direct ( or other ) buffers. I'm actually
thinking about adding some static methods as well for all the utils we
have in BB.



>
> I'd like to add BufferedReader features to CharChunk (marking and
> readLine, as implementing these without owning the buffer is both hard
> and inefficient).

That's a good idea.


>
> > - coyote standalone
> > - a small demo for coyote standalone, using a rhino adapter.
> > - some additions to coyote - to make it a bit easier to use in standalone 
> > mode.
>
> I have plans to use it to implement a coyote provider for JBoss
> remoting. This would be a good use case for your stuff.

Cool. It would also be interesting to do a small 'ab' test with coyote
standalone - with a small adapter that can take advantage of direct
access to buffers and converters.

I have most of the code - but needs cleanup, some is quite old ( 6-7
months for the logger ).

Costin

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

DO NOT REPLY [Bug 28222] - getRequestURL() in forwarded jsp/servlet doesn't return new url

[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=28222





--- Additional Comments From [EMAIL PROTECTED]  2005-10-21 21:14 ---
As mentioned in some of the previous comments, this fix seems to have broken
what was working for me in 5.0. For a demo of what happens, see

http://fdis.etg.gc.ca:8080/cdua3

for the Tomcat 5.0 version, and 

http://fdis.etg.gc.ca:8081/cdua3.3

for the Tomcat 5.5 version.

To see the difference in behaviour, click multiple times on the "English" and
"Français" hyperlinks at the top left of the screen. You will find out the 5.0
version works, but the 5.5 does not because it uses the jsp URL instead of the
Struts action. The code can be downloaded from the same website for inspection
(cdua3.tags.LinkTranslateURLTag.java).

As far as I am concerned, the only question to ask is: was the behavior of the
getRequestURL function broken in 5.0 - i.e., it was being used in the wrong way
by my application and I was lucky to get it to work-, or is it broken now?

Thank you for your attention on this matter.

-- 
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]

DO NOT REPLY [Bug 28222] - getRequestURL() in forwarded jsp/servlet doesn't return new url

[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=28222





--- Additional Comments From [EMAIL PROTECTED]  2005-10-22 00:04 ---
5.0 is broken and you were lucky

5.5 has the correct (as required by SRV.8.4) behaviour

The fix for your app should be simple, SRV.8.4 explains where you can get the
info you require.

-- 
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]

svn commit: r327594 - /tomcat/build/tc5.5.x/resources/build.xml

[jfclere]

Author: jfclere
Date: Fri Oct 21 15:15:44 2005
New Revision: 327594

URL: http://svn.apache.org/viewcvs?rev=327594&view=rev
Log:
Change cvs to svn and arrange locations.

Modified:
tomcat/build/tc5.5.x/resources/build.xml

Modified: tomcat/build/tc5.5.x/resources/build.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/build/tc5.5.x/resources/build.xml?rev=327594&r1=327593&r2=327594&view=diff
==
--- tomcat/build/tc5.5.x/resources/build.xml (original)
+++ tomcat/build/tc5.5.x/resources/build.xml Fri Oct 21 15:15:44 2005
@@ -18,15 +18,21 @@
   
 
   
-  
+  http://svn.apache.org/repos/asf/"; />
 
   
-  
-  
-  
-  
-  
+  
+  
+  
+  
+  
+
+  
+  
+  
+  
+  
 
   
   
@@ -37,7 +43,7 @@
   
   
+   value="${basedir}/${jasper.project}"/>
   
   
 
   
+  description="Update or checkout required sources from SVN">
 
 
+message="If the checkout fails, - todo - " />
 
-
-
-
-
-
+
+ 
+
+
+
+ 
+
+
+
+ 
+
+
+
+ 
+
+
+
+ 
+
 
   
 
   
 
-
-
+  
 
   
 



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