You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by jf...@apache.org on 2002/06/12 11:56:57 UTC
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_endpoint.c
jfclere 2002/06/12 02:56:57
Modified: jk/native2/common jk_endpoint.c
Log:
Prevent core when createSlot fails.
Revision Changes Path
1.19 +7 -1 jakarta-tomcat-connectors/jk/native2/common/jk_endpoint.c
Index: jk_endpoint.c
===================================================================
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_endpoint.c,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- jk_endpoint.c 10 Jun 2002 21:55:06 -0000 1.18
+++ jk_endpoint.c 12 Jun 2002 09:56:57 -0000 1.19
@@ -86,8 +86,14 @@
snprintf( shmName, 128, "epStat.%d", wEnv->childId );
wEnv->epStat=wEnv->shm->createSlot( env, wEnv->shm, shmName, 8096 );
+ if (wEnv->epStat==NULL) {
+ env->l->jkLog(env, env->l, JK_LOG_ERROR,
+ "workerEnv.init() create slot %s failed\n", shmName );
+ return JK_ERR;
+ }
wEnv->epStat->structCnt=0;
- env->l->jkLog(env, env->l, JK_LOG_ERROR, "workerEnv.init() create slot %s\n", shmName );
+ env->l->jkLog(env, env->l, JK_LOG_ERROR,
+ "workerEnv.init() create slot %s\n", shmName );
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Remy Maucherat <re...@apache.org>.
Arshad Mahmood wrote:
> Remy,
>
> I will send you the config files shortly (they're on a laptop I don't have
> access to at the moment).
>
> My situation does have one unique feature. The servlet which is causing
> these issues is in a jar which I
> have installed under "common/lib". The reason I have done this is because
> the servlet acts in a similar
> manner to the struts controller servlet, in that it catches all urls and
> then dispatches to appropriate
> action classes. All action classes are also in this jar so I shouldn't have
> any classloader related problems, the web
> applications have some config files (accessed via getResourceAsStream) and
> JSP files.
>
> That is the only difference I can think of, everything else is normal usage.
> As I say I will forward you the files later today or early tomorrow.
I'll test that scenario and see what happens.
Q: Is your servlet used by more than one webapp, or is it used in only
one webapp ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
Remy,
I will send you the config files shortly (they're on a laptop I don't have
access to at the moment).
My situation does have one unique feature. The servlet which is causing
these issues is in a jar which I
have installed under "common/lib". The reason I have done this is because
the servlet acts in a similar
manner to the struts controller servlet, in that it catches all urls and
then dispatches to appropriate
action classes. All action classes are also in this jar so I shouldn't have
any classloader related problems, the web
applications have some config files (accessed via getResourceAsStream) and
JSP files.
That is the only difference I can think of, everything else is normal usage.
As I say I will forward you the files later today or early tomorrow.
Regards,
Arshad
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Friday, June 14, 2002 4:45 PM
Subject: Re: JNDI with a custom factory not working
> > I had a look at the JNDI example, unfortunately it wasn't totally
relevant
> > as everything
> > is defined in the web.xml and that has always worked for me.
> >
> > After a lot more debugging and I am getting even more confused (!!!). I
put
> > some trace
> > into the "init" function of my servlet. It's within the "init" that I do
the
> > JNDI name lookups.
> > The "init" gets called twice per servlet. On the first call everything
is OK
> > and my lookup
> > succeeds. The second time however the lookup fails with a
NamingException.
> >
> > I notice that the first time the "init" gets called, the context
returned
> > has the bindings I expect.
> > The second call to "init" which performs identical processing gets a
> > NamingContext with
> > nothing bound (I don't have any entries in the web.xml, had I defined
any I
> > think they would be
> > the only entries there).
> >
> > It also looked like the two inits were done by different class loaders,
as I
> > defined some static
> > members and they were not carried across to the second init.
> >
> > Can anybody explain why the "init" may be called twice?
>
> This is a very odd behavior, and I will try to reproduce it. From what
> I've seen in your config, you are using a load-on-startup servlet. Do
> you have anything else which isn't the default ?
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Remy Maucherat <re...@apache.org>.
> I had a look at the JNDI example, unfortunately it wasn't totally relevant
> as everything
> is defined in the web.xml and that has always worked for me.
>
> After a lot more debugging and I am getting even more confused (!!!). I put
> some trace
> into the "init" function of my servlet. It's within the "init" that I do the
> JNDI name lookups.
> The "init" gets called twice per servlet. On the first call everything is OK
> and my lookup
> succeeds. The second time however the lookup fails with a NamingException.
>
> I notice that the first time the "init" gets called, the context returned
> has the bindings I expect.
> The second call to "init" which performs identical processing gets a
> NamingContext with
> nothing bound (I don't have any entries in the web.xml, had I defined any I
> think they would be
> the only entries there).
>
> It also looked like the two inits were done by different class loaders, as I
> defined some static
> members and they were not carried across to the second init.
>
> Can anybody explain why the "init" may be called twice?
This is a very odd behavior, and I will try to reproduce it. From what
I've seen in your config, you are using a load-on-startup servlet. Do
you have anything else which isn't the default ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, June 13, 2002 7:11 PM
Subject: Re: JNDI with a custom factory not working
> Arshad Mahmood wrote:
> > Hmm, I will investigate further. It seemed to be that "ResourceLink" in
the
> > server.xml
> > "<Context" entry was going into a naming context with name
> > "//Standard/myapp" but
> > the one which I retrieved from the servlet was called
> > "//Standard/localhost/webapp". I will
> > debug this further.
>
> The context name is not important for the global context. The
> ResourceLink are actually yet another reference which is bound into the
> webapp naming context, and use a standard JNDI object factory
> (factory.ResourceLinkFactory). The lookup in the actual global context
> then just uses a static reference instead of another lookup.
I had a look at the JNDI example, unfortunately it wasn't totally relevant
as everything
is defined in the web.xml and that has always worked for me.
After a lot more debugging and I am getting even more confused (!!!). I put
some trace
into the "init" function of my servlet. It's within the "init" that I do the
JNDI name lookups.
The "init" gets called twice per servlet. On the first call everything is OK
and my lookup
succeeds. The second time however the lookup fails with a NamingException.
I notice that the first time the "init" gets called, the context returned
has the bindings I expect.
The second call to "init" which performs identical processing gets a
NamingContext with
nothing bound (I don't have any entries in the web.xml, had I defined any I
think they would be
the only entries there).
It also looked like the two inits were done by different class loaders, as I
defined some static
members and they were not carried across to the second init.
Can anybody explain why the "init" may be called twice?
> > I will have a look at the JNDI example servlet. I must confess I was
using
> > the
> > JNDI-Howto in the docs.
>
> Which may not be totally accurate, and don't talk at all about how it
> actually works.
>
> > The latest version of 4.1 from CVS (although it's a little broken
because
> > MBeanUtils
> > does't compile, but I am not using that anyway).
>
> Really ? It does build for me. What's the problem ?
> I do get an exception on shutdown, or when removing a context, though.
Sorry, ant problems. I think the date on my machine may be a bit slow and
hence
when I did an update it didn't recompile everything.
Regards.
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Remy Maucherat <re...@apache.org>.
Arshad Mahmood wrote:
> Hmm, I will investigate further. It seemed to be that "ResourceLink" in the
> server.xml
> "<Context" entry was going into a naming context with name
> "//Standard/myapp" but
> the one which I retrieved from the servlet was called
> "//Standard/localhost/webapp". I will
> debug this further.
The context name is not important for the global context. The
ResourceLink are actually yet another reference which is bound into the
webapp naming context, and use a standard JNDI object factory
(factory.ResourceLinkFactory). The lookup in the actual global context
then just uses a static reference instead of another lookup.
> I will have a look at the JNDI example servlet. I must confess I was using
> the
> JNDI-Howto in the docs.
Which may not be totally accurate, and don't talk at all about how it
actually works.
> The latest version of 4.1 from CVS (although it's a little broken because
> MBeanUtils
> does't compile, but I am not using that anyway).
Really ? It does build for me. What's the problem ?
I do get an exception on shutdown, or when removing a context, though.
> Thanks for your help. I will try and pin the problem down a bit more.
Sounds good.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, June 13, 2002 6:51 PM
Subject: Re: JNDI with a custom factory not working
> Arshad Mahmood wrote:
> > I do get the same context when I ask for it in my web application. The
> > problem
> > is that I can see from the debug that my "Resource" definitions in the
> > global naming resources appear to be in one context,
>
> Indeed, the global resources go into a separate context.
>
> > the "ResourceLink" I
> > have defined in
> > the "<Context" for my webapp go into another, but the one I am given
when I
> > use
> > a lookup for "java:comp/env" in my servlet init function appears to have
> > only those
> > defined in the web.xml.
>
> Both of these should go in the same context or its subcontexts (for
> example, if your resource is "jdbc/db", then there will be a "jdbc"
> context child of "env", which will contain a "db" entry).
> Did you try to use the JNDI servlet in the servlet examples to see what
> was going on ? I believe it is quite useful for this.
Hmm, I will investigate further. It seemed to be that "ResourceLink" in the
server.xml
"<Context" entry was going into a naming context with name
"//Standard/myapp" but
the one which I retrieved from the servlet was called
"//Standard/localhost/webapp". I will
debug this further.
I will have a look at the JNDI example servlet. I must confess I was using
the
JNDI-Howto in the docs.
> > I realise you are incredibly busy, but if you have naming working, can
you
> > please try and
> > generate one with a custom factory. As I have followed the instructions
in
> > JNDI-Howto,
> > but the only things in the "bindings" when I retrieve the
"java:comp/env"
> > are the ones I have
> > defined in the web.xml, and these don't allow you to specify a factory.
>
> If the definitions from web.xml override the ones from server.xml,
> nothing will work (ie, even if you use the default DataSource factory,
> the reference will be missing some attributes).
> You can try removing the definition in web.xml to see what happens.
>
> BTW, which version of Tomcat are you using ?
The latest version of 4.1 from CVS (although it's a little broken because
MBeanUtils
does't compile, but I am not using that anyway).
Thanks for your help. I will try and pin the problem down a bit more.
Regards.
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Remy Maucherat <re...@apache.org>.
Arshad Mahmood wrote:
> I do get the same context when I ask for it in my web application. The
> problem
> is that I can see from the debug that my "Resource" definitions in the
> global naming resources appear to be in one context,
Indeed, the global resources go into a separate context.
> the "ResourceLink" I
> have defined in
> the "<Context" for my webapp go into another, but the one I am given when I
> use
> a lookup for "java:comp/env" in my servlet init function appears to have
> only those
> defined in the web.xml.
Both of these should go in the same context or its subcontexts (for
example, if your resource is "jdbc/db", then there will be a "jdbc"
context child of "env", which will contain a "db" entry).
Did you try to use the JNDI servlet in the servlet examples to see what
was going on ? I believe it is quite useful for this.
> I realise you are incredibly busy, but if you have naming working, can you
> please try and
> generate one with a custom factory. As I have followed the instructions in
> JNDI-Howto,
> but the only things in the "bindings" when I retrieve the "java:comp/env"
> are the ones I have
> defined in the web.xml, and these don't allow you to specify a factory.
If the definitions from web.xml override the ones from server.xml,
nothing will work (ie, even if you use the default DataSource factory,
the reference will be missing some attributes).
You can try removing the definition in web.xml to see what happens.
BTW, which version of Tomcat are you using ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, June 13, 2002 6:27 PM
Subject: Re: JNDI with a custom factory not working
> There was a simple bug until very recently which caused the resource
> defined in web.xml to override the one defined in server.xml (and then
> it didn't work).
> This bug has always been there, and it has been fixed to some extent in
> 4.1.3, although it is a partial fix (4.1.4 fixes the remaining issues).
>
> > To look into the problem I put some debug into the
> > "org.apache.naming.NamingContext" class in the
> > lookup method.
> >
> > I noticed that when this class was called a few times, the "name" member
> > varied between "//Standalone/myapp" amd
> > "//Standalone/localhost/myapp", etc.
>
> There is only one naming context per web application, and it is
> instantiated by the NamingContextListener.
>
> I don't understand how you get into that situation, and it is working
> fine for me overall (ie, if I do a lookup in a servlet, it always goes
> to the same context).
I do get the same context when I ask for it in my web application. The
problem
is that I can see from the debug that my "Resource" definitions in the
global naming resources appear to be in one context, the "ResourceLink" I
have defined in
the "<Context" for my webapp go into another, but the one I am given when I
use
a lookup for "java:comp/env" in my servlet init function appears to have
only those
defined in the web.xml.
I realise you are incredibly busy, but if you have naming working, can you
please try and
generate one with a custom factory. As I have followed the instructions in
JNDI-Howto,
but the only things in the "bindings" when I retrieve the "java:comp/env"
are the ones I have
defined in the web.xml, and these don't allow you to specify a factory.
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Remy Maucherat <re...@apache.org>.
Arshad Mahmood wrote:
> Remy,
>
> Thanks for you response. I didn't make myself very clear, I'll try again.
>
> The Problem
> =========
>
> In the server.xml have defined a global resourcce under the name
> "rohas/filecache".
> The resource params defines a "factory" along with other attributes.
> In my context I have defined a "ResourceLink" that maps to the
> global name (I have given them both the same name, I assume that
> doesn't make a difference).
>
> In the web.xml for my application I have defined a "resource-ref" that
> points to this resource.
>
> When I try and access the resource via an InitialContext in the "init"
> function of my servlet,
> I get a NamingException from
> org.apache.naming.factory.ResourceFactory.getObjectInstance.
There was a simple bug until very recently which caused the resource
defined in web.xml to override the one defined in server.xml (and then
it didn't work).
This bug has always been there, and it has been fixed to some extent in
4.1.3, although it is a partial fix (4.1.4 fixes the remaining issues).
> To look into the problem I put some debug into the
> "org.apache.naming.NamingContext" class in the
> lookup method.
>
> I noticed that when this class was called a few times, the "name" member
> varied between "//Standalone/myapp" amd
> "//Standalone/localhost/myapp", etc.
There is only one naming context per web application, and it is
instantiated by the NamingContextListener.
I don't understand how you get into that situation, and it is working
fine for me overall (ie, if I do a lookup in a servlet, it always goes
to the same context).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, June 13, 2002 5:33 PM
Subject: Re: JNDI with a custom factory not working
> Arshad Mahmood wrote:
> > ----- Original Message -----
> > From: "Ian Darwin" <ia...@darwinsys.com>
> > To: "Tomcat Developers List" <to...@jakarta.apache.org>; "Arshad
> > Mahmood" <ar...@compuvision.co.uk>
> > Sent: Thursday, June 13, 2002 1:48 AM
> > Subject: Re: JNDI with a custom factory not working
> >
> >
> >
> >>On June 12, 2002 07:45 am, Arshad Mahmood wrote:
> >>
> >>>I am having a problem trying to use a custom factory with JNDI. I get
an
> >>>exception froom org.apache.naming.factory.ResourceFactory. I have added
> >>>debug and it appears that my "factory" parameter is not being picked up
> >>>from the server.xml.
> >>>
> >>>Can somebody familiar with the naming code point me to the classes I
> >>
> > need
> >
> >>>to look at to trace this problem. Alternatively, if somebody can
confirm
> >>>that the JNDI-Howto example for a custom beanFactory works correctly in
> >>
> > 4.1
> >
> >>>(I have tried it and it doesn't) then I will look at my configuration
> >>>again.
> >>
> >>Doesn't work for me either. Inserting a listBindings() call for
> >
> > java:comp/env/bean
> >
> >>reveals nothing bound there.
> >
> >
> > I have traced the problem a little further and I think I know what the
> > problem is but I haven't got a clue how to fix it.
> >
> > Basically, it appears that a different NamingContext is created per
> > thread/class loader. Let's assume that you have a tomcat instance called
> > "Standalone", a virtual host "localhost" and a context "myapp".
> >
> > If you define any JNDI resources in the server.xml, then they appear to
be
> > put into a naming context call "//Standalone/myapp". Your resource
> > definitions in the web.xml go into the "//Standalone/localhost/myapp"
> > context.
> >
> > If you attempt to read the resources from your servlet then the
> > "//Standalone/localhost/myapp" context is used, this is ok for jdbc, etc
> > because the factory is hardwired into the naming code. But if you have
> > defined a custom factory then no definition exists in this context for
that
> > (because it's been put into the "//Standalone/myapp" context). I believe
> > this also goes for any parameters that you have defined.
> >
> > The fix would appear to be for Tomcat to put the resources under the
virtual
> > in the first place for those defined in the server.xml. There is still
an
> > issue though for the "global resources" as I am not sure you can link to
> > them because they are under a different naming context.
> >
> > This is an initial investigation so my analysis may be FLAWED.
> >
> > Remy, does this explanation of how the naming contexts are defined/used
make
> > sense ?
>
> I'm not sure I understand very well, so I'll assume it's a problem with
> the links.
>
> The global resources defined in server.xml are not accessible by default
> in the web applications (because you may want to restrict some to
> specific webapps, etc). So you have to link them using a ResourceLink
> element. You can also define the resource links in the default context
> so that all your contexts in your host or engine will have the link,
> instead of having to define it in each one.
> The admin webapp will have full support for this shortly (I reckon that
> configuring this is *hard* at the moment).
>
> Remy
Remy,
Thanks for you response. I didn't make myself very clear, I'll try again.
The Problem
=========
In the server.xml have defined a global resourcce under the name
"rohas/filecache".
The resource params defines a "factory" along with other attributes.
In my context I have defined a "ResourceLink" that maps to the
global name (I have given them both the same name, I assume that
doesn't make a difference).
In the web.xml for my application I have defined a "resource-ref" that
points to this resource.
When I try and access the resource via an InitialContext in the "init"
function of my servlet,
I get a NamingException from
org.apache.naming.factory.ResourceFactory.getObjectInstance.
To look into the problem I put some debug into the
"org.apache.naming.NamingContext" class in the
lookup method.
I noticed that when this class was called a few times, the "name" member
varied between "//Standalone/myapp" amd
"//Standalone/localhost/myapp", etc.
I was a bit surprised because I thought when I asked "java:comp/env" I would
always get the same "NamingContext" and
not different ones.
I then traced the code through
"org.apache.naming.java.javaURLContextFactory", which in turn uses
"org.apache.naming.SelectorContext".
The SelectorConext class uses "getBoundContext" to retrieve the appropriate
NamingContext to which it delegated
the lookup/bind/unbind, etc.
The getBoundContext then uses ContextBindings.getContext to get the context
(if doesn't exist then it creates a new one).
*** IMPORTANT *** The member variable initialContext is overriden inside the
"if" of this function (is this intentional).
ContextBindings appears to return a NamingContext based on the class loader
currenty in used. Hence the multiple contexts and why the name I am looking
for doesn't appear in the context which I am using for lookup.
Regards,
Arshad
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Remy Maucherat <re...@apache.org>.
Arshad Mahmood wrote:
> ----- Original Message -----
> From: "Ian Darwin" <ia...@darwinsys.com>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>; "Arshad
> Mahmood" <ar...@compuvision.co.uk>
> Sent: Thursday, June 13, 2002 1:48 AM
> Subject: Re: JNDI with a custom factory not working
>
>
>
>>On June 12, 2002 07:45 am, Arshad Mahmood wrote:
>>
>>>I am having a problem trying to use a custom factory with JNDI. I get an
>>>exception froom org.apache.naming.factory.ResourceFactory. I have added
>>>debug and it appears that my "factory" parameter is not being picked up
>>>from the server.xml.
>>>
>>>Can somebody familiar with the naming code point me to the classes I
>>
> need
>
>>>to look at to trace this problem. Alternatively, if somebody can confirm
>>>that the JNDI-Howto example for a custom beanFactory works correctly in
>>
> 4.1
>
>>>(I have tried it and it doesn't) then I will look at my configuration
>>>again.
>>
>>Doesn't work for me either. Inserting a listBindings() call for
>
> java:comp/env/bean
>
>>reveals nothing bound there.
>
>
> I have traced the problem a little further and I think I know what the
> problem is but I haven't got a clue how to fix it.
>
> Basically, it appears that a different NamingContext is created per
> thread/class loader. Let's assume that you have a tomcat instance called
> "Standalone", a virtual host "localhost" and a context "myapp".
>
> If you define any JNDI resources in the server.xml, then they appear to be
> put into a naming context call "//Standalone/myapp". Your resource
> definitions in the web.xml go into the "//Standalone/localhost/myapp"
> context.
>
> If you attempt to read the resources from your servlet then the
> "//Standalone/localhost/myapp" context is used, this is ok for jdbc, etc
> because the factory is hardwired into the naming code. But if you have
> defined a custom factory then no definition exists in this context for that
> (because it's been put into the "//Standalone/myapp" context). I believe
> this also goes for any parameters that you have defined.
>
> The fix would appear to be for Tomcat to put the resources under the virtual
> in the first place for those defined in the server.xml. There is still an
> issue though for the "global resources" as I am not sure you can link to
> them because they are under a different naming context.
>
> This is an initial investigation so my analysis may be FLAWED.
>
> Remy, does this explanation of how the naming contexts are defined/used make
> sense ?
I'm not sure I understand very well, so I'll assume it's a problem with
the links.
The global resources defined in server.xml are not accessible by default
in the web applications (because you may want to restrict some to
specific webapps, etc). So you have to link them using a ResourceLink
element. You can also define the resource links in the default context
so that all your contexts in your host or engine will have the link,
instead of having to define it in each one.
The admin webapp will have full support for this shortly (I reckon that
configuring this is *hard* at the moment).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
----- Original Message -----
From: "Ian Darwin" <ia...@darwinsys.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>; "Arshad
Mahmood" <ar...@compuvision.co.uk>
Sent: Thursday, June 13, 2002 1:48 AM
Subject: Re: JNDI with a custom factory not working
> On June 12, 2002 07:45 am, Arshad Mahmood wrote:
> > I am having a problem trying to use a custom factory with JNDI. I get an
> > exception froom org.apache.naming.factory.ResourceFactory. I have added
> > debug and it appears that my "factory" parameter is not being picked up
> > from the server.xml.
> >
> > Can somebody familiar with the naming code point me to the classes I
need
> > to look at to trace this problem. Alternatively, if somebody can confirm
> > that the JNDI-Howto example for a custom beanFactory works correctly in
4.1
> > (I have tried it and it doesn't) then I will look at my configuration
> > again.
>
> Doesn't work for me either. Inserting a listBindings() call for
java:comp/env/bean
> reveals nothing bound there.
I have traced the problem a little further and I think I know what the
problem is but I haven't got a clue how to fix it.
Basically, it appears that a different NamingContext is created per
thread/class loader. Let's assume that you have a tomcat instance called
"Standalone", a virtual host "localhost" and a context "myapp".
If you define any JNDI resources in the server.xml, then they appear to be
put into a naming context call "//Standalone/myapp". Your resource
definitions in the web.xml go into the "//Standalone/localhost/myapp"
context.
If you attempt to read the resources from your servlet then the
"//Standalone/localhost/myapp" context is used, this is ok for jdbc, etc
because the factory is hardwired into the naming code. But if you have
defined a custom factory then no definition exists in this context for that
(because it's been put into the "//Standalone/myapp" context). I believe
this also goes for any parameters that you have defined.
The fix would appear to be for Tomcat to put the resources under the virtual
in the first place for those defined in the server.xml. There is still an
issue though for the "global resources" as I am not sure you can link to
them because they are under a different naming context.
This is an initial investigation so my analysis may be FLAWED.
Remy, does this explanation of how the naming contexts are defined/used make
sense ?
Regards.
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI with a custom factory not working
Posted by Ian Darwin <ia...@darwinsys.com>.
On June 12, 2002 07:45 am, Arshad Mahmood wrote:
> I am having a problem trying to use a custom factory with JNDI. I get an
> exception froom org.apache.naming.factory.ResourceFactory. I have added
> debug and it appears that my "factory" parameter is not being picked up
> from the server.xml.
>
> Can somebody familiar with the naming code point me to the classes I need
> to look at to trace this problem. Alternatively, if somebody can confirm
> that the JNDI-Howto example for a custom beanFactory works correctly in 4.1
> (I have tried it and it doesn't) then I will look at my configuration
> again.
Doesn't work for me either. Inserting a listBindings() call for java:comp/env/bean
reveals nothing bound there.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
JNDI with a custom factory not working
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
Hi,
I am having a problem trying to use a custom factory with JNDI. I get an
exception froom org.apache.naming.factory.ResourceFactory. I have added
debug and it appears that my "factory" parameter is not being picked up from
the server.xml.
Can somebody familiar with the naming code point me to the classes I need to
look at to trace this problem. Alternatively, if somebody can confirm that
the JNDI-Howto example for a custom beanFactory works correctly in 4.1 (I
have tried it and it doesn't) then I will look at my configuration again.
Regards,
Arshad
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_endpoint.c
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
The core was the following:
+++
(gdb) where
#0 jk2_endpoint_init (env=0x8108b40, bean=0x8157de0)
at ../../common/jk_endpoint.c:89
#1 0x403b13ab in jk2_workerEnv_addEndpoint (env=0x8108b40, wEnv=0x80f2668,
ep=0x8157e58) at ../../common/jk_workerEnv.c:583
#2 0x403b26de in jk2_worker_ajp13_getEndpoint (env=0x8108b40,
ajp13=0x810f428, eP=0xbffff518) at ../../common/jk_worker_ajp13.c:599
#3 0x403b276c in jk2_worker_ajp13_service (env=0x8108b40, w=0x810f428,
s=0x8155db8) at ../../common/jk_worker_ajp13.c:623
#4 0x403b73b6 in jk2_handler (r=0x814fda0)
at ../../server/apache2/mod_jk2.c:600
+++
The patch did not help because the return codes are not tested... (It cores
somewhere else :-((.
The real problem is why the createSlot fails!
jfclere@apache.org wrote:
> jfclere 2002/06/12 02:56:57
>
> Modified: jk/native2/common jk_endpoint.c
> Log:
> Prevent core when createSlot fails.
>
> Revision Changes Path
> 1.19 +7 -1 jakarta-tomcat-connectors/jk/native2/common/jk_endpoint.c
>
> Index: jk_endpoint.c
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_endpoint.c,v
> retrieving revision 1.18
> retrieving revision 1.19
> diff -u -r1.18 -r1.19
> --- jk_endpoint.c 10 Jun 2002 21:55:06 -0000 1.18
> +++ jk_endpoint.c 12 Jun 2002 09:56:57 -0000 1.19
> @@ -86,8 +86,14 @@
> snprintf( shmName, 128, "epStat.%d", wEnv->childId );
>
> wEnv->epStat=wEnv->shm->createSlot( env, wEnv->shm, shmName, 8096 );
> + if (wEnv->epStat==NULL) {
> + env->l->jkLog(env, env->l, JK_LOG_ERROR,
> + "workerEnv.init() create slot %s failed\n", shmName );
> + return JK_ERR;
> + }
> wEnv->epStat->structCnt=0;
> - env->l->jkLog(env, env->l, JK_LOG_ERROR, "workerEnv.init() create slot %s\n", shmName );
> + env->l->jkLog(env, env->l, JK_LOG_ERROR,
> + "workerEnv.init() create slot %s\n", shmName );
> }
> }
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>