[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[equinox-dev] Reuse registry implementation in 'org.eclipse.core.internal.registry';
|
Hello exquinox dev list,
I´ve posted the following two messages to the platform core dev list and
I got good advice from Peter Kriens.
After that Thomas Watson told me to post my questions also to
equinox-dev, as there are the equinox server side guys. So if somebody
can help me or even better if somebody works on a similar project.
Regards
---
Joachim
<snip>
Hello List,
for some weeks I read through the Eclipse core/equinox/osgi bundles and
found the Implementation of the ExtensionPoint Registry useful for my
Implementation of an runtime object registry. So I wanted to reuse some
classes that implement IObjectManager, Handle etc.
But I´m facing serious problems due to Java and OSGi bundle acilities
(Classes are not Exportet in the Bundle Manifest, or simply defined
'private')
Is there, despite duplicating relevant classes into my plugin, a way to
use these facilities.
Thank you in advantage
---
Joachim
P.S.: Where is the right place to get advice for a design issue with a
sever side equinox/OSGi application which should contain of eclipse non
gui plugins. Can anybody help me.
</snip>
<snip>
Hello Peter,
now let me explain why I would like to reuse btw. extend the registry
API for my purposes. I´m trying to develop a proof of concept:
Mirgrating an erp plattform based on c and odbc to java and some kind of
or-mapping.
The old platform uses 2 basic concepts: Masks and Formulars. Mask
encapsulate one the on hand the data model on the other define the
relation database scheme. Formulars contain the commands triggerd by
some well defined mask actions. Both concepts can be extended and
modified through a module compiler, which makes it possiple for a higher
level application to modify a field or an action of an preceeding
module. (for example: the crm mask extends the address mask). This is
done by a compiler. So if you change a mask, the application has to be
recompiled, application stopped, database scheme adapted and application
restarted. Very tedious and no more bareable in an enterprise
application!
So I came to the OSGi architekture in genereal and the exquionx/eclipse
plugin specially. I would like to use a registry in two places.
First a registry should keep track of all value objects bound to a
session. These registry will be needed to syncronize the client
application (should be a eclipse (e)RCP gui), to validate, etc.
Second I need to provide some mechanism to make masks, fields and
actions/commands extendible for other plugins. But I dont want the
plugin-developer to define an extension-point for every fragment of the
mask...
So I´m totaly disconcerted about to manage all things (and probably not
experienced enough). But I´m sure that equinox would be the absolut
right platform for such an application. Do you some advice?
Regards
---
Joachim Rosskopf
</snip>
Am Mittwoch, den 12.04.2006, 10:13 +0200 schrieb Peter Kriens:
> Classes that are not exported are implementation classes and should
not be used.
> However, the extension registry is intended to be used. So something
> looks fishy.
>
> JR> P.S.: Where is the right place to get advice for a design issue
with a
> JR> sever side equinox/OSGi application which should contain of
eclipse non
> JR> gui plugins. Can anybody help me.
> I'd gladly help out, just send us the design issues you are struggling
> with.
>
> Kind regards,
>
> Peter Kriens
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev
Maybe you should take a step back and look at the requirements. It
looks like you think very much in the existing architecture.
OSGi/Equinox will give a powerful component model which might be
suitable for the task at hand but is a possible mismatch to your
current architecture.
I assume (with the little knowledge I have of ERP systems) that you
want run a large number of applications that:
1. Collaborate
2. Share and extend a data model (Masks?)
3. Share and extend common functions (Formulars?)
4. Share client sessions
It appears that an application would be a bundle in the OSGi model. In
this model, a bundle must be able to use a central data model or in
your case a registry of Masks. The bundle must be able to also provide
functionality which sounds like your Formulars.
The natural model for these interactions is the OSGi service registry.
A service is any java object that you register with the framework with
a set of properties. Other bundles can get notifications or query the
registry for services. This is a very dynamic model that works very
well. It handles dynamics well and one of the great software
advantages is that it uses Java interfaces which are easy to use and
provide type safety. The declarative services remove most of the
overhead. Sharing is also very easy because all objects are available to
all applications (security permitting).
The Equinox registry is different. It is described in XML schema that
belongs to a single bundle. Other bundles can contribute to this
extension point, but they can not directly use the contributors. The
intention of the registry is not so much sharing as well as allowing a
single bundle to define how its plugins should look like.
BJ and Jeff McAffer have explained this better in their presentation:
http://www.eclipsecon.org/2006/Sub.do?id=185
To conclude. It sounds like you have to do some core architecture
design that takes the requirements of your current ERP system into
account as well as the facilities that OSGi/Equinox provide. This type
of architectural work is crucial for a good result, but it is also
very hard because decisions tend to be amplified strongly (bad becomes
really bad, and good becomes, well, good).
So my advice depends. If your company has high expectations of the
OSGi route it should try to get help from an architect that has
designed OSGi based systems; this will be well worth the money.
If your project is just an evaluation project to see if it
might be useful in the future, I suggest to use the time to
get some OSGi/Equinox expertise by building some simple examples
and learning the difference between extension points and
OSGi services.
Overall I think that an ERP system designed OSGi technology is
extremely attractive; ERP systems seem to require a high degree of
extendibility.
Kind regards,
Peter Kriens
JR> Hello Peter,
JR> now let me explain why I would like to reuse btw. extend the
registry
JR> API for my purposes. IŽm trying to develop a proof of concept:
JR> Mirgrating an erp plattform based on c and odbc to java and some
kind of
JR> or-mapping.
JR> The old platform uses 2 basic concepts: Masks and Formulars. Mask
JR> encapsulate one the on hand the data model on the other define the
JR> relation database scheme. Formulars contain the commands triggerd by
JR> some well defined mask actions. Both concepts can be extended and
JR> modified through a module compiler, which makes it possiple for a
higher
JR> level application to modify a field or an action of an preceeding
JR> module. (for example: the crm mask extends the address mask). This
is
JR> done by a compiler. So if you change a mask, the application has to
be
JR> recompiled, application stopped, database scheme adapted and
application
JR> restarted. Very tedious and no more bareable in an enterprise
JR> application!
JR> So I came to the OSGi architekture in genereal and the
exquionx/eclipse
JR> plugin specially. I would like to use a registry in two places.
JR> First a registry should keep track of all value objects bound to a
JR> session. These registry will be needed to syncronize the client
JR> application (should be a eclipse (e)RCP gui), to validate, etc.
JR> Second I need to provide some mechanism to make masks, fields and
JR> actions/commands extendible for other plugins. But I dont want the
JR> plugin-developer to define an extension-point for every fragment of
the
JR> mask...
JR> So IŽm totaly disconcerted about to manage all things (and probably
not
JR> experienced enough). But IŽm sure that equinox would be the absolut
JR> right platform for such an application. Do you some advice?
JR> Regards
JR> ---
JR> Joachim Rosskopf
JR> Am Mittwoch, den 12.04.2006, 10:13 +0200 schrieb Peter Kriens:
>> Classes that are not exported are implementation classes and should
not be used.
>> However, the extension registry is intended to be used. So something
>> looks fishy.
>>
>> JR> P.S.: Where is the right place to get advice for a design issue
with a
>> JR> sever side equinox/OSGi application which should contain of
eclipse non
>> JR> gui plugins. Can anybody help me.
>> I'd gladly help out, just send us the design issues you are
struggling
>> with.
>>
>> Kind regards,
>>
>> Peter Kriens
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev
