Home » Modeling » EMF » [CDO] server setup and using an internal API?
|
| Re: [CDO] server setup and using an internal API? [message #423473 is a reply to message #423472] |
Tue, 30 September 2008 19:17   |
Eclipse User |
|
|
|
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 |
|
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
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:33:57 GMT 2024
Powered by FUDForum. Page generated in 0.03054 seconds |
] 
Search
Help
Register
Login
Home
