Hi Raymond
Nice idea. Comments in line...
If we did want to fully support C++ classes as SCA components, i.e. with
references and all the trimings then we could look to use the native runtime
in the same domain, as opposed to in the same VM. Embedding it might be
tricky.
Simon
On Thu, Jun 26, 2008 at 7:16 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Can you describe the use cases you have in mind? It will help us better
> understand what you want to achieve.
>
> Are you interested in contributing in this area? I can give some pointers
> and thoughts to get you started. The following is based on my on-the-surface
> thoughts.
>
> For example, you have a C/C++ DLL which provides some business functions
> and you want to use them to implement SCA components.
>
> As the first step, you can even use implementation.java to call JNI and you
> just have to write an implementation class like:
>
> @Service(Calculator.class)
> public class JNICalculatorImpl implements Calculator {
> static {
> System.loadLibrary("calculator.dll");
> }
> public native int method calculate(String op, int n1, int n2);
>
> @Reference
> public Add addService;
> }
>
> And configure the component as:
>
> <component name="JNICalculatorComponent">
> <implementation.java class="calculator.dll"/>
> </component>
Did you mean ...
<implementation.java class="JNICalculatorImpl "/>
>
> For the second step, we can try to automate the JNI access as follows:
>
> 1) Model the component as implementation.jni:
>
> <component name="JNICalculatorComponent">
> <implementation.jni library="calculator.dll"/>
> </component>
>
> You also need to provide a componentType file to describe the JNI
> operations (Potentially we can introspect the native C++ interface).
>
> <componentType>
> <service name="Calculator">
> <interface.java interface="calculator.Calculator"/> <!-- This is the
> java interface for the JNI functions -->
> </service>
> <reference name="Add">
> <interface.java interface="calculator.Add"/> <!-- This is the java
> interface for the JNI functions -->
> </service>
> </componentType>
>
> Then we can generate the JNICalculatorImpl class as illustrated above to
> represent the JNI component using ASM.
This looks like a promising and straightforward idea to get dlls working as
component implementations. In the native runtime there is a Java scagen tool
that does C++ header file introspection. Its for generating C++ service
proxy classes but there may be some code that is of use there if there is a
requirement to do instropection in this case
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: ""Dietrich, Björn"" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 25, 2008 11:45 PM
> To: <[email protected]>
> Subject: AW: Apache Tuscany doubts
>
>
> Hi,
>>
>> We are also looking for native (JNI) binding between Java and C++,
>> This would be a real cool feature.
>>
>> Greetings
>> Björn
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Malte Marquarding [mailto:[EMAIL PROTECTED]
>> Gesendet: Donnerstag, 26. Juni 2008 02:51
>> An: [email protected]
>> Betreff: Re: Apache Tuscany doubts
>>
>> Hi,
>>
>> Is there a timeline for the java runtime hosting a c++ component? We are
>> currently evaluating tuscany and need to access c++ components as these are
>> needed for specialized algorithms.
>>
>>
>> Cheers,
>> Malte.
>>
>>
>> At this point, Tuscany has both Java and C++ for 1). But the java
>>> runtime doesn't support C++ component, and not C++ runtime supports
>>> Java component either. So we have to use different runtimes to host
>>> the C++ and Java components at this point, but it's potentially
>>> possible that the Java runtime will be capable of hosting C++ component.
>>>
>>>
>>
>> CENIT AG Systemhaus, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49
>> 711 7825-30, Fax: +49 711 7825-4000, Internet: www.cenit.de
>> Geschaeftsstellen: Berlin, Duesseldorf, Frankfurt, Hamburg, Hannover,
>> Muenchen, Saarbruecken
>> Vorstandsmitglieder: Kurt Bengel, Christian Pusch
>> Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des Aufsichtsrats),
>> Hubert Leypoldt, Andreas Karrer
>> Bankverbindungen:
>> Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166
>> 1040 00 SWIFT-CODE : DEUTDESS,
>> Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532
>> 0155 00 SWIFT-Code : COBADEFF600,
>> BW-Bank (BLZ 600 501 01) Kto. 2 403 313 IBAN : DE17 6005 0101 0002 4033 13
>> SWIFT-Code : SOLADEST
>> Registergericht: Amtsgericht Stuttgart
>> Handelsregister: HRB Nr. 19117
>> Umsatzsteuer: ID-Nr. DE 147 862 777
>>
>>
