Attendees: Tim Quinn, Dies, Siraj, Byron, Hong, Jerome, Anissa, Vijay, Bill, Nazrul, Jennifer

• Deployment discussion (Hong) on synchronize (same as v2) or regenerate generated artifacts on remote instance -
  • Some of the things talked in the meeting
    • Generated EJB artifacts
    • Generated JSP artifacts
      • Peformance impact for regeneration of JSP compilation
    • Generated security policy artifacts
    • Generated JAX-RPC web service artifacts
    • Nazrul - synchronization working well in v2, cleaner - if deploy fails on remote instance have to debug instance individually instead of in 1 place.
    • Byron - remote instance would now be doing administration where before in v2 it did not.
    • Jerome propose use of hidden deploy command
    • motivation to regenerate on remote instance - simpler, easier to maintain code base.
    • When to add application-ref - after app loaded?
  • The conclusion is that we agreed to use the approach of generating all the artifacts on the DAS, collecting them together with the original archive, and sending them to the instance using a special internal "_deploy" command, which would save the app and the generated data, load the app, and update the domain.xml. So, no regeneration on the instances.
  • Jerome and Hong will discuss further and write this up
• schema2beans not used in v3, there's thread-locking when updating config in domain.xml
• v3 will continue to support shared cluster-config, same as in v2 unless there's a major bug that's hard to fix
• Discussion to add default-config.xml to domain.xml by default
  • default-config loaded in habitat and parsed - not much overhead
  • User may get confused what is default-config
  • Instead of adding to domain.xml, can have mock DefaultConfig element that's used
  • Not supporting create-domain --profile option in v3
  • Not much difference between developer and cluster profile

Action Items

• Jerome/Hong provide what happens on DAS vs remote instance