Bugs item #665037, was opened at 2003-01-09 06:32
Message generated for change (Comment added) made by starksm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665037&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Scott M Stark (starksm)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4
Initial Comment:
When running our remote clients we get a
NoInitialContextException. The exception is caused by
a call to HomeHandle.getEJBHome(). After Looking
through the source code for JBOSS, it seems that
JBOSS 3.0.4's
com.jboss.proxy.ejb.handle.HomeHandleImpl does not
serialize the JNDI context information like is should (and
used to in JBOSS2.4. Instead it always creates a new
InitialContext in the getEJBHome method. The following
example illustrates the problem.
import
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;
public class Example {
public static void main(String[] args) throws Exception
{
Properties _prop = new Properties();
_prop.setProperty
("java.naming.factory.initial","org.jnp.interfaces.NamingC
ontextFactory");
_prop.setProperty
("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.
interfaces");
_prop.setProperty
("java.naming.provider.url","localhost");
_prop.setProperty
("java.naming.provider.port","1099");
InitialContext _ic = new InitialContext(_prop);
POFObjectManagerRemoteHome _om_home =
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
("qlink/POFObjectManager"),POFObjectManagerRemote
Home.class);
HomeHandle _hhandle = _om_home.getHomeHandle
();
//Here is where the NoInitialContextException is
thrown
_om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
}
}
Thanks,
Shone Sadler
Senior Software Developer
Q-Link Technologies
OS: Win2000
JDK:1.3.1_06
Server Trace:
C:\development>java Example
Exception in thread "main" java.rmi.ServerException:
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to
specify class name in e
vironment or system property, or as an applet
parameter, or in an application r
source file: java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify
class name in environme
t or system property, or as an applet parameter, or in an
application resource
ile: java.naming.factory.initial
at
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)
----------------------------------------------------------------------
>Comment By: Scott M Stark (starksm)
Date: 2003-07-16 07:30
Message:
Logged In: YES
user_id=175228
This was addressed with the addition of the
org.jboss.naming.NamingContextFactory which showed up in
3.0.7. This factory makes the jndi properties available for
use by ejb home handles.
----------------------------------------------------------------------
Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 10:34
Message:
Logged In: YES
user_id=558871
Well, I am aware of this, hence no patch from me as of yet.
Also, as you may have noticed, I stretched the issue over to
StatelessHandleImpl. Having it store some preference of
which HARMIServer to hit upon reconnecting should not
make it any less robust. And I don't see why it should be any
different for HomeHandles.
The hindrance is the need to mess with
JRMPInvokerProxyHA et al. and this shouldn't be any of their
concern.
Just wanted to point an issue and hoped you would come up
with a neat solution as usual.
I reckon sticking with the exact same bean as long as
possible would would help a lot of people. It not being
possible, I'll live with it.
Oskari Kettunen,
Krocus Communications,
FINLAND
(a long)
P.S.
I am also very aware that my view is partly result of
stretching the spec:
We have a load of (seppuku) CMR/CMR entities accessed
via (clustered) SSB facades. We do not want the overhead of
clustering stateful facades, but we do like the performance
gain of hitting the same entity container within the same
session with some probability. Add to this an external fully
round robin http-load balancer and you get a glimpse of my
problem field.
One (bad) approach would have been shoving the handle in to
the HttpSession and let that distribute, assuming it was able
distinguish between targets.
Another (efficient, but not elegant) is dumping the session ID
into a ThreadLocal upon receiving a request, and have a
custom load balance policy divide the hash code modulus
target list length. Can't be any worse than RoundRobin, and
in normal circumstances gives a nice gain in performance.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2003-01-15 09:27
Message:
Logged In: YES
user_id=175228
Well, how robust would it be to fix to the node in the cluster
that previously handled the create only to find that node no
longer exists?
----------------------------------------------------------------------
Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 08:06
Message:
Logged In: YES
user_id=558871
Forgot to mention:
I was actually getting "XYZ not bound" from
StatelessHandleImpl, because the new InitialContext().lookup
(jndiName) caught onto the client side JNDI, not the one
discovered with specific properties. Same problem, obviously.
Oskari Kettunen,
Krocus Communications,
Finland
----------------------------------------------------------------------
Comment By: Oskari Kettunen (aok)
Date: 2003-01-15 07:58
Message:
Logged In: YES
user_id=558871
I've run into this also, and would like to add a sidenote:
When using HA-JNDI discoverServer broadcast, the jndi
properties are not sufficient information for accurately
determining the location of the EJB. Having just any server
with a similar bean respond when invoking
Handle.getEJBObject(), as transparent as it may be, doesn't
seem like "'robust' persistent reference to an EJB object" as
the J2EE javadoc suggests.
I intended to submit this bug along with a patch as soon as I
got time for fixing it, but as work is already underway, this is
purely additional FYI.
Oskari Kettunen,
Krocus Communications,
Finland
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2003-01-12 13:42
Message:
Logged In: YES
user_id=175228
Yes, that is a silly regression in 3.x. You have to restore the
handle in a context with a jndi.properties file that matches
that in which the handle was looked up. It will be addressed
in the 3.0.6 and 3.2 releases.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665037&group_id=22866
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
