Home » Archived » M2M (model-to-model transformation) » [QVTO] Passing calling context to BlockBox methods
|
| Re: [QVTO] Passing calling context to BlockBox methods [message #487508 is a reply to message #487491] |
Wed, 23 September 2009 13:16   |
Eclipse User |
|
|
|
Originally posted by: dvorak.radek.gmail.com
Hi Derek,
There is no direct support at the moment.
But it's a good idea and we will add support for this,
should not be a big deal.
What we can do is to provide a well known callback interface which a
library
may implement. It could manage some life-cycle aspects and also receive
an execution context at the library initialization time,
where you can put the user data.
We wanted to add sort of runtime context anyway for giving access to the
QVTO Engine,
like logger, configuration properties etc.
Regards,
/Radek
On Wed, 23 Sep 2009 14:29:20 +0200, Derek Palma <derek.palma@gmail.com>
wrote:
> Hi,
>
> I ran into a challenge interfacing some Java code as a black box. The
> java code needs some runtime context. I could use a static class
> variable and set it before I run QVT, but I was wondering if there is a
> better way. Is it possible to to use configuration properties for this
> purpose? I would need to pass an "opaque" configuration property which
> is set to reference the Java runtime context. I could then pass this to
> the library each time I invoke it or just once at the beginning. Is this
> correct/possible? Could I just create a special EClasss/EObject to hold
> my runtime context when I pass it in? Is there a more appropriate
> solution for this? Is there any other way to inject context into the
> black box library instance which seems to be my main issue?
>
> Thanks
> Derek
|
|
|
| Re: [QVTO] Passing calling context to BlockBox methods [message #487555 is a reply to message #487508] |
Wed, 23 September 2009 14:55 |
 Derek Palma
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Thanks Radek!
This made me think of another issue. What happens if java code throws
exceptions. Is there a way the QVT code can catch them?
Also, the same question from the QVT perspective is also interesting. What
happens if QVT code throws an exception? I am not familiar enough with QVT
to know what happens if there is an uncaught raised exception in QVT. Does
TransformationExecutor just catch Throwable and consume all execptions
generated during QVT execution and map them to Diagnostics?
Derek
"radek dvorak" <dvorak.radek@gmail.com> wrote in message
news:op.u0pohxwb12y5f2@kliste.local...
> Hi Derek,
>
> There is no direct support at the moment.
> But it's a good idea and we will add support for this,
> should not be a big deal.
>
> What we can do is to provide a well known callback interface which a
> library
> may implement. It could manage some life-cycle aspects and also receive
> an execution context at the library initialization time,
> where you can put the user data.
>
> We wanted to add sort of runtime context anyway for giving access to the
> QVTO Engine,
> like logger, configuration properties etc.
>
> Regards,
> /Radek
>
>
> On Wed, 23 Sep 2009 14:29:20 +0200, Derek Palma <derek.palma@gmail.com>
> wrote:
>
>> Hi,
>>
>> I ran into a challenge interfacing some Java code as a black box. The
>> java code needs some runtime context. I could use a static class
>> variable and set it before I run QVT, but I was wondering if there is a
>> better way. Is it possible to to use configuration properties for this
>> purpose? I would need to pass an "opaque" configuration property which
>> is set to reference the Java runtime context. I could then pass this to
>> the library each time I invoke it or just once at the beginning. Is this
>> correct/possible? Could I just create a special EClasss/EObject to hold
>> my runtime context when I pass it in? Is there a more appropriate
>> solution for this? Is there any other way to inject context into the
>> black box library instance which seems to be my main issue?
>>
>> Thanks
>> Derek
|
|
|
| Re: [QVTO] Passing calling context to BlockBox methods [message #487592 is a reply to message #487555] |
Wed, 23 September 2009 16:42 |
| Eclipse User |
|
|
|
Originally posted by: dvorak.radek.gmail.com
Hi Derek,
See in-lined response.
Regards,
/Radek
>
> This made me think of another issue. What happens if java code throws
> exceptions. Is there a way the QVTO code can catch them?
As for now, OCL Invalid is returned to the QVTO caller of the blackbox
operation.
The same is done by OCL if an ecore model operation is called so we just
kept consistent.
It should not be a problem for a black-box library to indicate that it
wants
to propagate the exception to the calling QVTO Engine.
>
> Also, the same question from the QVT perspective is also interesting.
> What happens if QVT code throws an exception? I am not familiar enough
> with QVT to know what happens if there is an uncaught raised exception
> in QVT. Does TransformationExecutor just catch Throwable and consume all
> execptions generated during QVT execution and map them to Diagnostics?
You should never get an exception from the TransformationExecutor but a
proper
diagnostic object instead. If you get one, please report a bug.
There are several exceptions already raised by QVT Engine, like a fatal
assertion failed (according to OMG spec), stack trace overflow (easy if
you are imperative),
read-only model modification etc.
These are typically QVTO programming errors which we can't recover from
meaningfully,
therefore they cause a transformation to terminate.
See org.eclipse.m2m.qvt.oml.ExecutionDiagnostic.getStackTrace() method,
which gives the
stack trace of the QVTO Engine, which appears in a Java style but reflects
the QVTO execution stack frames.
You can use convenience operation
org.eclipse.m2m.qvt.oml.ExecutionDiagnostic.printStackTrace( PrintWriter)
to print it out.
As for now, you can't catch exceptions programmatically in QVTO concrete
syntax.
The OMG spec defines <try-catch> in the grammar but we have not
implemented yet,
as we have not found it as essential feature as the other that we needed
to address.
I think, we should not do anything like catching all exceptions on the way
and put
them into the resulting diagnostic, but rather terminate execution if no
explicit <catch> statement has handled that.
Summarized:
1) Adding support for a generic exception thrown by a black-box operation
to
cause the QVTO Engine terminate is reasonably easy. A proper stack trace
would be produced.
2) Adding support for a custom exception <catch, throw> requires more work
-
- adding support in the concrete syntax, which we are currently
updating to catch up with MDT OCL
- execution engine update (though the stack frame unwiding is more or
less ready)
Not sure if it solves your case but hope this helps to clarify things ;)
> "radek dvorak" <dvorak.radek@gmail.com> wrote in message
> news:op.u0pohxwb12y5f2@kliste.local...
>> Hi Derek,
>>
>> There is no direct support at the moment.
>> But it's a good idea and we will add support for this,
>> should not be a big deal.
>>
>> What we can do is to provide a well known callback interface which a
>> library
>> may implement. It could manage some life-cycle aspects and also receive
>> an execution context at the library initialization time,
>> where you can put the user data.
>>
>> We wanted to add sort of runtime context anyway for giving access to
>> the QVTO Engine,
>> like logger, configuration properties etc.
>>
>> Regards,
>> /Radek
>>
>>
>> On Wed, 23 Sep 2009 14:29:20 +0200, Derek Palma <derek.palma@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I ran into a challenge interfacing some Java code as a black box. The
>>> java code needs some runtime context. I could use a static class
>>> variable and set it before I run QVT, but I was wondering if there is
>>> a better way. Is it possible to to use configuration properties for
>>> this purpose? I would need to pass an "opaque" configuration property
>>> which is set to reference the Java runtime context. I could then pass
>>> this to the library each time I invoke it or just once at the
>>> beginning. Is this correct/possible? Could I just create a special
>>> EClasss/EObject to hold my runtime context when I pass it in? Is there
>>> a more appropriate solution for this? Is there any other way to inject
>>> context into the black box library instance which seems to be my main
>>> issue?
>>>
>>> Thanks
>>> Derek
>
|
|
|
Goto Forum:
Current Time: Fri Jan 24 22:16:45 GMT 2025
Powered by FUDForum. Page generated in 0.03254 seconds |
] 
Search
Help
Register
Login
Home
