Michael Rumpf wrote: > > Hi Paul, > > > AltRMI is getting quite mature now. We want to have a transport that > utilises CORBA. (SOAP too later). We have an Ant task that can take some > java interfaces and make AltRMI proxies (they are transport > independant). It > would be nice to have a switch called "generateIDL too" so that at > deployment of the AltRMI using app, CORBA was an option. > > > > We are thinking thate there is some reusable part of 'enterprise' that > might fit the bill. Could you give me some initial thoughts... > > The rmi package has not been moved into the enterprise package of > the avalon > project, it is still located on http://openorb.sf.net under the name > RMIoverIIOP. > > > * Do you have a Java stub compiler from IDL source? > > Yes it has a JavaToIdl compiler... > > > * Is it an Ant task? > > No.
But I don't think it would be to much of a problem to make an ant wrapper (once the static issues mentioned by Michael) have dissapeared. > > * Could we resuse it? > > It depends on what you want to do. The org.openorb.rmi.compiler.JavaToIdl is > somewhat broken. It is dependent on the IdlCompiler from the > OpenORB package and as the IdlCompiler it uses static variables for > initialization. This becomes ugly as soon as you want to start the > compiler in process a multiple times. When creating a new instance the > static fields are not reset and you > have to either do that manually or create some wrapper that > starts it out of process ( as we didi with Runtime.exec())... > Another problem is its internal design, it does not use JavaCC for parsing > and a as a consequence it is not as mature as it could be. > > However, light is at the end of the tunnel as Jesper from our > team started a complete rewrite of the IdlCompiler which will be > extended by JavaToIdl functionality once it has reached a certain kind > of usable state... > > > * Does it have dynamic (on the fly) capability? > > What exactly do you mean by that ? I think what Pete's getting at is the ability to generate stubs on the fly - i.e. imagine the compiler mounted as a service - provide a class, a path, execute, stubs are ready to run ... and be able to do that repeatedly on demand within a single VM session. I think we run into trouble with the static state on this - but to be frank I not really that familiar with the scope of the static problem. Maybe its fixable relatively easily. > Regards, > Michael > > > PS: Steve, not that elaborated but a starting point... ;-) So this is the price I pay for stuffing around with the build file :-) Cheers, Steve. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
