Christof Ameye wrote:
>Anyway,
>
>If you have a strongly distributed architecture with several application
>servers you already have to use the properties mechanism to be able to
>distinguish the different application servers.
>
Hi Christof,
That is not true. A valid Application Client container implementation
must allow
the client naming provider to be configured without relying on
application code.
Otherwise, there is no portability. Our appclient command allows these
to be
set via an optional Application Client .xml file. In our case, they
default to
localhost/3700.
All of the Java EE compatibility tests that
have client functionality are developed as Java EE Application Clients.
These
components use either Java EE 5 annotations or no-arg new
InitialContext() +
lookup() relative to java:comp/env to retrieve their resources. Each
vendor runs these same Application Client components with their application
server. They don't have the option of recompiling the client code to pass
different properties to InitialContext.
Anytime you see a java client that uses something other than the no-arg
InitialContext() to access Java EE resources/ejbs it is by definition
non-portable.
That's one of the differences between what we refer to as a stand-alone java
client and a Java EE Application Client component.
--ken
> The same applies if you
>connect to one application server from within another one.
>I don't think Java EE 5 solves that problem. Or maybe we could solve
>this by playing with the class loader (but does that simplify things,
>rather not).
>
>Christof
>
>
>Takashi Nishigaya wrote:
>
>
>>Thanks, Ian.
>>
>>Yes, Java Web Start may be a good choice for portability.
>>I will evaluate it.
>>
>>Thanks,
>>Takashi Nishigaya
>>
>>Ian Evans wrote:
>>
>>
>>>Takashi Nishigaya <Takashi.Nishigaya_at_Sun.COM> wrote:
>>>
>>>
>>>
>>>>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
>>>>
>>>>
>>>Glassfish/App Server 9 uses Java Web Start to simplify packaging and
>>>running Java EE App Clients. It's the best solution for running
>>>remote app clients.
>>>
>>>http://blogs.sun.com/roller/page/quinn?entry=how_does_glassfish_know_about
>>>
>>>http://docs.sun.com/app/docs/doc/819-3659/6n5s6m5aa?a=view
>>>
>>>I don't think we've done enough to promote app client use generally
>>>or to publicize our Java Web Start-able app client feature.
>>>
>>>-ian
>>>
>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ejb-unsubscribe_at_glassfish.dev.java.net
>For additional commands, e-mail: ejb-help_at_glassfish.dev.java.net
>
>
>