Takashi Nishigaya wrote:
> 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.
That's a good question and it gets to the heart of the portability
guarantees made by
Java EE. Java EE ensures that the same application code will run correctly
on different Java EE implementations. It does *not* ensure that the
command used to
start either the Application Server or the Application Client container
will be the same.
It's a lot like Java SE. The commands to start the JVM and the specific
options/arguments
that are accepted differ between JVM implementations but your Java SE
.classes should
run the same on each.
For Java EE, the key is that you be able to package up a portable
archive and use that as an input
to deployment. As long as the application code in that archive uses
the correct programming
model for accessing dependencies :
a. no-arg new InitialContext() + lookup relative to java:comp/env
b. EJBContext.lookup() (only applies to code running within ejbs)
c. environment annotations such as @EJB, @Resource
you should be able to run it using the vendor-provided commands and
configuration
guidelines.
I agree it would be nice if even more aspects of the process were
standardized across vendors, but the reality is that it's hard enough to
just provide
application portability so some of the other candidates for
standardization are
prioritized much lower during the specification process.
--ken
> 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
>>>
>>
>>
>>
>