Hi Tim,
It's nice to see you guys working on improving app client deployment for v3. If I had to choose between the two options you've outlined, I'd prefer the second; multiple files instead of one large file. My motivation for selecting that option is in part because I hope it would make it easier for me to discard the resources I don't need.
To be honest though, I could care less if the application client container added 30 seconds to application startup if I can monitor the process and provide feedback to the user while it happens. With the v2 client container it was a pain to even do simple things like adding a splash screen.
I hope this isn't too off-topic:
I don't use the v2 client container. Instead I (try to) figure out which jars I need, pull them out of the lib directory and package them using a more traditional installer. The process does involve some compromises and I lose some ease of programming features like resource injection and simpler configuration. However, I justify the reduced portability and increased configuration complexity because I feel the result is a better deployment experience.
When it comes down to it, I want more control over the startup process. I hate turning over control to the client container and having it doing a bunch of setup before my application launches. It may not be something that's going to change for v3, but I think it makes it too difficult to do any kind of runtime configuration that is dependent on user input.
I'll use setting properties like an initial ORB host or port number as an example of what I mean. When I deploy I want to have two options for my users:
1. Run my application via web start (assuming v3 is better than v2).
2. Install the application using a traditional installer (ideally the client container + my application).
If I want to do multiple deployments (one for each organization) the web-start option works fine (in terms of configuration). However, if I want to use the client container for this scenario it becomes too much of a hassle. Am I supposed to build a new client container (that has the proper configuration automatically created) for every deployment? A new installer that adds the proper command line args to the application launch?
Personally I'd rather have a comprehensive set of documentation related to deployment instead of having the client container force me down a single path. For example, how to determine which resources you need, how to load those resources properly, how to initialize (via an API) the client container environment, etc.
The ability to start the client container via an API call with as little as a single callback (when it's finished starting) would resolve nearly every complaint I have about the v2 client container. I don't care how big it is. I don't care how long it takes to load. I just want to control it.
I can understand the desire to have the client container as a deployment solution that 'just works', but I think having it do everything automatically can, at times, be just as frustrating as having to reference the documentation and do some customization.
To give you some perspective on my viewpoint I'm currently working on a productivity application and would like to target a market that you'd probably consider small to mid-size business. We selected JavaEE as a platform because we felt it will give use the most flexibility in terms of selling our product as either a managed, subscription based service or a traditional client / server software package.
My intent isn't to criticize. I simply wanted to point out some of the characteristics of the client container that aren't optimal 'for me' and I do realize those same characteristics could be ideal for someone in a different situation than me.
[Message sent by forum member 'ryan6608' (ryan6608)]
http://forums.java.net/jive/thread.jspa?messageID=333306