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