Hi John,
John Sisson wrote:
Hello, Maybe I am missing something, but I am having a hard time with UNO development of 'services' for Java. I can specify two IDLS - (stripped) code as follows: ==== the interface ==== #include <com/sun/star/uno/XInterface.idl> module com { module nxps { module nxadv { module unotest { module interfaces { interface XJsTestOne: com::sun::star::uno::XInterface { boolean checkText( [in] string sCheckText ); boolean triggerComplete([in] long waitSeconds ); }; }; }; }; }; }; ==== the service ==== #include <com/sun/star/beans/XPropertySet.idl> #include "XJsTestOne.idl" module com { module nxps { module nxadv { module unotest { module services { service JsTestOne { interface com::nxps::nxadv::unotest::interfaces::XJsTestOne; interface com::sun::star::beans::XPropertySet; [property] string sDocumentId; [property] string sMacroParams; [property] string sMacroResult; [property] string sTriggerInvoked; [property] string sTriggerComplete; }; }; }; }; }; }; == build proceeds using some ant targets modeled after the generic devguide makefiles: - this runs 'idlc' and 'regmerge' and creates a file JsTestOne.uno.rdb - running 'regview' on this shows that there is a spec for interface XJsTestOne - but there is nothing beyond some hierarchy placeholders for service JsTestOne running 'javamaker' produces a skeleton JsTestOne.java and no evidence of JsTestOne.
This seems to be the case for all the other stuff in the devguide. - so the service 'specification' is implemented entirely in user-written code - no evidence of its contract is in the rdb file
There seems to be no point in writing or maintaining service IDL. - unless it is to be used in extension of the service by some other service idl. - is this so?
yes, it is so for all old style services and i can't remember that in the DevGuide is written that we generate code for this kind of services.
But i agree that it is not easy to understand when you familiar with Corba. With our new style services this will change and a constructor method is created for this services (see http://udk.openoffice.org/common/man/draft/multinherit.html and the new updated DevGuide, part of the SDK and online hopefully in the next days).
For your example i would suggest to use the a new style service and that you adapt your interface accordingly.
interface XJsTestOne: com::sun::star::uno::XInterface {
boolean checkText( [in] string sCheckText );
boolean triggerComplete([in] long waitSeconds );[attribute] string DocumentId {
get raises (UnknownPropertyException);
set raises (IllegalArgumentException);
};
[attribute] string MacroParams {
get raises (UnknownPropertyException);
set raises (IllegalArgumentException);
};
[attribute] string MacroResult {
get raises (UnknownPropertyException);
set raises (IllegalArgumentException);
};
[attribute] string TriggerInvoked {
get raises (UnknownPropertyException);
set raises (IllegalArgumentException);
};
// for example this is also possible and default get/set methods are generated
[attribute] string TriggerComplete;
};
service JsTestOne : XJsTestOne {
// define here your own create methods, for example:
create([in]string sArgument)
raises (::com::sun::star::lang::IllegalArgumentException);
};Use a multiple inheritance interface if necessary and specify the properties as attributes at the interface. For attributes get/set methods will be created, where you can specify additional exceptions. Inheritance of XInterface is done implicitly, you don't have to write it.
For your service you can specify additonal create methods, for example with parameters. This create methods are internally mapped to a createInstanceWithArgumentsAndContext call. In fact of this your implementation has to implement XInitialization.
In your client code you can then simple write
XComponentContext xCtx = .... // get from anywhere; XJsTestOne = JsTestOne.create( xCtx, "Hello");
This new features are available with OO2.0
Hope this helps
- Juergen
- maybe it should be in the devguide.
What have I missed here? The Visbroker Corba codewright engine created stubs for both interfaces and services.
Thank you, John Sisson
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
