Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] server setup and using an internal API?
[CDO] server setup and using an internal API? [message #423472] Tue, 30 September 2008 19:02 Go to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
I'm starting to learn CDO, and I'm finding that server setup is
somewhat confusing. I followed the directions here:

http://wiki.eclipse.org/Setting_up_a_CDO_Server

to get started, and I got a simple test model working. Now, I need to
set up the CDO server as a service of our existing Eclipse / OSGi
server. Looking at the CDOServerApplication, I see there are utilities
to read and process the cdo-server.xml, but they are in an "internal"
package which tells me that I shouldn't use them. However, I also see
that those packages are exported, which should mean that they are
public API.

I also see instructions that appear to set up everything in code
instead of using the sdo-server.xml here:

http://wiki.eclipse.org/Run_a_CDO_container_inside_eclipse_r untime

So, my question is: What is the preferred way to set up a CDO server in
an Eclipse / OSGi server where I own the application entry point?

Bryan
Re: [CDO] server setup and using an internal API? [message #423473 is a reply to message #423472] Tue, 30 September 2008 19:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Bryan,

Eclipse recommends exporting all packages, even the internal ones,
because you just never know who may absolutely need to assume the risk
of using internal API. Besides, all of the plug-ins in a component
generally have access to one another's internals, but OSGi wouldn't make
them available if they weren't exported.

Cheers,

Christian


Bryan Hunt wrote:
> I'm starting to learn CDO, and I'm finding that server setup is somewhat
> confusing. I followed the directions here:
>
> http://wiki.eclipse.org/Setting_up_a_CDO_Server
>
> to get started, and I got a simple test model working. Now, I need to
> set up the CDO server as a service of our existing Eclipse / OSGi
> server. Looking at the CDOServerApplication, I see there are utilities
> to read and process the cdo-server.xml, but they are in an "internal"
> package which tells me that I shouldn't use them. However, I also see
> that those packages are exported, which should mean that they are public
> API.
>
> I also see instructions that appear to set up everything in code instead
> of using the sdo-server.xml here:
>
> http://wiki.eclipse.org/Run_a_CDO_container_inside_eclipse_r untime
>
> So, my question is: What is the preferred way to set up a CDO server in
> an Eclipse / OSGi server where I own the application entry point?
>
> Bryan
>
Re: [CDO] server setup and using an internal API? [message #423483 is a reply to message #423473] Wed, 01 October 2008 09:03 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6468
Registered: July 2009
Senior Member
Guys,

We are always paying special attention to the proper separation of
public and internal code. We generally list all packages in the manifest
(with versions). Usually packages with "internal" in their name are
marked x-internal or x-friends so that you can use them on your own risk
and get builder warnings in each case.

That said, we've found it to be extremely difficult to satisfy both at
the same time:

1) Protect regular API clients from using the internal code
2) Provide extenders (e.g. IStore implementors) with convenient base classes

You're addressing one (if not the only) place where 2) led to a package
with "internal" in its name but *not* marked x-friend. This is only
because we don't know all "friends", the package is really meant to be
non-public. I also played with "mandatory attributes" (see OSGi Spec) to
give selective access to SPI packages although they have no PDE UI
support, but without success. From the platform I have the impression
that they solve this issue by simply making all packages public. We'd
appreciate to hear from others how they solve these issues!

Apart from this more general discussion CDO and Net4j are strictly
separating the aspects of component code (functionality) and wiring
code. Almost all components undergo this lifecycle:
1) Instantiation
2) Configuration/Wiring
3) Activation
4) Servicing
5) Deactivation

Usually only 4) is publicly available through the service API.
3) and 5) are available through ILifecycle or LifecycleUtil.

1) and 2) depend a bit on the environment. In standalone mode (i.e. no
OSGi running) you can directly call "new" on the component
implementation classes and use the component setters. For the most
common use cases we always have public XyzUtil convenience classes with
static createXyz() methods. In all environments you could use an
IManagedContainer (in Eclipse for example IPluginContainer.INSTANCE
which is extension point based for factories and post processors). The
org.eclipse.emf.cdo.examples plugin gives an impression about these
possibilities.

Especially for the server side I like the possibility to configure the
repositories through the Spring Framework. See
org.eclipse.emf.cdo.examples.spring for an example.

I can imagine that all this is confusing at the first time but I also
hope that you'll like the flexibility that we tried to achieve for the
non-servicing aspects. If there are certain issues left please don't
hesitate to ask here or file a Bugzilla.

Cheers
/Eike


Christian W. Damus schrieb:
> Hi, Bryan,
>
> Eclipse recommends exporting all packages, even the internal ones,
> because you just never know who may absolutely need to assume the risk
> of using internal API. Besides, all of the plug-ins in a component
> generally have access to one another's internals, but OSGi wouldn't
> make them available if they weren't exported.
>
> Cheers,
>
> Christian
>
>
> Bryan Hunt wrote:
>> I'm starting to learn CDO, and I'm finding that server setup is
>> somewhat confusing. I followed the directions here:
>>
>> http://wiki.eclipse.org/Setting_up_a_CDO_Server
>>
>> to get started, and I got a simple test model working. Now, I need
>> to set up the CDO server as a service of our existing Eclipse / OSGi
>> server. Looking at the CDOServerApplication, I see there are
>> utilities to read and process the cdo-server.xml, but they are in an
>> "internal" package which tells me that I shouldn't use them.
>> However, I also see that those packages are exported, which should
>> mean that they are public API.
>>
>> I also see instructions that appear to set up everything in code
>> instead of using the sdo-server.xml here:
>>
>> http://wiki.eclipse.org/Run_a_CDO_container_inside_eclipse_r untime
>>
>> So, my question is: What is the preferred way to set up a CDO server
>> in an Eclipse / OSGi server where I own the application entry point?
>>
>> Bryan
>>


Previous Topic:Mapping EObjects to DOM objects already in memory
Next Topic:[CDO] Should Audit validate the timestamp on instantiation?
Goto Forum:
  


Current Time: Mon Jan 27 22:34:56 GMT 2020

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

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

Back to the top