Hi ken,
Thank you for your valuable sugestions.
Yes, @EJB is really good feature in Java EE 5.
Maybe it is time to use the client container.
But for portability issue, different vendor provides the different
command usage for client container. It raises another issue about
packaging of the portable ejb client application, i.e.,
which is protable? properties + classpath vs. wrapping command line
Anyway, thank you so much,
Takashi Nishigaya
Kenneth Saks wrote:
> 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
>>
>
>
>