You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2007/01/03 16:09:30 UTC
Java kernel release
Over the past couple of weeks we have made progress in upgrading the
capabilities of the kernel, including starting support for a
standalone server, JMX, and SCA deployment. In addition, we have made
changes that have allowed us to support existing SCA features such as
multiple bindings for services and references as well as implement
recent spec changes such as the introduction of autowire in the
assembly model. Related to this, Jeremy has begun work to further
modularize our source tree with the goal of allowing us to release
the kernel and extensions independently.
Given this, I would like to get another release of the kernel going
shortly. Some of the features I am personally interested in seeing are:
- A standalone service with JMX support for management
- A functioning deployment implementation that corresponds to the
current SCA deployment proposal for contributing and mutating assemblies
- Closer alignment with the Java C&I specification (scopes,
conversations, autowire attributes, eager initialization semantics,
support for resources)
- Closer alignment with the assembly specification (multiple bindings
per service/reference, property overrides)
- Improved extension support, including classloader isolation (i.e.
use of multiparent classloading)
Another key goal I would like to see is a focus on hardening the
kernel. We still have a number of critical code paths which are
fragile and have little to no test coverage.
I would ideally like to get a kernel release out by the end of the
month that extension developers can use which is fairly stable and
robust. Depending on the outcome of changes under consideration by
the SCA collaboration, this would put us in a fairly good position to
support a significant number of features by the time the
specifications are released in their "1.0" form.
Thoughts?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Deployment, was: Java kernel release
Posted by Francesco Furfari <fr...@isti.cnr.it>.
thank you all for the details :-)
I need more time to absorb them, but here some comments following up to
the thread about the Standalone server.
> 1. How the management mechanism is implemented
> 2. How the management interface is extracted from managed components
I would like to discuss about the third level
1. (Agent level) How the management mechanism is implemented
2. (Probe level) How the management interface is extracted from managed
components
3. (console) How client applications effectively manage components
thinking to hundreds of components to be controlled I'm not sure that
standard consoles can manage all them easily.
for example, can the containment hierarchy of the composite pattern be
reproduced using
> ${userDomain} : type = SCAComponent, composite = "${compositeURI}" , name = ${componentName}
I suspect that a standard console (i.e. JConsole) would show a flat
structure, and custom client applications should be developed in order
to integrate *dynamic* systems !! not so exciting.
From this point of view the approach used in Felix mosgi console is
quite interesting in my opinion. For every instrumented component the
developer could point another "controller" component (Plugin) for
rendering purpose (console side). The pattern could be extended also to
composite or modules in order to improve the management of a complex system.
for instance:
@ManagedResource(description="a sample management interface",
controller="componentURI")
In such a way you could also maintain compatibility with the MOSGi
implementation, in fact the URI could point to a non-SCA component (i.e
pure bundle) as well.
> I think one key question is would these annotations be specific to tuscany, or would they be pushed into the core SCA spec some time.
I don't know whether pushing annotations to the SCA spec would be
limited to extend the componentType only, but I'm wondering if it makes
sense to declare instrumented component even in the scdl schema.
Would be nice to have a top level view of the system understanding which
part of the system are manageable. Actually instrumented component
define implicit service entries.
well I've still a lot of questions, but I will post them next.
regards
francesco
Jeremy Boynes wrote:
> I started work on a version of this with the definition of two
> interfaces in host-api:
>
> ContributionService is an API that handles the contribution of artifacts
> to a SCA domain (for now, the domain corresponds to a single runtime, in
> the future it will be multiple federated ones). The main method is:
> contribute(URI source, InputStream contribution, String contentType)
>
> which allows the content of any resource to be added to the domain. The
> contentType is used to direct the stream to a processor that is
> responsible for handling the stream's content and adding the definitions
> it provides to the domain. For example, if the Content-Type was
> "application/zip" it would be dispatched to a processor handling zip
> archives (which might be able to handle other zip-style archives such as
> jars). Once a contribution has been processed, the definitions it
> provided can be referenced from the Assembly.
>
> The other interface, AssemblyService, handles changes to the logical
> Assembly for the domain (which is the instance of the Assembly model
> that describes the services provided by the domain and how they are
> wired together). The Assembly starts off empty (when the domain boots)
> and is built up with a series of changes made through this API. Typical
> changes would be things like creating a component, removing a component,
> adding a wire between two components and so forth.
>
> The Assembly only references logical definitions such as the
> "com.acme.Foo" class name from Jim's example. The runtime is responsible
> for mapping that reference into a physical implementation. So, if that
> class was contributed in a OSGi bundle, then the runtime would want to
> instantiate it in an OSGi-compliant manner (for example, by loading it
> into an OSGi framework).
>
> I'm still actively working on this and there is a lot still to do.
> --
> Jeremy
>
> On Jan 3, 2007, at 9:08 AM, Jim Marino wrote:
>
>>
>> On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote:
>>
>>> Hi Jim,
>>>
>>> as you know my vision about Tuscany architecture is still limited,
>>> but I was wondering whether one of the JMX implementation at the
>>> Felix project could help you. Take a look at
>>> http://cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html
>>>
>>> This solution is tied to adopt an OSGi container. I thought that
>>> assemblies could be deployed as bundles, and the SCA system
>>> controlled using an OSGi-based JMX console.
>>>
>> Hi Francesco,
>>
>> Meeraj has been leading the JMX integration so I'll let him talk about
>> what his plans are for it...
>>
>> In terms of deploying assemblies as bundles, yes, we want to be able
>> to support that but we also have plans to do more. The SCA
>> collaboration is currently working on deployment (it is one of the big
>> missing pieces prior to releasing the specs as "1.0" versions). It is
>> still very much a work in progress but the idea behind SCA deployment
>> is that we want to support a variety of "packaging" formats as well as
>> the ability to contribute resources (e.g. Java classes, XSDs, WSDL
>> port types, etc.) that an assembly may reference. They key thing we
>> want to do is decouple how resources are referenced in an assembly and
>> how they are physically contributed to the SCA "domain". Another key
>> thing is we want the end-user experience to be very simple.
>>
>> Some specific examples may help to explain this further. Say I have
>> the following component definition:
>>
>> <component name="FooService">
>> <implemenation.java class="com.acme.Foo">
>> </component>
>>
>> How the com.acme.Foo service is contributed to the SCA runtime should
>> not be evident from the assembly SCDL, as shown above. It could have
>> been contributed through any of the following means:
>>
>> 1. The class file was placed in a directory
>> 2. A jar containing the class file was contributed to a "deployment"
>> service
>> 3. An OSGi bundle containing the class file was contributed to a
>> "deployment" service
>>
>> ..etc..
>>
>> Similarly, the same mechanism could be used for WSDLs, XSDs, etc.
>>
>> More specifically, two steps take place in this process. The first is
>> the resource is contributed to the SCA domain. The second step is the
>> assembly is mutated, for example, a component is instantiated using
>> the SCDL above. This allows for reuse. Sometimes these steps may be
>> combined from an end-user perspective. For example, I should be able
>> to drop a Java class in a directory and have the runtime introspect
>> and deploy it as a component. The runtime should also be smart enough
>> to be able to figure out how to provision components to various nodes
>> in the service network. For example, if I have a component that
>> requires high availability, it may deploy to a J2EE host environment
>> running Tuscany. Or, it may provision it to an OSGi container running
>> Tuscany. Ditto for the Standalone server.
>>
>> By the time we are done defining the deployment API, I suspect we will
>> have something similar to Subversion.
>>
>> If you are interested in getting involved in helping implement some of
>> this or other parts of Tuscany, let us know and I am sure people will
>> be able to give you pointers to help get you started. Also, we're
>> always interested in hearing about your requirements, particularly
>> since it sounds as if you have several projects that may be able to
>> make use of these capabilities.
>>
>> Jim
>>
>>
>>> Is this approach feasible for you or you prefer to add JMX support
>>> directly to the kernel?
>>>
>>> francesco
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Deployment, was: Java kernel release
Posted by Jeremy Boynes <jb...@apache.org>.
I started work on a version of this with the definition of two
interfaces in host-api:
ContributionService is an API that handles the contribution of
artifacts to a SCA domain (for now, the domain corresponds to a
single runtime, in the future it will be multiple federated ones).
The main method is:
contribute(URI source, InputStream contribution, String contentType)
which allows the content of any resource to be added to the domain.
The contentType is used to direct the stream to a processor that is
responsible for handling the stream's content and adding the
definitions it provides to the domain. For example, if the Content-
Type was "application/zip" it would be dispatched to a processor
handling zip archives (which might be able to handle other zip-style
archives such as jars). Once a contribution has been processed, the
definitions it provided can be referenced from the Assembly.
The other interface, AssemblyService, handles changes to the logical
Assembly for the domain (which is the instance of the Assembly model
that describes the services provided by the domain and how they are
wired together). The Assembly starts off empty (when the domain
boots) and is built up with a series of changes made through this
API. Typical changes would be things like creating a component,
removing a component, adding a wire between two components and so forth.
The Assembly only references logical definitions such as the
"com.acme.Foo" class name from Jim's example. The runtime is
responsible for mapping that reference into a physical
implementation. So, if that class was contributed in a OSGi bundle,
then the runtime would want to instantiate it in an OSGi-compliant
manner (for example, by loading it into an OSGi framework).
I'm still actively working on this and there is a lot still to do.
--
Jeremy
On Jan 3, 2007, at 9:08 AM, Jim Marino wrote:
>
> On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote:
>
>> Hi Jim,
>>
>> as you know my vision about Tuscany architecture is still limited,
>> but I was wondering whether one of the JMX implementation at the
>> Felix project could help you. Take a look at http://
>> cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html
>>
>> This solution is tied to adopt an OSGi container. I thought that
>> assemblies could be deployed as bundles, and the SCA system
>> controlled using an OSGi-based JMX console.
>>
> Hi Francesco,
>
> Meeraj has been leading the JMX integration so I'll let him talk
> about what his plans are for it...
>
> In terms of deploying assemblies as bundles, yes, we want to be
> able to support that but we also have plans to do more. The SCA
> collaboration is currently working on deployment (it is one of the
> big missing pieces prior to releasing the specs as "1.0" versions).
> It is still very much a work in progress but the idea behind SCA
> deployment is that we want to support a variety of "packaging"
> formats as well as the ability to contribute resources (e.g. Java
> classes, XSDs, WSDL port types, etc.) that an assembly may
> reference. They key thing we want to do is decouple how resources
> are referenced in an assembly and how they are physically
> contributed to the SCA "domain". Another key thing is we want the
> end-user experience to be very simple.
>
> Some specific examples may help to explain this further. Say I have
> the following component definition:
>
> <component name="FooService">
> <implemenation.java class="com.acme.Foo">
> </component>
>
> How the com.acme.Foo service is contributed to the SCA runtime
> should not be evident from the assembly SCDL, as shown above. It
> could have been contributed through any of the following means:
>
> 1. The class file was placed in a directory
> 2. A jar containing the class file was contributed to a
> "deployment" service
> 3. An OSGi bundle containing the class file was contributed to a
> "deployment" service
>
> ..etc..
>
> Similarly, the same mechanism could be used for WSDLs, XSDs, etc.
>
> More specifically, two steps take place in this process. The first
> is the resource is contributed to the SCA domain. The second step
> is the assembly is mutated, for example, a component is
> instantiated using the SCDL above. This allows for reuse. Sometimes
> these steps may be combined from an end-user perspective. For
> example, I should be able to drop a Java class in a directory and
> have the runtime introspect and deploy it as a component. The
> runtime should also be smart enough to be able to figure out how to
> provision components to various nodes in the service network. For
> example, if I have a component that requires high availability, it
> may deploy to a J2EE host environment running Tuscany. Or, it may
> provision it to an OSGi container running Tuscany. Ditto for the
> Standalone server.
>
> By the time we are done defining the deployment API, I suspect we
> will have something similar to Subversion.
>
> If you are interested in getting involved in helping implement some
> of this or other parts of Tuscany, let us know and I am sure people
> will be able to give you pointers to help get you started. Also,
> we're always interested in hearing about your requirements,
> particularly since it sounds as if you have several projects that
> may be able to make use of these capabilities.
>
> Jim
>
>
>> Is this approach feasible for you or you prefer to add JMX support
>> directly to the kernel?
>>
>> francesco
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Requiremets -- was:Java kernel release
Posted by Francesco Furfari <fr...@isti.cnr.it>.
> If you are interested in getting involved in helping implement some of
> this or other parts of Tuscany, let us know and I am sure people will be
> able to give you pointers to help get you started. Also, we're always
> interested in hearing about your requirements, particularly since it
> sounds as if you have several projects that may be able to make use of
> these capabilities.
not several projects :-) just one, I'm currently involved in CASPAR
project (http://www.casparpreserves.eu/) about the preservation of
digital artefacts over time. Basically the objective is to implement,
validate and extend the OAIS reference model
(http://public.ccsds.org/publications/archive/650x0b1.pdf), so the main
research interest is about metadata management of digital information
objects, not s/w engineering per se.
You can get a top level view of the model at page 4-1, while the last
page (F-1) give you a composite view of the functional entities.
Obviously I cannot state anything on behalf of the Project management,
I'm reporting just my opinion. An effective software development should
implies many of the aspects addressed by the SCA spec, I'm referring to
the security, policy, transaction, conversational services and so on.
At the moment I haven't specific requirements, I can tell you my
expectations.
The work will be developed among different partners developing specific
components/subsystems and sharing them in a common source repository. I
guess we should be able to build and deploy the whole system in a single
host machine (one/multiple processes) for debugging purpose, but also
set up a production network, as well as a network for testing the
various releases.
Thus, for example, I appreciate in SCA the @AllowsPassbyReference in the
data exchange semantic, because useful when deploying on a single
process and, I think, to tune the system by grouping parts of it for
performance reasons. I expect to administer nodes of the "test" network
in which to deploy new versions, but also nodes in which are running
components that I cannot install on my development node (e.g. different
platform)
that's all so far.
regards
francesco
Jim Marino wrote:
>
> On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote:
>
>> Hi Jim,
>>
>> as you know my vision about Tuscany architecture is still limited, but
>> I was wondering whether one of the JMX implementation at the Felix
>> project could help you. Take a look at
>> http://cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html
>>
>> This solution is tied to adopt an OSGi container. I thought that
>> assemblies could be deployed as bundles, and the SCA system controlled
>> using an OSGi-based JMX console.
>>
> Hi Francesco,
>
> Meeraj has been leading the JMX integration so I'll let him talk about
> what his plans are for it...
>
> In terms of deploying assemblies as bundles, yes, we want to be able to
> support that but we also have plans to do more. The SCA collaboration is
> currently working on deployment (it is one of the big missing pieces
> prior to releasing the specs as "1.0" versions). It is still very much a
> work in progress but the idea behind SCA deployment is that we want to
> support a variety of "packaging" formats as well as the ability to
> contribute resources (e.g. Java classes, XSDs, WSDL port types, etc.)
> that an assembly may reference. They key thing we want to do is decouple
> how resources are referenced in an assembly and how they are physically
> contributed to the SCA "domain". Another key thing is we want the
> end-user experience to be very simple.
>
> Some specific examples may help to explain this further. Say I have the
> following component definition:
>
> <component name="FooService">
> <implemenation.java class="com.acme.Foo">
> </component>
>
> How the com.acme.Foo service is contributed to the SCA runtime should
> not be evident from the assembly SCDL, as shown above. It could have
> been contributed through any of the following means:
>
> 1. The class file was placed in a directory
> 2. A jar containing the class file was contributed to a "deployment"
> service
> 3. An OSGi bundle containing the class file was contributed to a
> "deployment" service
>
> ..etc..
>
> Similarly, the same mechanism could be used for WSDLs, XSDs, etc.
>
> More specifically, two steps take place in this process. The first is
> the resource is contributed to the SCA domain. The second step is the
> assembly is mutated, for example, a component is instantiated using the
> SCDL above. This allows for reuse. Sometimes these steps may be combined
> from an end-user perspective. For example, I should be able to drop a
> Java class in a directory and have the runtime introspect and deploy it
> as a component. The runtime should also be smart enough to be able to
> figure out how to provision components to various nodes in the service
> network. For example, if I have a component that requires high
> availability, it may deploy to a J2EE host environment running Tuscany.
> Or, it may provision it to an OSGi container running Tuscany. Ditto for
> the Standalone server.
>
> By the time we are done defining the deployment API, I suspect we will
> have something similar to Subversion.
>
> If you are interested in getting involved in helping implement some of
> this or other parts of Tuscany, let us know and I am sure people will be
> able to give you pointers to help get you started. Also, we're always
> interested in hearing about your requirements, particularly since it
> sounds as if you have several projects that may be able to make use of
> these capabilities.
>
> Jim
>
>
>> Is this approach feasible for you or you prefer to add JMX support
>> directly to the kernel?
>>
>> francesco
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java kernel release
Posted by Jim Marino <jm...@myromatours.com>.
On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote:
> Hi Jim,
>
> as you know my vision about Tuscany architecture is still limited,
> but I was wondering whether one of the JMX implementation at the
> Felix project could help you. Take a look at http://
> cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html
>
> This solution is tied to adopt an OSGi container. I thought that
> assemblies could be deployed as bundles, and the SCA system
> controlled using an OSGi-based JMX console.
>
Hi Francesco,
Meeraj has been leading the JMX integration so I'll let him talk
about what his plans are for it...
In terms of deploying assemblies as bundles, yes, we want to be able
to support that but we also have plans to do more. The SCA
collaboration is currently working on deployment (it is one of the
big missing pieces prior to releasing the specs as "1.0" versions).
It is still very much a work in progress but the idea behind SCA
deployment is that we want to support a variety of "packaging"
formats as well as the ability to contribute resources (e.g. Java
classes, XSDs, WSDL port types, etc.) that an assembly may reference.
They key thing we want to do is decouple how resources are referenced
in an assembly and how they are physically contributed to the SCA
"domain". Another key thing is we want the end-user experience to be
very simple.
Some specific examples may help to explain this further. Say I have
the following component definition:
<component name="FooService">
<implemenation.java class="com.acme.Foo">
</component>
How the com.acme.Foo service is contributed to the SCA runtime should
not be evident from the assembly SCDL, as shown above. It could have
been contributed through any of the following means:
1. The class file was placed in a directory
2. A jar containing the class file was contributed to a "deployment"
service
3. An OSGi bundle containing the class file was contributed to a
"deployment" service
..etc..
Similarly, the same mechanism could be used for WSDLs, XSDs, etc.
More specifically, two steps take place in this process. The first is
the resource is contributed to the SCA domain. The second step is the
assembly is mutated, for example, a component is instantiated using
the SCDL above. This allows for reuse. Sometimes these steps may be
combined from an end-user perspective. For example, I should be able
to drop a Java class in a directory and have the runtime introspect
and deploy it as a component. The runtime should also be smart enough
to be able to figure out how to provision components to various nodes
in the service network. For example, if I have a component that
requires high availability, it may deploy to a J2EE host environment
running Tuscany. Or, it may provision it to an OSGi container running
Tuscany. Ditto for the Standalone server.
By the time we are done defining the deployment API, I suspect we
will have something similar to Subversion.
If you are interested in getting involved in helping implement some
of this or other parts of Tuscany, let us know and I am sure people
will be able to give you pointers to help get you started. Also,
we're always interested in hearing about your requirements,
particularly since it sounds as if you have several projects that may
be able to make use of these capabilities.
Jim
> Is this approach feasible for you or you prefer to add JMX support
> directly to the kernel?
>
> francesco
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java kernel release
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Hi Jim,
as you know my vision about Tuscany architecture is still limited, but I
was wondering whether one of the JMX implementation at the Felix project
could help you. Take a look at
http://cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html
This solution is tied to adopt an OSGi container. I thought that
assemblies could be deployed as bundles, and the SCA system controlled
using an OSGi-based JMX console.
Is this approach feasible for you or you prefer to add JMX support
directly to the kernel?
francesco
Jim Marino wrote:
> Over the past couple of weeks we have made progress in upgrading the
> capabilities of the kernel, including starting support for a standalone
> server, JMX, and SCA deployment. In addition, we have made changes that
> have allowed us to support existing SCA features such as multiple
> bindings for services and references as well as implement recent spec
> changes such as the introduction of autowire in the assembly model.
> Related to this, Jeremy has begun work to further modularize our source
> tree with the goal of allowing us to release the kernel and extensions
> independently.
>
> Given this, I would like to get another release of the kernel going
> shortly. Some of the features I am personally interested in seeing are:
>
> - A standalone service with JMX support for management
> - A functioning deployment implementation that corresponds to the
> current SCA deployment proposal for contributing and mutating assemblies
> - Closer alignment with the Java C&I specification (scopes,
> conversations, autowire attributes, eager initialization semantics,
> support for resources)
> - Closer alignment with the assembly specification (multiple bindings
> per service/reference, property overrides)
> - Improved extension support, including classloader isolation (i.e. use
> of multiparent classloading)
>
> Another key goal I would like to see is a focus on hardening the kernel.
> We still have a number of critical code paths which are fragile and have
> little to no test coverage.
>
> I would ideally like to get a kernel release out by the end of the month
> that extension developers can use which is fairly stable and robust.
> Depending on the outcome of changes under consideration by the SCA
> collaboration, this would put us in a fairly good position to support a
> significant number of features by the time the specifications are
> released in their "1.0" form.
>
> Thoughts?
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java kernel release
Posted by Jim Marino <jm...@myromatours.com>.
>> Given this, I would like to get another release of the kernel
>> going shortly. Some of the features I am personally interested in
>> seeing are:
>>
>> - A standalone service with JMX support for management
>> - A functioning deployment implementation that corresponds to the
>> current SCA deployment proposal for contributing and mutating
>> assemblies
>> - Closer alignment with the Java C&I specification (scopes,
>> conversations, autowire attributes, eager initialization
>> semantics, support for resources)
>
> There are some JIRA issues created from the test cases in "testing
> \sca\itest\test-spec". We should try to fix them.
>
+1
>> - Closer alignment with the assembly specification (multiple
>> bindings per service/reference, property overrides)
>
>> - Improved extension support, including classloader isolation
>> (i.e. use of multiparent classloading)
>
> Is there anyone working on this? If not, I can try to help.
>
Jeremy was doing part of this work for deployment but as he mentioned
there is a lot to get done so I would sync with him. Geronimo as a
multiparent classloader that we could probably borrow from.
One other thing that occurred to me is it would be good to get
support for policy as well.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java kernel release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
>
> There are some JIRA issues created from the test cases in
> "testing\sca\itest\test-spec". We should try to fix them.
>
>> - Closer alignment with the assembly specification (multiple
>> bindings per service/reference, property overrides)
>
I'd like to help with the release as well. If nobody else is already
working on this, I'll start with the JIRAs reporting differences with
the latest spec (APIs, annotations, and SCDL).
It looks like TUSCANY-909 is already fixed but I'll do a pass through
the latest C&I spec to verify it. I'll also look into TUSCANY-910.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java kernel release
Posted by Simon Nash <na...@hursley.ibm.com>.
I'd like to help with the classloader work as well. It's time I got into
some real Java programming :-)
Simon
Raymond Feng wrote:
> Hi,
>
> Please see my comments below.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jim Marino" <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, January 03, 2007 7:09 AM
> Subject: Java kernel release
>
>
>> Over the past couple of weeks we have made progress in upgrading the
>> capabilities of the kernel, including starting support for a
>> standalone server, JMX, and SCA deployment. In addition, we have made
>> changes that have allowed us to support existing SCA features such as
>> multiple bindings for services and references as well as implement
>> recent spec changes such as the introduction of autowire in the
>> assembly model. Related to this, Jeremy has begun work to further
>> modularize our source tree with the goal of allowing us to release
>> the kernel and extensions independently.
>>
>
> Great job! You guys made a lot of improvements during the holidays.
>
>> Given this, I would like to get another release of the kernel going
>> shortly. Some of the features I am personally interested in seeing are:
>>
>> - A standalone service with JMX support for management
>> - A functioning deployment implementation that corresponds to the
>> current SCA deployment proposal for contributing and mutating assemblies
>> - Closer alignment with the Java C&I specification (scopes,
>> conversations, autowire attributes, eager initialization semantics,
>> support for resources)
>
>
> There are some JIRA issues created from the test cases in
> "testing\sca\itest\test-spec". We should try to fix them.
>
>> - Closer alignment with the assembly specification (multiple bindings
>> per service/reference, property overrides)
>
>
>> - Improved extension support, including classloader isolation (i.e.
>> use of multiparent classloading)
>
>
> Is there anyone working on this? If not, I can try to help.
>
>>
>> Another key goal I would like to see is a focus on hardening the
>> kernel. We still have a number of critical code paths which are
>> fragile and have little to no test coverage.
>>
>> I would ideally like to get a kernel release out by the end of the
>> month that extension developers can use which is fairly stable and
>> robust. Depending on the outcome of changes under consideration by
>> the SCA collaboration, this would put us in a fairly good position to
>> support a significant number of features by the time the
>> specifications are released in their "1.0" form.
>>
>
> +1
>
>> Thoughts?
>>
>> Jim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Eclipse code style template
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Raymond,
I will get the sourcecheck profile working and post the violations.
Ta
Meeraj
>From: "Meeraj Kunnumpurath" <m....@hotmail.co.uk>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: Eclipse code style template
>Date: Fri, 05 Jan 2007 07:47:43 +0000
>
>Thanks Raymond.
>
>The sourcecheck profile is failing in the build unable to resolve maven
>checkstyle plugin from the current repos.
>
>Ta
>Meeraj
>
>
>
>>From: "Raymond Feng" <en...@gmail.com>
>>Reply-To: tuscany-dev@ws.apache.org
>>To: <tu...@ws.apache.org>
>>Subject: Re: Eclipse code style template
>>Date: Thu, 4 Jan 2007 17:19:34 -0800
>>
>>Hi,
>>
>>I checked in an updated version on Dec. 1, 2006. As we know, the template
>>is not fully conforming to the checkstyle and we agree to fix it case by
>>case.
>>
>>Meeraj, can you run the audit by running "mvn -Psourcecheck" and post the
>>violations to help us understand what's breaking?
>>
>>Thanks,
>>Raymond
>>
>>----- Original Message ----- From: "Jeremy Boynes" <jb...@apache.org>
>>To: <tu...@ws.apache.org>
>>Sent: Thursday, January 04, 2007 4:21 PM
>>Subject: Re: Eclipse code style template
>>
>>
>>>On Jan 4, 2007, at 3:34 PM, Meeraj Kunnumpurath wrote:
>>>
>>>>Hi,
>>>>
>>>>Is the eclipse code style template in etc up-to-date? I have configured
>>>>my workspace to use it. However, Jim mentioned some of the changes I
>>>>recently made in kernel screwed up the formatting.
>>>
>>>I don't think so. IIRC Raymond was working on updating it.
>>>--
>>>Jeremy
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>_________________________________________________________________
>MSN Hotmail is evolving check out the new Windows Live Mail
>http://ideas.live.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Eclipse code style template
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Thanks Raymond.
The sourcecheck profile is failing in the build unable to resolve maven
checkstyle plugin from the current repos.
Ta
Meeraj
>From: "Raymond Feng" <en...@gmail.com>
>Reply-To: tuscany-dev@ws.apache.org
>To: <tu...@ws.apache.org>
>Subject: Re: Eclipse code style template
>Date: Thu, 4 Jan 2007 17:19:34 -0800
>
>Hi,
>
>I checked in an updated version on Dec. 1, 2006. As we know, the template
>is not fully conforming to the checkstyle and we agree to fix it case by
>case.
>
>Meeraj, can you run the audit by running "mvn -Psourcecheck" and post the
>violations to help us understand what's breaking?
>
>Thanks,
>Raymond
>
>----- Original Message ----- From: "Jeremy Boynes" <jb...@apache.org>
>To: <tu...@ws.apache.org>
>Sent: Thursday, January 04, 2007 4:21 PM
>Subject: Re: Eclipse code style template
>
>
>>On Jan 4, 2007, at 3:34 PM, Meeraj Kunnumpurath wrote:
>>
>>>Hi,
>>>
>>>Is the eclipse code style template in etc up-to-date? I have configured
>>>my workspace to use it. However, Jim mentioned some of the changes I
>>>recently made in kernel screwed up the formatting.
>>
>>I don't think so. IIRC Raymond was working on updating it.
>>--
>>Jeremy
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Eclipse code style template
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I checked in an updated version on Dec. 1, 2006. As we know, the template is
not fully conforming to the checkstyle and we agree to fix it case by case.
Meeraj, can you run the audit by running "mvn -Psourcecheck" and post the
violations to help us understand what's breaking?
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, January 04, 2007 4:21 PM
Subject: Re: Eclipse code style template
> On Jan 4, 2007, at 3:34 PM, Meeraj Kunnumpurath wrote:
>
>> Hi,
>>
>> Is the eclipse code style template in etc up-to-date? I have configured
>> my workspace to use it. However, Jim mentioned some of the changes I
>> recently made in kernel screwed up the formatting.
>
> I don't think so. IIRC Raymond was working on updating it.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Eclipse code style template
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 4, 2007, at 3:34 PM, Meeraj Kunnumpurath wrote:
> Hi,
>
> Is the eclipse code style template in etc up-to-date? I have
> configured my workspace to use it. However, Jim mentioned some of
> the changes I recently made in kernel screwed up the formatting.
I don't think so. IIRC Raymond was working on updating it.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Eclipse code style template
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Hi,
Is the eclipse code style template in etc up-to-date? I have configured my
workspace to use it. However, Jim mentioned some of the changes I recently
made in kernel screwed up the formatting.
Ta
Meeraj
_________________________________________________________________
Find Singles In Your Area This Christmas With Match.com! msnuk.match.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Update on management service
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Hi,
This is a quick summary for the changes to enable management service within
composite components so that component registration can be relayed through
to the management service,
1. The runtime creates a management service and registers with the system
composite
2. The type of management service will be defined in etc/runtime.properties
3. Runtime passes the management service in to the default bootstrapper to
be used by the primodial builder registry
4. BuilderRegistry will have a depenedency on management service
5. This will be autowired for the one that comes from the scdl and set
manually for the one created in bootstrapper
6. CompositeComponent will have a setManagementService
7. After the builder builds the component and if it is a composite component
the builder registry will set the management service.
8. From there onwards the composite component will use the management
service for exposing its child components for management.
We will also have to pass contextual information to the management service
when it is created by the runtime. For eg, the JMX management service would
need a reference to the mbean server used by the host. I have a JMX runtime
info that is wired into the JMX management service to pass the mbean server.
However for this to work with a generic creation mechanism for management
service, we need to have runtime info as part of the management service
abstraction. Something like this in the runtime,
Properties runtimeProps = new Porperties();
InputStream in =
bootClassLoader.getResourceAsStream("/etc/runtime.properties");
runtimeProps.load(in);
String managementServiceClass =
runtimeProps.getProperty("management.service.class");
ManagementService managementService = (ManagementService)
Class.forName(managementServiceClass ).newInstance();
managementService .setRuntimeInfo(runtimeInfo);
and the JmxManagementService's setRuntimeInfo would look like
JmxRunrimeInfo jmxRuntimeInfo = (JmxRuntimeInfo) runtimeInfo;
this.mbeanServer = jmxRuntimeInfo.getMbeanServer();
We could even paremeterize ManagementService with RuntimeInfo to avoid the
donwcast.
Ta
Meeraj
_________________________________________________________________
Find Singles In Your Area This Christmas With Match.com! msnuk.match.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java kernel release
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please see my comments below.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, January 03, 2007 7:09 AM
Subject: Java kernel release
> Over the past couple of weeks we have made progress in upgrading the
> capabilities of the kernel, including starting support for a standalone
> server, JMX, and SCA deployment. In addition, we have made changes that
> have allowed us to support existing SCA features such as multiple
> bindings for services and references as well as implement recent spec
> changes such as the introduction of autowire in the assembly model.
> Related to this, Jeremy has begun work to further modularize our source
> tree with the goal of allowing us to release the kernel and extensions
> independently.
>
Great job! You guys made a lot of improvements during the holidays.
> Given this, I would like to get another release of the kernel going
> shortly. Some of the features I am personally interested in seeing are:
>
> - A standalone service with JMX support for management
> - A functioning deployment implementation that corresponds to the current
> SCA deployment proposal for contributing and mutating assemblies
> - Closer alignment with the Java C&I specification (scopes,
> conversations, autowire attributes, eager initialization semantics,
> support for resources)
There are some JIRA issues created from the test cases in
"testing\sca\itest\test-spec". We should try to fix them.
> - Closer alignment with the assembly specification (multiple bindings per
> service/reference, property overrides)
> - Improved extension support, including classloader isolation (i.e. use
> of multiparent classloading)
Is there anyone working on this? If not, I can try to help.
>
> Another key goal I would like to see is a focus on hardening the kernel.
> We still have a number of critical code paths which are fragile and have
> little to no test coverage.
>
> I would ideally like to get a kernel release out by the end of the month
> that extension developers can use which is fairly stable and robust.
> Depending on the outcome of changes under consideration by the SCA
> collaboration, this would put us in a fairly good position to support a
> significant number of features by the time the specifications are
> released in their "1.0" form.
>
+1
> Thoughts?
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org