Takashi Nishigaya wrote:
> Hi ken,
>
>
>
> This is confusing and causes non-potable configuration files between
> glassfish and others.
Hi Takashi,
Yes, the real issue here is that *any* use of stand-alone java clients
is not portable.
If you're unhappy with the differences between configuring stand-alone
Java clients
for different vendors then that's one more reason to use the portable
alternative, a
Java EE Application Client component. We do our best to support
stand-alone Java
clients but they are not recommended. Furthermore, when it comes to our
configuration requirements for stand-alone Java clients, we set it up
such that in
as many cases as possible, the no-arg InitialContext() constructor will
work, in order
to simplify the job of the developer.
Java EE has a portable component called an Application Client which
avoids all these issues.
When accessing dependencies wtihin a Java EE component, the no-arg
InitialContext() and
java:comp/env are guaranteed to work. That puts the burden of bootstrapping
the naming context on the container, where it should be. It also allows
the developer
to take advantage of the newer improvements in the platform such as Java
EE 5
annotations, e.g. @EJB. We have a writeup covering these issues in our
EJB FAQ.
--ken
>
>
> Glassfish should also support the configuration approach 2), isn't it?
>
> Takashi Nishigaya
>
> Kenneth Saks wrote:
>
>> Takashi Nishigaya wrote:
>>
>>> Hi Ken,
>>>
>>> Let me clarify the point of my problem.
>>>
>>> My test client is using no-arg InitialContext constructor.
>>> -----
>>> public class Client {
>>> public static void main(String args[]) throws Exception {
>>> InitialContext ctx = new InitialContext();
>>> Object home = ctx.lookup("ejb/mgmt/MEJB");
>>> }
>>> }
>>> -----
>>>
>>> We have two options to configure the client *remotely located*
>>> outside of container.
>>>
>>> 1) specifying properties 'org.omg.CORBA.ORBInitialHost' and
>>> 'org.omg.CORBA.ORBInitialPort',
>>> for example,
>>>
>>> $ java -classpath 'javaee.jar;appserv-rt.jar;.'
>>> -Dorg.omg.CORBA.ORBInitialHost=192.168.0.1 \
>>> -Dorg.omg.CORBA.ORBInitialPort=3700 \
>>> Client
>>>
>>> -> OK.
>>>
>>> , or
>>>
>>> 2) specifying property 'java.naming.provider.url',
>>> for example,
>>>
>>> $ java -classpath 'javaee.jar;appserv-rt.jar;.' \
>>> -Djava.naming.provider.url=iiop://192.168.0.1:3700 \
>>
>>
>>
>> I haven't tried using this particular property with our naming provider.
>> This property is typically used when instantiating the CosNaming
>> provider. I'd recommend using approach 1). Regarding the stack trace,
>> this is probably caused by the fact that your stand-alone
>> client is accessing MEJB, which is a secured ejb. Many of the
>> standard services provided by the portable Java EE Application
>> Client container are not available or require special work from a
>> stand-alone client, which is why we recommend using
>> Application Clients. You can find more information on accessing
>> the MEJB from a stand-alone client at :
>>
>> http://java.sun.com/developer/EJTechTips/2006/tt0225.html#2
>>
>> --ken
>>
>>>
>>> Client
>>>
>>> -> NG (please see the stack trace in the previous email)
>>>
>>> The semantics of both case is the same. So, the latter case should
>>> work as the first case, shouldn't it?
>>> Wired thing is that gf runtime is trying to connect to localhost,
>>> ignoring the property setting java.naming.provider.url.
>>>
>>> Is this the correct behavior?
>>>
>>> Thank you,
>>> Takashi Nishigaya
>>>
>>> Kenneth Saks wrote:
>>>
>>>> Takashi Nishigaya wrote:
>>>>
>>>>> Hi,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi Takashi,
>>>>
>>>> If you just have a simple stand-alone java client there's no reason
>>>> to explicitly set the naming provider properties the way we're
>>>> suggesting for the Resin case in the other part of this email
>>>> thread. You should be able to use the no-arg InitialContext
>>>> constructor by following the steps outlined in our ejb faq :
>>>>
>>>> https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB
>>>>
>>>>
>>>> Please try that first and let us know if you still see any errors.
>>>> Also, if you get an error message saying connection failure, such as :
>>>>
>>>> "(COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT;
>>>> hostname: localhost; port: 3700"
>>>>
>>>> it means the host/port combination is invalid. This could mean
>>>> either that the appserver is not running or that the orb port
>>>> number is incorrect. --ken
>>>>
>>>>>
>>>>> I have a similar problem in the case of standalone client without
>>>>> client container.
>>>>>
>>>>> When I run the remote client with the folloing jndi properties:
>>>>> -----
>>>>> $ java -classpath 'javaee.jar;appserv-rt.jar;.' \
>>>>>
>>>>> -Djava.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
>>>>> \
>>>>> -Djava.naming.provider.url=iiop://192.168.0.1:3700 \
>>>>> -Djava.naming.factory.url.pkgs=com.sun.enterprise.naming \
>>>>>
>>>>> -Djava.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
>>>>> \
>>>>> Client
>>>>> -----
>>>>> (where 192.168.0.1 is remote host)
>>>>>
>>>>> I got the exception like this:
>>>>> -----
>>>>> WARN: "IOP00410201: (COMM_FAILURE) Connection failure: socketType:
>>>>> IIOP_CLEAR_TEXT; hostname: localhost; port: 3700"
>>>>> org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
>>>>> at
>>>>> com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2348)
>>>>>
>>>>> at
>>>>> com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2369)
>>>>>
>>>>> at
>>>>> com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:212)
>>>>>
>>>>> at
>>>>> com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:225)
>>>>>
>>>>> at
>>>>> com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:104)
>>>>>
>>>>> at
>>>>> com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:159)
>>>>>
>>>>> at
>>>>> com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:156)
>>>>>
>>>>> at
>>>>> com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:296)
>>>>>
>>>>> at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
>>>>> at
>>>>> org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
>>>>>
>>>>> at
>>>>> com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:110)
>>>>>
>>>>> at
>>>>> com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:164)
>>>>>
>>>>> at
>>>>> com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:309)
>>>>>
>>>>> at javax.naming.InitialContext.lookup(InitialContext.java:351)
>>>>> at Client.main(Client2.java:11)
>>>>> Caused by: java.lang.RuntimeException: java.net.ConnectException:
>>>>> Connection refused: connect
>>>>> at
>>>>> com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:356)
>>>>>
>>>>> at
>>>>> com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:195)
>>>>>
>>>>> ... 12 more
>>>>> -----
>>>>>
>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ejb-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: ejb-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ejb-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: ejb-help_at_glassfish.dev.java.net
>