In order for the runtime to have better integration for a tooling/
development environment we need the runtime to be able to run modules
and their resources directly from a users development environment.
Currently, if a single source file changes the entire EAR must be
exported and redeployed. This is not a long term solution and in
past experiences this can lead to severe performance issues hindering
a users development experience.
My proposal is that we introduce a schema that defines an external
j2ee configuration, that for a given application its external
configuration file would define:
(1) configID
(2) all its j2ee modules
(3) for each module an absolute path location to its metadata and
binaries (n number of classes folder)
During deployment, the location of this configuration file could be
passed and processed via jmx. All configurations on a given server
instance could have a set of properties associated and serialized
with it, one of them being a location to this "external config" file.
As far as how the runtime would handle this, keeping the knowledge of
this config file as low is the stack as possible I would like some
thoughts on.
If we have a solution to this, we could have a 1st class developer
experience, any change to any resource would take affect almost
instantaneously, without having to go through any repackaging or
deployment steps.
What do people think? Is this something that we could discuss?
- sachin
