Hi Ken,
Ok very nice, but what about Java EE applications that connect to
several other application servers from within the same single application,
or even on complexity more: the server they connect to must be run-time
configurable in the application itself ?
Christof
Kenneth Saks wrote:
> 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
>>
>>
>
>