Actually I didn't even know that portability is a design target for the ACC and frankly I do not care about this type of portability at all (my clients only need to be able to talk to the GlassFish instance they belong to and nothing else; I do not see any note in the Java EE spec that any portability here is mandatory and I do not see the benefit of supporting this -- but I see drawbacks). What I want is that the install and config step has to be separated from the startup procedure to speed up things as much as possible. I thought that this is what this thread is about?
> -----Original Message-----
> From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
> Sent: Samstag, 28. Februar 2009 13:14
> To: users_at_glassfish.dev.java.net
> Subject: Re: If you deploy app clients we need your feedback on some
> choices in v3!
>
> I hope it's ok if I add a little more input on this topic. I think the
> issue Markus was talking about was more than likely the way the build-
> appclient script and configuration (asenv / sun-acc.xml) of the
> resulting environment is set up in v2.
>
> It's not exactly what I'd consider portable.
>
> Don't hesitate to correct me if I'm wrong, because it's been well over
> a year since I've used the ACC and I'm mostly going by memory.
>
> If I remember correctly the configuration of the v2 ACC is what really
> turned me away from it. Running the build-appclient script wasn't too
> big of a deal, but the way the appclient had to be configured was a
> hassle. Some of the big points for me were:
>
> 1. Absolute paths in the asenv config file.
> 2. Different launch scripts and configs for different platforms (win32
> vs linux).
> 3. Having to change configuration in the sun-acc.xml file.
>
> When I first started using the v2 ACC I had to do too much tweaking to
> get what I felt like was a 'portable enough' ACC that I could wrap in a
> traditional installer.
>
> From what I've read, the first two points I mentioned won't be an issue
> anymore. The sun-acc.xml is probably a necessary evil since it looks
> like it mostly contains configuration information about the server that
> isn't guaranteed to be the same on every server.
>
> I'm guessing things will be very close to a 'java -jar appclient.jar'
> exectution, but there will always be a need for a minimal amount of
> configuration information that's going to be required by the ACC (the
> target client main class, initial orb host & ports, etc).
>
> If the ACC is being used as an entry point (ACC gets started, inits,
> hands off to real app), would it be possible to split and layer the
> configuration? By that, I mean split the configuration requirements
> into two categories (verbose names as examples)...
>
> acc-non-portable-host-config.xml
> acc-non-portable-runtime-config.xml
>
> Config info like initial orb ports & hosts, logging, etc could go in
> the runtime-config. Other more involved settings where it's likely the
> defaults will suffice for most people could go in the host-config.
> Chances are most app developers aren't going to start thinking about
> some of the (host-config style) settings that we saw in the v2 sun-
> acc.xml file until they're getting closer to an actual deployment. At
> that point it would probably be better to let the person responsible
> for configuring the production environment supply that config info.
>
> By layering the configuration I mean (keep) using configuration
> priorities similar to the way a lot of EE components are configured;
> command line args > hand config > default config.
>
> It would also be nice if the app server were capable of spitting out
> intelligent defaults for either of those configs (ie: --get-acc-non-
> portable-configs). As a general rule, I don't care about that kind of
> stuff unless something breaks. I want to point my app client to a
> runtime-config (host, port, etc) and have it 'just work'.
>
> In terms of what I consider 'portablility' I'd like to be able to build
> an ACC on one machine (ie: my wn32 dev machine) and use it to run app
> clients that connect to any app servers (ie: a linux test server
> accessible to others) that have my .ear deployed. Ideally I wouldn't
> have to build it and could just download a .jar. To me, having to
> build the ACC is an indication that it's adding some server specific
> information and is likely only going to (be guaranteed to) work with
> the server on which it was built.
>
> I started to ask some questions about the embedded version of the
> appclient since that's what I'm really interested in, but my post is
> already a bit long winded. Is there any more detailed information
> regarding how the embedded appclient will work that anyone knows of?
> [Message sent by forum member 'ryan6608' (ryan6608)]
>
> http://forums.java.net/jive/thread.jspa?messageID=334398
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net