Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » Access container config properties
Access container config properties [message #597172] Mon, 30 January 2006 15:00 Go to next message
Jim Wright is currently offline Jim WrightFriend
Messages: 16
Registered: July 2009
Junior Member
I am using ECF for the Eclipse Corona project and have the following
question.

I have a server and client component.

I created a shared object on server and replicated it to the client. The
shared object has properties.

I created the client container(TCPClientSOContainer) with configuration
properties and created the server container(TCPServerSOContainer) with
properties.

When the shared object is created in the client, I can get the shared object
properties via a call to the shared object method getConfig().

What I need access to from the shared object is the container's properties.
From the client shared object I want to access the client container's
properties. From the server shared object I want to access the server
container's properties.

Is there a way to do this?

Thanks
Jim Wright
Compuware Corp.
Re: Access container config properties [message #597181 is a reply to message #597172] Mon, 30 January 2006 16:38 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Jim,

Jim Wright wrote:
> I am using ECF for the Eclipse Corona project and have the following
> question.
>
> I have a server and client component.
>
> I created a shared object on server and replicated it to the client. The
> shared object has properties.
>
> I created the client container(TCPClientSOContainer) with configuration
> properties and created the server container(TCPServerSOContainer) with
> properties.
>
> When the shared object is created in the client, I can get the shared object
> properties via a call to the shared object method getConfig().
>
> What I need access to from the shared object is the container's properties.


> From the client shared object I want to access the client container's
> properties. From the server shared object I want to access the server
> container's properties.
>
> Is there a way to do this?

Yes, but it's not currently in the sharedobjectcontainer api.

You could make a trivial subclass of the TCPClientSOContainer and
TCPServerSOContainer that overrides 'createSharedObjectContext' method
in SOContainer (which is called whenever an shared object is
constructed) and fill out the properties passed to the newly created
shared object context with whichever of the local container's properties
you prefer. This context (and the filled out properties) will be passed
to the shared object when its init method is called and so the shared
object will have those properties available when its code calls
getConfig().getProperties().

Now...do think there is reasonable cause here to expose a method on the
shared object context to access the local container's properties? This
could be easily exposed via a
ISharedObjectContext.getLocalContainerProperties() method or some such.
Could you describe the use case for this a little further? I hadn't
anticipated that shared objects would typically access their container's
properties (unless the container explicitly exposes them through
mechanism such as above), but this could be a good idea.

Thanks,


Scott
Re: Access container config properties [message #597191 is a reply to message #597181] Mon, 30 January 2006 17:26 Go to previous messageGo to next message
Jim Wright is currently offline Jim WrightFriend
Messages: 16
Registered: July 2009
Junior Member
Scott

In my case I need the BundleContext of the Bundle that the container/shared
object is running under. I need to create a ServiceTracker so I can
interface with an OSGI service.

The first parameter of the ServiceTracker is the BundleContext.

By placing this information in the Container's properties, I can use the
same code whether the shared object is in the client or the server.

I like the idea of adding ISharedObjectContext.getLocalContainerProperties()
method. It is clean and clearly separates the shared object properties from
the container's properties.

Thanks,

JimW

By placing that information in the Container's properties, then I can use
the same code under the client and the server.
"Scott Lewis" <slewis@composent.com> wrote in message
news:43DE4106.7050007@composent.com...
> Hi Jim,
>
> Jim Wright wrote:
> > I am using ECF for the Eclipse Corona project and have the following
> > question.
> >
> > I have a server and client component.
> >
> > I created a shared object on server and replicated it to the client.
The
> > shared object has properties.
> >
> > I created the client container(TCPClientSOContainer) with configuration
> > properties and created the server container(TCPServerSOContainer) with
> > properties.
> >
> > When the shared object is created in the client, I can get the shared
object
> > properties via a call to the shared object method getConfig().
> >
> > What I need access to from the shared object is the container's
properties.
>
>
> > From the client shared object I want to access the client container's
> > properties. From the server shared object I want to access the server
> > container's properties.
> >
> > Is there a way to do this?
>
> Yes, but it's not currently in the sharedobjectcontainer api.
>
> You could make a trivial subclass of the TCPClientSOContainer and
> TCPServerSOContainer that overrides 'createSharedObjectContext' method
> in SOContainer (which is called whenever an shared object is
> constructed) and fill out the properties passed to the newly created
> shared object context with whichever of the local container's properties
> you prefer. This context (and the filled out properties) will be passed
> to the shared object when its init method is called and so the shared
> object will have those properties available when its code calls
> getConfig().getProperties().
>
> Now...do think there is reasonable cause here to expose a method on the
> shared object context to access the local container's properties? This
> could be easily exposed via a
> ISharedObjectContext.getLocalContainerProperties() method or some such.
> Could you describe the use case for this a little further? I hadn't
> anticipated that shared objects would typically access their container's
> properties (unless the container explicitly exposes them through
> mechanism such as above), but this could be a good idea.
>
> Thanks,
>
>
> Scott
>
>
Re: Access container config properties [message #597204 is a reply to message #597191] Mon, 30 January 2006 18:00 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Jim,

Jim Wright wrote:
> Scott
>
> In my case I need the BundleContext of the Bundle that the container/shared
> object is running under. I need to create a ServiceTracker so I can
> interface with an OSGI service.
>
> The first parameter of the ServiceTracker is the BundleContext.
>
> By placing this information in the Container's properties, I can use the
> same code whether the shared object is in the client or the server.

Ah...interesting. Some time ago I had actually anticipated exposing
org.eclipse.ecf.core.IOSGIService directly (which just exposes the
BundleContext service access methods). This so that shared object code
could...with container 'approval'...access local OSGI services...without
having to do what you are doing (passing round BundleContext refs).

So I think that I should move the API to completion there (it's just not
finished yet)...in addition to adding the getLocalContainerProperties()
method to ISharedObjectContext as discussed below. Any comments about that?

Do you think this is reasonable? Just for curiosity's sake...what
BundleContext methods are you going after?

>
> I like the idea of adding ISharedObjectContext.getLocalContainerProperties()
> method. It is clean and clearly separates the shared object properties from
> the container's properties.

Yes, I will add this method and implementation. After a few minutes
thought I think it would be a reasonable addition. It won't be deployed
until 0.6.2, however, which will probably be next week.

BTW Jim...I haven't yet been able to follow up with Corona plan changes,
support from ECF, etc. Would you like to have a conference call to
discuss...perhaps sometime later this week or next?

Thanks,

Scott


>
> Thanks,
>
> JimW
>
> By placing that information in the Container's properties, then I can use
> the same code under the client and the server.
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:43DE4106.7050007@composent.com...
>
>>Hi Jim,
>>
>>Jim Wright wrote:
>>
>>>I am using ECF for the Eclipse Corona project and have the following
>>>question.
>>>
>>>I have a server and client component.
>>>
>>>I created a shared object on server and replicated it to the client.
>
> The
>
>>>shared object has properties.
>>>
>>>I created the client container(TCPClientSOContainer) with configuration
>>>properties and created the server container(TCPServerSOContainer) with
>>>properties.
>>>
>>>When the shared object is created in the client, I can get the shared
>
> object
>
>>>properties via a call to the shared object method getConfig().
>>>
>>>What I need access to from the shared object is the container's
>
> properties.
>
>>
>>>From the client shared object I want to access the client container's
>>>properties. From the server shared object I want to access the server
>>>container's properties.
>>>
>>>Is there a way to do this?
>>
>>Yes, but it's not currently in the sharedobjectcontainer api.
>>
>>You could make a trivial subclass of the TCPClientSOContainer and
>>TCPServerSOContainer that overrides 'createSharedObjectContext' method
>>in SOContainer (which is called whenever an shared object is
>>constructed) and fill out the properties passed to the newly created
>>shared object context with whichever of the local container's properties
>>you prefer. This context (and the filled out properties) will be passed
>>to the shared object when its init method is called and so the shared
>>object will have those properties available when its code calls
>>getConfig().getProperties().
>>
>>Now...do think there is reasonable cause here to expose a method on the
>>shared object context to access the local container's properties? This
>>could be easily exposed via a
>>ISharedObjectContext.getLocalContainerProperties() method or some such.
>> Could you describe the use case for this a little further? I hadn't
>>anticipated that shared objects would typically access their container's
>>properties (unless the container explicitly exposes them through
>>mechanism such as above), but this could be a good idea.
>>
>>Thanks,
>>
>>
>>Scott
>>
>>
>
>
>
Re: Access container config properties [message #597209 is a reply to message #597204] Mon, 30 January 2006 18:08 Go to previous messageGo to next message
Jim Wright is currently offline Jim WrightFriend
Messages: 16
Registered: July 2009
Junior Member
I am not not actually using any of the bundle context methods. I need a
BundleContext to create a ServiceTracker to access other registered
services. As in the following

ServiceTracker srvTracker = new
ServiceTracker(context,CollaborationEventRouter.class.getNam e(),null);

I do like the idea of getting a BundleContext without having to pass it
around.

If I wasn't so busy, I think the ECF project would be fun to work on...

JimW

"Scott Lewis" <slewis@composent.com> wrote in message
news:43DE5449.90807@composent.com...
> Hi Jim,
>
> Jim Wright wrote:
> > Scott
> >
> > In my case I need the BundleContext of the Bundle that the
container/shared
> > object is running under. I need to create a ServiceTracker so I can
> > interface with an OSGI service.
> >
> > The first parameter of the ServiceTracker is the BundleContext.
> >
> > By placing this information in the Container's properties, I can use the
> > same code whether the shared object is in the client or the server.
>
> Ah...interesting. Some time ago I had actually anticipated exposing
> org.eclipse.ecf.core.IOSGIService directly (which just exposes the
> BundleContext service access methods). This so that shared object code
> could...with container 'approval'...access local OSGI services...without
> having to do what you are doing (passing round BundleContext refs).
>
> So I think that I should move the API to completion there (it's just not
> finished yet)...in addition to adding the getLocalContainerProperties()
> method to ISharedObjectContext as discussed below. Any comments about
that?
>
> Do you think this is reasonable? Just for curiosity's sake...what
> BundleContext methods are you going after?
>
> >
> > I like the idea of adding
ISharedObjectContext.getLocalContainerProperties()
> > method. It is clean and clearly separates the shared object properties
from
> > the container's properties.
>
> Yes, I will add this method and implementation. After a few minutes
> thought I think it would be a reasonable addition. It won't be deployed
> until 0.6.2, however, which will probably be next week.
>
> BTW Jim...I haven't yet been able to follow up with Corona plan changes,
> support from ECF, etc. Would you like to have a conference call to
> discuss...perhaps sometime later this week or next?
>
> Thanks,
>
> Scott
>
>
> >
> > Thanks,
> >
> > JimW
> >
> > By placing that information in the Container's properties, then I can
use
> > the same code under the client and the server.
> > "Scott Lewis" <slewis@composent.com> wrote in message
> > news:43DE4106.7050007@composent.com...
> >
> >>Hi Jim,
> >>
> >>Jim Wright wrote:
> >>
> >>>I am using ECF for the Eclipse Corona project and have the following
> >>>question.
> >>>
> >>>I have a server and client component.
> >>>
> >>>I created a shared object on server and replicated it to the client.
> >
> > The
> >
> >>>shared object has properties.
> >>>
> >>>I created the client container(TCPClientSOContainer) with configuration
> >>>properties and created the server container(TCPServerSOContainer) with
> >>>properties.
> >>>
> >>>When the shared object is created in the client, I can get the shared
> >
> > object
> >
> >>>properties via a call to the shared object method getConfig().
> >>>
> >>>What I need access to from the shared object is the container's
> >
> > properties.
> >
> >>
> >>>From the client shared object I want to access the client container's
> >>>properties. From the server shared object I want to access the server
> >>>container's properties.
> >>>
> >>>Is there a way to do this?
> >>
> >>Yes, but it's not currently in the sharedobjectcontainer api.
> >>
> >>You could make a trivial subclass of the TCPClientSOContainer and
> >>TCPServerSOContainer that overrides 'createSharedObjectContext' method
> >>in SOContainer (which is called whenever an shared object is
> >>constructed) and fill out the properties passed to the newly created
> >>shared object context with whichever of the local container's properties
> >>you prefer. This context (and the filled out properties) will be passed
> >>to the shared object when its init method is called and so the shared
> >>object will have those properties available when its code calls
> >>getConfig().getProperties().
> >>
> >>Now...do think there is reasonable cause here to expose a method on the
> >>shared object context to access the local container's properties? This
> >>could be easily exposed via a
> >>ISharedObjectContext.getLocalContainerProperties() method or some such.
> >> Could you describe the use case for this a little further? I hadn't
> >>anticipated that shared objects would typically access their container's
> >>properties (unless the container explicitly exposes them through
> >>mechanism such as above), but this could be a good idea.
> >>
> >>Thanks,
> >>
> >>
> >>Scott
> >>
> >>
> >
> >
> >
Re: Access container config properties [message #597216 is a reply to message #597209] Mon, 30 January 2006 18:22 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Jim,

Jim Wright wrote:
> I am not not actually using any of the bundle context methods. I need a
> BundleContext to create a ServiceTracker to access other registered
> services. As in the following
>
> ServiceTracker srvTracker = new
> ServiceTracker(context,CollaborationEventRouter.class.getNam e(),null);

Ah...OK.

>
> I do like the idea of getting a BundleContext without having to pass it
> around.

Hmmm. Perhaps the IOSGIService interface should be enhanced to provide
direct access to BundleContext. BTW, there is a 'getServiceAccess()'
method on ISharedObjectContext interface...although the current
implementations just return null. That can/could be easily fixed, however.

>
> If I wasn't so busy, I think the ECF project would be fun to work on...

I have a similar perspective :).

This project is largely in the hands of the developer/committer
community, and the community can drive it in directions where they
want/need it to go. Please just be open about your needs and desires so
that they can be addressed (through newsgroups, ecf-dev, bug
reports/feature requests, etc)...and be patient as we're an extremely
small, but active group.

BTW, the ECF committer group is also growing larger...so if any are able
to provide their personal and/or employer commitment to supporting ECF
(through adding developers, etc) then please do so!

Thanks,

Scott
Re: Access container config properties [message #597223 is a reply to message #597216] Mon, 30 January 2006 18:35 Go to previous messageGo to next message
Jim Wright is currently offline Jim WrightFriend
Messages: 16
Registered: July 2009
Junior Member
Thanks

I think for now I am going to subclass TCPClientSOContainer and
TCPServerSOContainer.

As new ECF versions appear, I will look for the
ISharedObjectContext.getLocalContainerProperties() method, if it is
implemented.

I did look at get ServiceAccess and did see some use of it in the future.

Thanks

JimW

"Scott Lewis" <slewis@composent.com> wrote in message
news:43DE595E.9000408@composent.com...
> Hi Jim,
>
> Jim Wright wrote:
> > I am not not actually using any of the bundle context methods. I need a
> > BundleContext to create a ServiceTracker to access other registered
> > services. As in the following
> >
> > ServiceTracker srvTracker = new
> > ServiceTracker(context,CollaborationEventRouter.class.getNam e(),null);
>
> Ah...OK.
>
> >
> > I do like the idea of getting a BundleContext without having to pass it
> > around.
>
> Hmmm. Perhaps the IOSGIService interface should be enhanced to provide
> direct access to BundleContext. BTW, there is a 'getServiceAccess()'
> method on ISharedObjectContext interface...although the current
> implementations just return null. That can/could be easily fixed,
however.
>
> >
> > If I wasn't so busy, I think the ECF project would be fun to work on...
>
> I have a similar perspective :).
>
> This project is largely in the hands of the developer/committer
> community, and the community can drive it in directions where they
> want/need it to go. Please just be open about your needs and desires so
> that they can be addressed (through newsgroups, ecf-dev, bug
> reports/feature requests, etc)...and be patient as we're an extremely
> small, but active group.
>
> BTW, the ECF committer group is also growing larger...so if any are able
> to provide their personal and/or employer commitment to supporting ECF
> (through adding developers, etc) then please do so!
>
> Thanks,
>
> Scott
>
>
Re: Access container config properties [message #597232 is a reply to message #597223] Mon, 30 January 2006 22:48 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Jim/all,

I just checked in the following addition to ISharedObjectContext API:

/**
* Get local container properties that it wishes to expose to shared
object access
*
* @return Map of properties available to calling shared object. Map
returned must not be null.
*/
public Map getLocalContainerProperties();

This API change will appear in v0.6.2 stable...probably in next week
build. The generic ISharedObjectContext implementation (aka SOContext)
of this API calls the following method on SOContainer:

protected Map getContainerPropertiesForSharedObject(ID sharedObjectID) {
return new HashMap();
}

Subclasses of SOContainer/Client[Server]SOContainer and
TCPClient[Server]SOContainer may override this SOContainer method as
desired to provide properties to sharedobjects that use
getLocalContainerProperties().

Scott

Jim Wright wrote:
> Thanks
>
> I think for now I am going to subclass TCPClientSOContainer and
> TCPServerSOContainer.
>
> As new ECF versions appear, I will look for the
> ISharedObjectContext.getLocalContainerProperties() method, if it is
> implemented.
>
> I did look at get ServiceAccess and did see some use of it in the future.
>
> Thanks
>
> JimW
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:43DE595E.9000408@composent.com...
>
>>Hi Jim,
>>
>>Jim Wright wrote:
>>
>>>I am not not actually using any of the bundle context methods. I need a
>>>BundleContext to create a ServiceTracker to access other registered
>>>services. As in the following
>>>
>>> ServiceTracker srvTracker = new
>>> ServiceTracker(context,CollaborationEventRouter.class.getNam e(),null);
>>
>>Ah...OK.
>>
>>
>>>I do like the idea of getting a BundleContext without having to pass it
>>>around.
>>
>>Hmmm. Perhaps the IOSGIService interface should be enhanced to provide
>>direct access to BundleContext. BTW, there is a 'getServiceAccess()'
>>method on ISharedObjectContext interface...although the current
>>implementations just return null. That can/could be easily fixed,
>
> however.
>
>>>If I wasn't so busy, I think the ECF project would be fun to work on...
>>
>>I have a similar perspective :).
>>
>>This project is largely in the hands of the developer/committer
>>community, and the community can drive it in directions where they
>>want/need it to go. Please just be open about your needs and desires so
>>that they can be addressed (through newsgroups, ecf-dev, bug
>>reports/feature requests, etc)...and be patient as we're an extremely
>>small, but active group.
>>
>>BTW, the ECF committer group is also growing larger...so if any are able
>>to provide their personal and/or employer commitment to supporting ECF
>>(through adding developers, etc) then please do so!
>>
>>Thanks,
>>
>>Scott
>>
>>
>
>
>
Previous Topic:v 0.6.1 stable now available
Next Topic:ECF as replacement for RMI
Goto Forum:
  


Current Time: Sat Dec 20 19:25:24 GMT 2014

Powered by FUDForum. Page generated in 0.02083 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software