dev@glassfish.java.net

Re: SQE BLocking Bug 14396: How should we run a standalone client on GF 3.1?

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Mon, 08 Nov 2010 11:56:43 -0800

Ken Cavanaugh wrote:
> On Nov 8, 2010, at 11:28 AM, Marina Vatkina wrote:
>
>
>> Ken Saks told me at 3.0 timeframe that GF/habitat bootstrapping and injection should happen during new InitialContext() call.
>>
>> Cheng, can you check?
>>
>
> That's interesting, because the place where this problem occurs is in the constructor for
> SerialInitContectFactory, which is called in a new InitialContext() call (followed by
> getInitialContext). But that's the problem: the very first thing in the SerialIInitContextFactory
> constructor IS the reference to Globals.getDefaultHabitat(), which returns null.
>

What's strange is that it all works in a single-instance install (ejb
devtests do that and Gopal was also able to set up hist test on a single
instance).

So the question is why Globals.getDefaultHabitat() is not working
correctly in a cluster?
> This probably means that the habitat bootstrapping has not yet happened.
>
> The other possibility is a call to SerialInitContextFactory.setDefaultHabitat BEFORE a
> call to new InitialContext (or equivalently for SerialInitContextFactory, a call to
> Globals.setHabitat). I don't see a possibility of this in the standalone client case.
>
> In the appclient, it appears that ACCModulesManager.prepareHabitat is responsible
> for setting up the habitat. Do we need something similar in the standalone client case?
> If so, how do we detect whether we are in the standalone vs. appclient case?
> Is getting a null habitat in the SerialInitContextFactory constructor a sufficient indication
> that something similar to prepareHabitat is needed?
> If so, what ClassLoader should be used (e.g. the thread context ClassLoader)
>
> Thanks,
>
> Ken.
>
>
>> thanks,
>> -marina
>>
>> Ken wrote:
>>
>>> Ken wrote:
>>>
>>>> One of the bugs that Gopal has filed (issue 14396) concerns running IIOP FOLB tests
>>>> from a standalone client. As far as I can tell, that is simply a J2SE client
>>>> that include gf-client.jar in its classpath.
>>>>
>>>> First question: Is anything else required to setup a standalone client?
>>>>
>>>> The test that we have been trying basically does something like (this is from the issue comments):
>>>>
>>>> /export/jdk1.6.0_21/bin/java -Dcom.sun.appserv.iiop.endpoints=hat2k2:23700,hat2k2:23701,hat2k2:23702,hat2k2:23703 -Drmiregistry.host=hat2k2 -classpath /disk3/agentrepo/glassfish-samples/callback-service.jar
>>>> :/disk3/agentrepo/glassfish-samples/cart-ejb.jar
>>>> :/disk3/sfish-samples/cart-app-client.jar
>>>> :/disk3/glassfish3/glassfish/modules/gf-client.jar cart.client.CartFailoverClient
>>>>
>>>> This fails with a stack trace in naming, which comes down to the fact that
>>>> org.glassfish.internal.api.Globals.defaultHabitat is set to null, apparently
>>>> because dependency injection did not happen. The code that is failing is simply calling
>>>>
>>>> habitat = Globals.getDefaultHabitat()
>>>>
>>>> in the SerialInitContextFactory constructor.
>>>>
>>>> So what else is needed to make this work?
>>>>
>>>> Thanks,
>>>>
>>>> Ken.
>>>>
>>> This is a blocking bug for SQE, and I have no idea how to fix it.
>>>
>>> I need information about the relation between a standalone client (that just includes gf-client.jar in its classpath),
>>> and hk2 dependency injection. Does dependency injection work at all in this configuration?
>>>
>>> Without assistance, this will never get fixed.
>>>
>>> Thanks,
>>>
>>> Ken.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>