You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by tt...@ticnet.com on 2001/03/14 00:15:41 UTC
Strange problem with URL_PKG_PREFIXES
The Context.URL_PKG_PREFIXES environment variable is a colon-seperated list
of package prefixes. However, when I set this environment variable to
"org.jnp.interfaces:org.apache.naming" and attempt to get a Context;
Context ctx = new InitialContext().lookup("java:/comp");
The lookup fails with:
javax.naming.ConfigurationException: Provider URL missing
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:702)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:286)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:279)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at SimpleServlet.printContextInfo(SimpleServlet.java:153)
at SimpleServlet.doIt(SimpleServlet.java:99)
at SimpleServlet.doGet(SimpleServlet.java:29)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:534)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:325)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:262)
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:254)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2119)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:162)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:893)
at java.lang.Thread.run(Thread.java:484)
However, when I set this environment variable to
"org.apache.naming:org.jnp.interfaces"
The lookup succeeds!
"org.jnp.interfaces" only contains one class and that is
"org.jnp.interfaces.jnp.jnpURLContextFactory".
It seems to me that the lookup code is not correctly parsing the
Context.URL_PKG_PREFIXES environment variable.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: Strange problem with URL_PKG_PREFIXES
Posted by tt...@ticnet.com.
Remy Maucherat writes:
> > Remy Maucherat writes:
> >
> > > Quoting tttye@ticnet.com:
> > >
> > > > I am trying to make the <ejb-link> use jnp://ttt1:1099/EJBresource
> work.
> > >
> > > So it doesn't work either the other way around ?
> > No: ...
> > When I call 'lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");' in any
> > form, I get "javax.naming.NameNotFoundException: Name jnp: is not
> > bound in this Context"
> > When I encode the URL in the <ejb-link> I get
> > "javax.naming.NamingException: Cannot create resource instance"
>
> I did some testing on this.
> The integrated ENC was running fine even if the JNP URL prefix was appended
> before org.apache.naming (I had put jnpserver.jar in common/lib).
> However, trying to resolve a jnp: URL always failed :-(
>
> It could be a classloader problem after all. Where did you put the jnp JAR
> and its dependencies (if any) ?
I placed a link to jnp-client.jar in file:/usr/java/jdk1.3/jre/lib/ext/.
When I reference the libraries via InitialContext(env) as:
Hashtable env = new Properties();
env.put("java.naming.factory.initial",
(String)lc.lookup("env/ejb/naming/factory"));
env.put("java.naming.provider.url",
(String)lc.lookup("env/ejb/naming/provider"));
Context jb = new InitialContext(env);
Everything is found and works correctly.
However, reference via ctx.lookup("jnp....") always fails.
BTW, Even when I remove the jnp-client.jar from lib/ext, the InitialContext
lookup works.
>
> Remy
>
Re: Strange problem with URL_PKG_PREFIXES
Posted by tt...@ticnet.com.
Remy Maucherat writes:
>
> I've updated the object factory for the EJB references. It should now
> attempt to resolve ejb-links using a JNDI lookup.
> I can't really test the feature, so I'm waiting for your feedback and stack
> traces, if it goes wrong ;-)
>
> Remy
>
Ok, I will test with the 20010320 nightly build when it is available.
(I cannot access all of the Java code I need to build tomcat at work
because of a parinoid fire wall).
Tim
Re: Strange problem with URL_PKG_PREFIXES
Posted by tt...@ticnet.com.
Remy Maucherat writes:
> Quoting tttye@ticnet.com:
>
> >
> > Remy Maucherat writes:
> > > I've updated the object factory for the EJB references. It should now
> > > attempt to resolve ejb-links using a JNDI lookup.
> > > I can't really test the feature, so I'm waiting for your feedback and
> > stack
> > > traces, if it goes wrong ;-)
> > >
> > I finally got all pieces downloaded and compiled the change....
> > Now we get an exception on the correct class name...:
> >
> >
> > S_STRESS_31K [true] | org.apache.naming.EjbRef |
> > javax.naming.NamingException:
> > cool.models.coop07.java.S_STRESS_31KpsHome
> >
> > javax.naming.NamingException:
> > cool.models.coop07.java.S_STRESS_31KpsHome
>
> The exception isn't very clear. It can't load the home interface, right ?
> To debug that problem, the factory won't fail if loading of the home interface
> fails or if the type checking fails. If something like that happens, a message
> will be printed out on the console, but the bean instance will still be
> returned.
>
> However, if the factory can't load the home interface class, your servlet will
> probably not be able to either (which is a problem).
>
> Remy
Please do not test the class of the REMOTE OBJECT returned from the EJB
server.
The servlet has no problem loading or casting the remote object to the home
interface class because the servlet classes include the EJB client classes.
The actual object name of the remote object is $Proxy??? (where ??? is a
number between 0 and 999).
That proxy object represents the Home Interface and can be cast to the home
interface. But the remote object cannot be tested correctly with the
'Class' object.
Please use the following code snip, it includes the only test that actually
succeeds.
if (linkRefAddr != null) {
// Retrieving the EJB link
String ejbLink = linkRefAddr.getContent().toString();
Object beanObj = null;
try {
beanObj = (new InitialContext()).lookup(ejbLink);
String homeClassName = ref.getClassName();
if (!homeClassName.endsWith(beanObj.toString()))
System.out.println("EJB link \"" + ejbLink
+ "\" of EJB Object: " + beanObj
+ " is not castable to: " + homeClassName);
} catch (Exception e) {
System.out.println("EJB link \""+ejbLink+"\" failed: "+e);
}
return beanObj;
}
Tim
Re: Strange problem with URL_PKG_PREFIXES
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting tttye@ticnet.com:
>
> Remy Maucherat writes:
> > I've updated the object factory for the EJB references. It should now
> > attempt to resolve ejb-links using a JNDI lookup.
> > I can't really test the feature, so I'm waiting for your feedback and
> stack
> > traces, if it goes wrong ;-)
> >
> I finally got all pieces downloaded and compiled the change....
> Now we get an exception on the correct class name...:
>
>
> S_STRESS_31K [true] | org.apache.naming.EjbRef |
> javax.naming.NamingException:
> cool.models.coop07.java.S_STRESS_31KpsHome
>
> javax.naming.NamingException:
> cool.models.coop07.java.S_STRESS_31KpsHome
The exception isn't very clear. It can't load the home interface, right ?
To debug that problem, the factory won't fail if loading of the home interface
fails or if the type checking fails. If something like that happens, a message
will be printed out on the console, but the bean instance will still be
returned.
However, if the factory can't load the home interface class, your servlet will
probably not be able to either (which is a problem).
Remy
Re: Strange problem with URL_PKG_PREFIXES
Posted by tt...@ticnet.com.
Remy Maucherat writes:
> I've updated the object factory for the EJB references. It should now
> attempt to resolve ejb-links using a JNDI lookup.
> I can't really test the feature, so I'm waiting for your feedback and stack
> traces, if it goes wrong ;-)
>
I finally got all pieces downloaded and compiled the change....
Now we get an exception on the correct class name...:
S_STRESS_31K [true] | org.apache.naming.EjbRef |
javax.naming.NamingException: cool.models.coop07.java.S_STRESS_31KpsHome
javax.naming.NamingException: cool.models.coop07.java.S_STRESS_31KpsHome
at org.apache.naming.NamingContext.lookup(NamingContext.java:837)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:194)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:183)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at SimpleServlet.printContextInfo(SimpleServlet.java:177)
at SimpleServlet.doIt(SimpleServlet.java:99)
at SimpleServlet.doGet(SimpleServlet.java:29)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:534)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:325)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:262)
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:254)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:213)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:162)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:827)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:904)
at java.lang.Thread.run(Thread.java:484)
Re: Strange problem with URL_PKG_PREFIXES
Posted by Remy Maucherat <re...@apache.org>.
> Thanks, I look forward to the final patch.
>
> I placed jnp-client.jar in jdk1.3/jdk/lib/ext and removed a hand build jar
> (containing only jnpURLContextFactory) in jakarta-tomcat-4.0/common/lib.
> Finally, setting
> "java.naming.factory.url.pkgs = org.apache.naming:org.jnp.interfaces".
> Tim
I've updated the object factory for the EJB references. It should now
attempt to resolve ejb-links using a JNDI lookup.
I can't really test the feature, so I'm waiting for your feedback and stack
traces, if it goes wrong ;-)
Remy
Re: Strange problem with URL_PKG_PREFIXES
Posted by tt...@ticnet.com.
Thanks, I look forward to the final patch.
I placed jnp-client.jar in jdk1.3/jdk/lib/ext and removed a hand build jar
(containing only jnpURLContextFactory) in jakarta-tomcat-4.0/common/lib.
Finally, setting
"java.naming.factory.url.pkgs = org.apache.naming:org.jnp.interfaces".
Tim
Remy Maucherat writes:
> Quoting tttye@ticnet.com:
>
> > I've got some of the lookup working now, but <ejb-link> still fails:
> > WORKS--> lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");
> > WORKS--> ho =
> > (EJBHome)ctx.lookup("jnp://ttt1.ca.com:1099/S_STRESS_31Kps");
> > FAILS--- ho = (EJBHome)ctx.lookup("java:/comp/ejb/S_STRESS_31K");
>
> Wahoo, way cool :-)
>
> I think I can easily fix the last one by applying a simple patch to the EJB
> object factory.
>
> BTW, how did you fix your problems ?
>
> Remy
Re: Strange problem with URL_PKG_PREFIXES
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting tttye@ticnet.com:
> I've got some of the lookup working now, but <ejb-link> still fails:
> WORKS--> lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");
> WORKS--> ho =
> (EJBHome)ctx.lookup("jnp://ttt1.ca.com:1099/S_STRESS_31Kps");
> FAILS--- ho = (EJBHome)ctx.lookup("java:/comp/ejb/S_STRESS_31K");
Wahoo, way cool :-)
I think I can easily fix the last one by applying a simple patch to the EJB
object factory.
BTW, how did you fix your problems ?
Remy
Re: Strange problem with URL_PKG_PREFIXES
Posted by tt...@ticnet.com.
I've got some of the lookup working now, but <ejb-link> still fails:
WORKS--> lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");
WORKS--> ho =
(EJBHome)ctx.lookup("jnp://ttt1.ca.com:1099/S_STRESS_31Kps");
FAILS--- ho = (EJBHome)ctx.lookup("java:/comp/ejb/S_STRESS_31K");
Web.xml entry:
<ejb-ref>
<description>Sample bean generated by coolgen placed here for ease
of early testing</description>
<ejb-ref-name>ejb/S_STRESS_31K</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>cool.models.coop07.java.S_STRESS_31KpsHome</home>
<remote>cool.models.coop07.java.S_STRESS_31Kps</remote>
<ejb-link>jnp://ttt1.ca.com:1099/S_STRESS_31Kps</ejb-link>
</ejb-ref>
javax.naming.NamingException: Cannot create resource instance
at org.apache.naming.NamingContext.lookup(NamingContext.java:837)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:194)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:183)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at SimpleServlet.printContextInfo(SimpleServlet.java:177)
at SimpleServlet.doIt(SimpleServlet.java:99)
at SimpleServlet.doGet(SimpleServlet.java:29)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:534)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:325)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:262)
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:254)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2119)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:162)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:893)
at java.lang.Thread.run(Thread.java:484)
Remy Maucherat writes:
> > Remy Maucherat writes:
> >
> > > Quoting tttye@ticnet.com:
> > >
> > > > I am trying to make the <ejb-link> use jnp://ttt1:1099/EJBresource
> work.
> > >
> > > So it doesn't work either the other way around ?
> > No: ...
> > When I call 'lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");' in any
> > form, I get "javax.naming.NameNotFoundException: Name jnp: is not
> > bound in this Context"
> > When I encode the URL in the <ejb-link> I get
> > "javax.naming.NamingException: Cannot create resource instance"
>
> I did some testing on this.
> The integrated ENC was running fine even if the JNP URL prefix was appended
> before org.apache.naming (I had put jnpserver.jar in common/lib).
> However, trying to resolve a jnp: URL always failed :-(
>
> It could be a classloader problem after all. Where did you put the jnp JAR
> and its dependencies (if any) ?
>
> Remy
>
Re: Strange problem with URL_PKG_PREFIXES
Posted by Remy Maucherat <re...@apache.org>.
> Remy Maucherat writes:
>
> > Quoting tttye@ticnet.com:
> >
> > > I am trying to make the <ejb-link> use jnp://ttt1:1099/EJBresource
work.
> >
> > So it doesn't work either the other way around ?
> No: ...
> When I call 'lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");' in any
> form, I get "javax.naming.NameNotFoundException: Name jnp: is not
> bound in this Context"
> When I encode the URL in the <ejb-link> I get
> "javax.naming.NamingException: Cannot create resource instance"
I did some testing on this.
The integrated ENC was running fine even if the JNP URL prefix was appended
before org.apache.naming (I had put jnpserver.jar in common/lib).
However, trying to resolve a jnp: URL always failed :-(
It could be a classloader problem after all. Where did you put the jnp JAR
and its dependencies (if any) ?
Remy
Re: Strange problem with URL_PKG_PREFIXES
Posted by tt...@ticnet.com.
Remy Maucherat writes:
> Quoting tttye@ticnet.com:
>
> > I am trying to make the <ejb-link> use jnp://ttt1:1099/EJBresource work.
>
> So it doesn't work either the other way around ?
No: ...
When I call 'lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");' in any
form, I get "javax.naming.NameNotFoundException: Name jnp: is not
bound in this Context"
When I encode the URL in the <ejb-link> I get
"javax.naming.NamingException: Cannot create resource instance"
>
> > I need to resolve this type of URL link in Jakarta to allow seperation
> > between the JSP server and the EJB server.
> > The org.apache.naming.NamingContext does not seem to pass the correct
> > information to NamingManager so it can connect to the jnpURLNaming....
> > Can you think of anything else to try?
>
> If you call (new InitialContext()).lookup("jnp://ttt1:1099/EJBresource"), then
> it's supposed to work if the jnp URL context factory is in the classpath.
> Nothing special has to be done in NamingContext (the same is true for the java
> URLs and JNP - that's why I can't figure out why it doesn't work).
>
Re: Strange problem with URL_PKG_PREFIXES
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting tttye@ticnet.com:
> Remy,
> Thanks for helping me look into this problem.
> I believe that short term, prepending the apache pkg prefix is a simple
> way
> to make results consistent.
I'll put that in this evening.
> I thought that some of my problem might be from having out of date
> 'org.jnp.interface' library. I have looked all morning, and cannot
> find
> anything outside of JBoss that includes this jar, so I have no
> explaination
> why Jakarta is able to get a naming context from JBoss instead of Class
> load fail!!! How do I find out where a servlet class loader is
> obtaining a
> class from (which jar path)?
You don't :-(
We just register the class repositories in a URLClassLoader, and let it do its
magic.
> I am trying to make the <ejb-link> use jnp://ttt1:1099/EJBresource work.
So it doesn't work either the other way around ?
> I need to resolve this type of URL link in Jakarta to allow seperation
> between the JSP server and the EJB server.
> The org.apache.naming.NamingContext does not seem to pass the correct
> information to NamingManager so it can connect to the jnpURLNaming....
> Can you think of anything else to try?
If you call (new InitialContext()).lookup("jnp://ttt1:1099/EJBresource"), then
it's supposed to work if the jnp URL context factory is in the classpath.
Nothing special has to be done in NamingContext (the same is true for the java
URLs and JNP - that's why I can't figure out why it doesn't work).
The com.sun.naming.internal.ResourceManager.getFactory method which is
ultimately called to return the appropriate URL context factory seems to be
doing what's expected.
Of course, the usual suspect when something really strange happens in Catalina
is the classloader, so it may be the root cause of this.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: Strange problem with URL_PKG_PREFIXES
Posted by tt...@ticnet.com.
Remy,
Thanks for helping me look into this problem.
I believe that short term, prepending the apache pkg prefix is a simple way
to make results consistent.
I thought that some of my problem might be from having out of date
'org.jnp.interface' library. I have looked all morning, and cannot find
anything outside of JBoss that includes this jar, so I have no explaination
why Jakarta is able to get a naming context from JBoss instead of Class
load fail!!! How do I find out where a servlet class loader is obtaining a
class from (which jar path)?
I am trying to make the <ejb-link> use jnp://ttt1:1099/EJBresource work.
I need to resolve this type of URL link in Jakarta to allow seperation
between the JSP server and the EJB server.
The org.apache.naming.NamingContext does not seem to pass the correct
information to NamingManager so it can connect to the jnpURLNaming....
Can you think of anything else to try?
Remy Maucherat writes:
> > According to NamingManager documentation, first it will look for
> > 'org.jnp.interfaces.java.javaURLContextFactory' which does not exist, so
> it
> > should next look for 'org.apache.naming.java.javaURLContextFactory' which
> > does exist.
> > So, this should work.
>
> Indeed, my mistake. It should work, since the IC will only call lookup on
> the Context produced by the IC factory *after* checking the URLs.
>
> > BTW, the 'org.apache.naming' prefix is concatenated onto the URL prefixes
> by
> > jakarta.
>
> Since I can't figure out where the problem is coming from, I can change it
> and make 'org.apache.naming' a prefix.
>
> > Also, when the jnp.jar is removed, it still fails with the same
> > error.
> > How can this be made to work?
>
> Don't you get a no initial context factory found when you remove JNP ?
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: Strange problem with URL_PKG_PREFIXES
Posted by Remy Maucherat <re...@apache.org>.
> According to NamingManager documentation, first it will look for
> 'org.jnp.interfaces.java.javaURLContextFactory' which does not exist, so
it
> should next look for 'org.apache.naming.java.javaURLContextFactory' which
> does exist.
> So, this should work.
Indeed, my mistake. It should work, since the IC will only call lookup on
the Context produced by the IC factory *after* checking the URLs.
> BTW, the 'org.apache.naming' prefix is concatenated onto the URL prefixes
by
> jakarta.
Since I can't figure out where the problem is coming from, I can change it
and make 'org.apache.naming' a prefix.
> Also, when the jnp.jar is removed, it still fails with the same
> error.
> How can this be made to work?
Don't you get a no initial context factory found when you remove JNP ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: Strange problem with URL_PKG_PREFIXES
Posted by Tim Tye <tt...@ticnet.com>.
According to NamingManager documentation, first it will look for
'org.jnp.interfaces.java.javaURLContextFactory' which does not exist, so it
should next look for 'org.apache.naming.java.javaURLContextFactory' which
does exist.
So, this should work.
BTW, the 'org.apache.naming' prefix is concatenated onto the URL prefixes by
jakarta. Also, when the jnp.jar is removed, it still fails with the same
error.
How can this be made to work?
----- Original Message -----
From: Remy Maucherat <re...@apache.org>
To: <to...@jakarta.apache.org>
Sent: Tuesday, March 13, 2001 5:49 PM
Subject: Re: Strange problem with URL_PKG_PREFIXES
> > The Context.URL_PKG_PREFIXES environment variable is a colon-seperated
> list
> > of package prefixes. However, when I set this environment variable to
> > "org.jnp.interfaces:org.apache.naming" and attempt to get a Context;
> > Context ctx = new InitialContext().lookup("java:/comp");
> > The lookup fails with:
> > javax.naming.ConfigurationException: Provider URL missing
> > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:702)
>
> > However, when I set this environment variable to
> > "org.apache.naming:org.jnp.interfaces"
> > The lookup succeeds!
> > "org.jnp.interfaces" only contains one class and that is
> > "org.jnp.interfaces.jnp.jnpURLContextFactory".
> > It seems to me that the lookup code is not correctly parsing the
> > Context.URL_PKG_PREFIXES environment variable.
>
> It looks like the JNP InitialContext has a custom way to retrieve URL
> contexts.
> It's supposed to call NamingManager.getURLContext (see the
> javax.naming.InitialContext source code for more details).
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: Strange problem with URL_PKG_PREFIXES
Posted by Remy Maucherat <re...@apache.org>.
> The Context.URL_PKG_PREFIXES environment variable is a colon-seperated
list
> of package prefixes. However, when I set this environment variable to
> "org.jnp.interfaces:org.apache.naming" and attempt to get a Context;
> Context ctx = new InitialContext().lookup("java:/comp");
> The lookup fails with:
> javax.naming.ConfigurationException: Provider URL missing
> at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:702)
> However, when I set this environment variable to
> "org.apache.naming:org.jnp.interfaces"
> The lookup succeeds!
> "org.jnp.interfaces" only contains one class and that is
> "org.jnp.interfaces.jnp.jnpURLContextFactory".
> It seems to me that the lookup code is not correctly parsing the
> Context.URL_PKG_PREFIXES environment variable.
It looks like the JNP InitialContext has a custom way to retrieve URL
contexts.
It's supposed to call NamingManager.getURLContext (see the
javax.naming.InitialContext source code for more details).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org