[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [equinox-dev] Reuse registry implementation in'org.eclipse.core.internal.registry';
|
Hi Joachim,
For the server side equinox stuff you might take a look at http://www.eclipse.org/equinox/incubator/server/index.php.
The majority of work to date has been about allowing one to embed Eclipse/Equinox in a J2EE app server.
I'd definitely be interested to hear what sorts of requirements J2EE or otherwise you might have on the infrastructure.
-Simon
> -----Original Message-----
> From: equinox-dev-bounces@xxxxxxxxxxx
> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Joachim Rosskopf
> Sent: Wednesday, April 12, 2006 3:28 PM
> To: equinox-dev@xxxxxxxxxxx
> Subject: [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
>
>
>
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
