You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Balan Subramanian (JIRA)" <ji...@apache.org> on 2007/08/27 16:49:31 UTC
[jira] Reopened: (MUSE-243) Dynamic discovery and aggregation of
resource types
[ https://issues.apache.org/jira/browse/MUSE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Balan Subramanian reopened MUSE-243:
------------------------------------
The OSGi fix provided by Joel only satisfies:
"As an additional enhancement, it is desired that in addition to support archive files, Muse supports this feature for OSGi bundles by registering with the OSGi container's bundle registry. This enhancement is applicable only when the runtime environment for Muse is OSGi."
We still need to provide the base feature which allows muse.xml fragments to be provided separately in separate JAR files.
> Dynamic discovery and aggregation of resource types
> ---------------------------------------------------
>
> Key: MUSE-243
> URL: https://issues.apache.org/jira/browse/MUSE-243
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Resource and Capability APIs
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
>
> In some cases all resource type definitions are not available at the time the Muse runtime starts. So even though multiple resource types can be hosted by a single Muse instance, all the resource type definitions must be available before Muse starts and listed in muse.xml. It is desired that Muse be made dynamic so that it can monitor a particular folder where an archive (JAR for example) is dropped. This archive will contain the necessary classes, descriptors, router entries etc. and a muse.xml fragment which will be used by Muse to instantiate the specified instances of that resource type. As an additional enhancement, it is desired that in addition to support archive files, Muse supports this feature for OSGi bundles by registering with the OSGi container's bundle registry. This enhancement is applicable only when the runtime environment for Muse is OSGi.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Reopened: (MUSE-243) Dynamic discovery and aggregation of
resource types
Posted by Balan Subramanian <bs...@us.ibm.com>.
Vinh,
Thanks for the detailed description. I realize the complexity in doing
this at runtime, so I think I will revise this to do this only at startup
time. The main issue we are trying to deal with is that for some products
that provide their own endpoints and also allow other endpoints to be
hosted on them, we need a clear separation between the built in and
contributed endpoints without duplicating the muse container .i.e. the
requirement is to have only one instance of the Muse container.
I think if we remove the "dynamic" or "runtime reconfiguration" nature of
it, this requirement should be easy to accomplish. In fact, we have
started working on a design that I will be happy to post here in a week or
so.
Thanks,
Balan
Balan Subramanian
Autonomic Computing, IBM, RTP, NC
919.543.0197 | bsubram@us.ibm.com
"Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
08/27/2007 01:35 PM
Please respond to
muse-dev@ws.apache.org
To
<mu...@ws.apache.org>
cc
Subject
RE: [jira] Reopened: (MUSE-243) Dynamic discovery and aggregation of
resource types
I think this is similar to a question I had awhile back about having
multiple teams working on a single Muse app. Each team would have their
own muse.xml, but in the end, was there a way that Muse can
automatically startup the app from multiple muse.xml files?
Looks like this is similar to Balan's request to allow muse.xml to be
fragmented. The answer at the time was that this wasn't currently
supported. Thinking about it now, it might also be difficult,
especially if you want each muse.xml fragment to be located in a
separate jar. This requires playing with the classloaders and making
sure Muse is smart enough to locate all the muse.xml fragments at
startup, load them in the correct order, and error handling to avoid
resource clashes.
In addition, to make it more complicated as Balan is proposing, the jars
could be dropped in the app at anytime after startup. So not only does
Muse need to locate the fragments at startup, it must also pick them up
at runtime. The problem I see with this part is: if the Muse app is
packaged in a War/EAR, how do you drop in jars at runtime after the app
already started? Upon restart of the server, wouldn't you lose those
jars because they aren't actually in the original War/EAR?
Balan's proposal is good because it makes use of the "discovery"
mechanism. Currently, the only way a new resource can be added at
runtime is to explicitly invoke Muse to add the resource (i.e. via
ResourceManager). So the proposal would allow Muse to automatically
pickup the new resources at runtime, but I can see this won't be that
easy to achieve.
-----Original Message-----
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Monday, August 27, 2007 7:50 AM
To: muse-dev@ws.apache.org
Subject: [jira] Reopened: (MUSE-243) Dynamic discovery and aggregation
of resource types
[
https://issues.apache.org/jira/browse/MUSE-243?page=com.atlassian.jira.p
lugin.system.issuetabpanels:all-tabpanel ]
Balan Subramanian reopened MUSE-243:
------------------------------------
The OSGi fix provided by Joel only satisfies:
"As an additional enhancement, it is desired that in addition to support
archive files, Muse supports this feature for OSGi bundles by
registering with the OSGi container's bundle registry. This enhancement
is applicable only when the runtime environment for Muse is OSGi."
We still need to provide the base feature which allows muse.xml
fragments to be provided separately in separate JAR files.
> Dynamic discovery and aggregation of resource types
> ---------------------------------------------------
>
> Key: MUSE-243
> URL: https://issues.apache.org/jira/browse/MUSE-243
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Resource and Capability APIs
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
>
> In some cases all resource type definitions are not available at the
time the Muse runtime starts. So even though multiple resource types can
be hosted by a single Muse instance, all the resource type definitions
must be available before Muse starts and listed in muse.xml. It is
desired that Muse be made dynamic so that it can monitor a particular
folder where an archive (JAR for example) is dropped. This archive will
contain the necessary classes, descriptors, router entries etc. and a
muse.xml fragment which will be used by Muse to instantiate the
specified instances of that resource type. As an additional enhancement,
it is desired that in addition to support archive files, Muse supports
this feature for OSGi bundles by registering with the OSGi container's
bundle registry. This enhancement is applicable only when the runtime
environment for Muse is OSGi.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Reopened: (MUSE-243) Dynamic discovery and aggregation of resource types
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
I think this is similar to a question I had awhile back about having
multiple teams working on a single Muse app. Each team would have their
own muse.xml, but in the end, was there a way that Muse can
automatically startup the app from multiple muse.xml files?
Looks like this is similar to Balan's request to allow muse.xml to be
fragmented. The answer at the time was that this wasn't currently
supported. Thinking about it now, it might also be difficult,
especially if you want each muse.xml fragment to be located in a
separate jar. This requires playing with the classloaders and making
sure Muse is smart enough to locate all the muse.xml fragments at
startup, load them in the correct order, and error handling to avoid
resource clashes.
In addition, to make it more complicated as Balan is proposing, the jars
could be dropped in the app at anytime after startup. So not only does
Muse need to locate the fragments at startup, it must also pick them up
at runtime. The problem I see with this part is: if the Muse app is
packaged in a War/EAR, how do you drop in jars at runtime after the app
already started? Upon restart of the server, wouldn't you lose those
jars because they aren't actually in the original War/EAR?
Balan's proposal is good because it makes use of the "discovery"
mechanism. Currently, the only way a new resource can be added at
runtime is to explicitly invoke Muse to add the resource (i.e. via
ResourceManager). So the proposal would allow Muse to automatically
pickup the new resources at runtime, but I can see this won't be that
easy to achieve.
-----Original Message-----
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Monday, August 27, 2007 7:50 AM
To: muse-dev@ws.apache.org
Subject: [jira] Reopened: (MUSE-243) Dynamic discovery and aggregation
of resource types
[
https://issues.apache.org/jira/browse/MUSE-243?page=com.atlassian.jira.p
lugin.system.issuetabpanels:all-tabpanel ]
Balan Subramanian reopened MUSE-243:
------------------------------------
The OSGi fix provided by Joel only satisfies:
"As an additional enhancement, it is desired that in addition to support
archive files, Muse supports this feature for OSGi bundles by
registering with the OSGi container's bundle registry. This enhancement
is applicable only when the runtime environment for Muse is OSGi."
We still need to provide the base feature which allows muse.xml
fragments to be provided separately in separate JAR files.
> Dynamic discovery and aggregation of resource types
> ---------------------------------------------------
>
> Key: MUSE-243
> URL: https://issues.apache.org/jira/browse/MUSE-243
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Resource and Capability APIs
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
>
> In some cases all resource type definitions are not available at the
time the Muse runtime starts. So even though multiple resource types can
be hosted by a single Muse instance, all the resource type definitions
must be available before Muse starts and listed in muse.xml. It is
desired that Muse be made dynamic so that it can monitor a particular
folder where an archive (JAR for example) is dropped. This archive will
contain the necessary classes, descriptors, router entries etc. and a
muse.xml fragment which will be used by Muse to instantiate the
specified instances of that resource type. As an additional enhancement,
it is desired that in addition to support archive files, Muse supports
this feature for OSGi bundles by registering with the OSGi container's
bundle registry. This enhancement is applicable only when the runtime
environment for Muse is OSGi.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org