DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-30 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

Anjana Fernando  changed:

   What|Removed |Added

 CC||laferna...@gmail.com

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-31 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Mark Thomas  2011-08-31 14:20:15 UTC ---
Given that the JNDI context is meant to be (largely) read-only, I don't think
calls to close() should be permitted here. I have added a call to
checkWriteable() before the environment is cleared.

This fix has been applied to trunk and 7.0.x and will be included in 7.0.22
onwards.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-31 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #2 from Anjana Fernando  2011-08-31 14:33:31 
UTC ---
Hi Mark,

So for the situation I'm facing, in the close method, if the environment is
cleared, will this be removed from "ContextBindings" also? .. Since that was
the problem I faced. 

Cheers,
Anjana.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-31 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #3 from Mark Thomas  2011-08-31 14:35:00 UTC ---
No. The attempt to use the close() method will fail.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-31 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #4 from Anjana Fernando  2011-08-31 14:43:14 
UTC ---
Hi Mark,

Sorry, maybe I misunderstood, I guessed the modified version would be something
like the following,

public void close() throws NamingException {
if (checkWriteable()) {
env.clear();
} else {
throw something...
}
}

so in the case of checkWriteable() == true, the environment is cleared and if
the user again looks up that context, wouldn't my same problem occur again? .. 

Cheers,
Anjana.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-31 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #5 from Mark Thomas  2011-08-31 14:48:59 UTC ---
Rather than guessing why don't you look at the source code and see what it
actually does? You might also want to investigate when the JNDI context is
writeable.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-31 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #6 from Anjana Fernando  2011-08-31 15:32:13 
UTC ---
Hi Mark,

OK, sorry, I should have looked at the code before. I just didn't know where
the svn for this was (yeah it was a simple looking around the tomcat project
page), I thought you wouldn't mind showing the code. 

Anyways, yeah, the code was close to what I assumed. So a quick question, let's
assume the context is writeable (I'm still not that sure when they are exactly
writeable or not), just bare with me, so in the case where "checkWriteable"
doesn't throw anything, wouldn't you want to clear this object from the map at
ContextBindings?, so later the method "getBoundContext" from SelectorContext
wouldn't return an invalid Context object, and also I guess you would want to
remove it from that map for it to be GC'ed later. 

Cheers,
Anjana.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-31 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #7 from Mark Thomas  2011-08-31 15:37:20 UTC ---
I'll repeat: "You might also want to investigate when the JNDI context is
writeable."

I really do not appreciate code reviews based on guess work. If you are going
to comment on the code please have the courtesy to read and understand the
relevant portions of the source rather than guessing what the source code might
be.

I do not intend replying to further comments on this issue until you have
actually read the relevant code.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-08-31 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #8 from Anjana Fernando  2011-08-31 15:57:33 
UTC ---
Mark,

You could have used all those words to give me a simple explanation, I gave the
comments and reported the bug to my ability, I explained the issue as I
understood it, and since I actually faced it, it's not like I "guessed" this
issue or imagined it and reported it. And I accept I'm not in any kind of an
expert in these areas, that's why we talk to you guys, the actual developers,
to get some help. Talking about "courtesy", you should have the common courtesy
to give a proper response or at-least direct the user to some resources to
understand it more. So much for the spirit of open source development! .. I
don't expect you to respond to this also, good bye!.

Cheers,
Anjana.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-10-25 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

Leonid Mikhailov  changed:

   What|Removed |Added

Version|7.0.14  |7.0.22
 OS/Version|Linux   |Windows 7

--- Comment #9 from Leonid Mikhailov  2011-10-25 21:17:49 
UTC ---
Guys,

It appears that something is not quite right with this fix in 7.0.22. The
following worked just fine in 7.0.14 (and GlassFish, WebLogic, and WebSphere)
and now fails on envCtx.close() with "Context is read only" message.

javax.naming.Context initCtx = new InitialContext();
javax.naming.Context envCtx = (javax.naming.Context)
initCtx.lookup("java:comp/env");
//some clever logic that uses envCtx
envCtx.close();//Fails here!
initCtx.close();

According to JavaDoc I should be able to safely close the context when I am
done with it.  

Thanks,

Leon

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-10-26 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

Konstantin Kolinko  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
 OS/Version||All

--- Comment #10 from Konstantin Kolinko  2011-10-26 
11:01:34 UTC ---
Reopening, so that new issue in comment 9 is not lost.
Do you have a stack trace?

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-10-26 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #11 from Leonid Mikhailov  2011-10-26 21:24:19 
UTC ---
Here you go:

javax.naming.NamingException: Context is read only
at org.apache.naming.NamingContext.checkWritable(NamingContext.java:941)
at org.apache.naming.NamingContext.close(NamingContext.java:747)
at
com.esri.sds.rest.AdminDatasourcesResource.listDatasources(AdminDatasourcesResource.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:149)
at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:259)
at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:990)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:941)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:932)
at
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:384)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:451)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:797)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:770)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:731)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:964)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Thanks,

Leon

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-10-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #12 from Mark Thomas  2011-10-27 16:11:07 UTC ---
To quote from section EE.5.3.4 of the Java EE spec

The container must ensure that the application component instances have only
read access to their naming context. The container must throw the
javax.naming.OperationNotSupportedException from all the methods of the
javax.naming.Context interface that modify the environment naming context and
its subcontexts.


I would argue that the close() method is a method that "modifies the
environment naming context" and therefore an exception should be thrown here.
Tomcat is, however, not throwing the right exception in this case. Fortunately,
the exception we should be throwing is a sub-class of the one we are throwing
so changing it shouldn't break anything.

Providing an option on the StandardContext to silently swallow this error
rather than throwing an Exception looks doable. I'll take a look.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-10-28 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

Mark Thomas  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Mark Thomas  2011-10-28 14:33:29 UTC ---
The correct exception is now thrown and the option to control whether or not an
exception is thrown has been added to the StandardContext.

Both of these changes have been made to trunk and 7.0.x and will be included in
7.0.23 onwards.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2011-12-01 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #14 from Leonid Mikhailov  2011-12-01 23:17:40 
UTC ---
(In reply to comment #13)
> The correct exception is now thrown and the option to control whether or not 
> an
> exception is thrown has been added to the StandardContext.
> 
> Both of these changes have been made to trunk and 7.0.x and will be included 
> in
> 7.0.23 onwards.

Mark,

I just installed 7.0.23 and I still see "Context is read only" exception
thrown. 

In your previous message you mentioned:
> To quote from section EE.5.3.4 of the Java EE spec
> 
> The container must ensure that the application component instances have only
> read access to their naming context. The container must throw the
> javax.naming.OperationNotSupportedException from all the methods of the
> javax.naming.Context interface that modify the environment naming context and
> its subcontexts.
> 
> 
> I would argue that the close() method is a method that "modifies the
> environment naming context" and therefore an exception should be thrown here.

I hoped to avoid an argument but... I believe you are not interpreting the spec
correctly. Here is a recommendation from a tutorial
(http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/close.html)
explaining how one is supposed to work with Contexts:

"Normal garbage collection takes care of removing Context instances when they
are no longer in use. Connections used by Context instances being garbage
collected will be closed automatically. Therefore, you do not need to
explicitly close connections. Network connections, however, are limited
resources and for certain programs, you might want to have control over their
proliferation and usage." 

And here is a promoted usage pattern:
// Create initial context
DirContext ctx = new InitialDirContext(env);
// Get a copy of the same context
Context ctx2 = (Context)ctx.lookup("");
// Get a child context
Context ctx3 = (Context) ctx.lookup("ou=NewHires");
// do something useful with ctx, ctx2, ctx3
// Close the contexts when we're done
ctx.close();
ctx2.close();
ctx3.close();

Closing a context has nothing to do with modifying it - you are just telling
the system that you are done with a resource and it can be safely released at
this time. Modifying a context means adding and/or deleting something from it. 

I have written a sample application that works as described above with no
logged exceptions in GlassFish and in all Tomcat versions prior to 7.0.22. 
I can send it to you if you like.

I don't believe the current implementation is correct. No exceptions should be
logged by default.

Regards,

Leon

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2012-03-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

--- Comment #15 from mmaure...@gmail.com 2012-03-27 22:03:48 UTC ---
I'm using Tomcat 7.0.25 and am still seeing this same issue. Any attempt to
close a Context object results in the exception "Context is read only", and I
am unable to instantiate a JNDI DataSource. My code worked fine on previous
versions (earlier than 7.0.22), but is now broken.

Are we supposed to just leave the Context open, and it will not cause memory
leaks?

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 51744] JNDI Lookup Error after a Context is closed

2012-03-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=51744

mmaure...@gmail.com changed:

   What|Removed |Added

 CC||mmaure...@gmail.com

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org