[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.