But yes, if we can key of something else to identify the type of
repo, that would be good. The primary issue is the the eclipse-aware
config store can not resolve artifacts that are in a J2EE structure.
It will only be able to understand the eclipse project layout, so
deploying an application in a J2EE compliant structure to this repo
will fail.
- sachin
On Apr 28, 2006, at 2:39 PM, Sachin Patel wrote:
The eclipse-aware config store is a subclass of the repository
config-store, so yes, there would be more then one. (Currently due
to it being a subclass the metadata would be written to the
instance repo, but I'm thinking about moving this internally to
generate inside the eclipse workspace metadata. So either way if
the CLI deployed to both writeable config stores, I'm thinking
there would be issues with that, so "no" to the second question.
- sachin
On Apr 28, 2006, at 1:51 PM, Aaron Mulder wrote:
Is there going to be more than one writeable config store per
server? Can the default be to deploy to all writeable config stores?
Aaron
On 4/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Apr 28, 2006, at 9:48 AM, Sachin Patel wrote:
> Aaron,
>
> If no targets are specified by default the current help specifies
> that the the configuration will be deployed to all targets. Will
> this cause conflicts? i.e config store A may not be able to
> correctly resolve a configuration that can only be understood by
> config store B, as will be the case with the eclipse scenario. In
> the case that the app can be successfully deployed to both, how
> does this impact the application at runtime? If I hit an app in
the
> browser which config store is it running off off?
>
> Does there need to be a notion of a default config store and if no
> targets are specified the default is used? I'm concerned with the
> eclipse-aware configuration store causing issues with a given
> server instance being used for "normal" deployment.
+1
-dain
