[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [bpel-dev] DOM Facade work
|
Michal,
now I see what you mean. I am actually a little bit sceptical ... the
reason why I am sceptical is: In the long term, the proper solution for
BPEL MUST be to have our own ExtensibilityElement class instead of
conveniantly reusing WSDL's one
Then your approach would stop working right away. So I guess if I had to
vote I would vote against the short-term WSDL based solution and rather
spend some time in implementing the recipe in the first shot (btw, any
updates on this ? Did someone actually start looking at that problem?), and
then moving towards a BPELExtensibilityElement base class ? What you think
?
Cheers
Simon
Simon Moser, M.Eng. Mail: IBM Deutschland
smoser@xxxxxx Entwicklung GmbH
Team Lead BPEL Editor / .com Vorsitzender des
Websphere Integration Phone: Aufsichtsrats: Johann
Developer +49-7031-16-4 Weihen
Dept. 4722, Bldg. 71032-01, 304 Geschäftsführung: Herbert
Room 086 Fax: Kircher
Websphere Solutions and +49-7031-16-4 Sitz der Gesellschaft:
Services 890 Böblingen
IBM Deutschland Entwicklung Registergericht:
GmbH Amtsgericht Stuttgart, HRB
Schönaicherstr. 220, D – 243294
71032 Boeblingen
Michal
Chmielewski
<michal.chmielews To
ki@xxxxxxxxxx> "BPEL Designer project developer
Sent by: discussions."
bpel-dev-bounces@ <bpel-dev@xxxxxxxxxxx>
eclipse.org cc
Subject
04/12/2007 11:38 Re: [bpel-dev] DOM Facade work
PM
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
Simon D Moser wrote:
Michal,
just a short response:
I am OK with also extending Import etc. from ExtensibleElement -
eventually
we have to do this anyway when we move up to be fully 2.0 compliant.
Concerning the XMLSerializer I also have no objections.
ok
However, I dont understand your "one direction" comment. In that
recipe
that I posted some time ago I have the xx2XML and XML2xx in the
xxClass
(substitute xx by Receive etc.), so that should be bidirectional, and
I
would actually prefer that solution instead of some temporary.
well there is a mechanism to do DOM facading within WSDLElement, that's
all.
It's a little different then the one you talked about, I just assumed we
could use what's there. It actually does it both ways on closer examination
...
Or am I misunderstanding something here ?
Cheers
Simon
Simon Moser, M.Eng. Mail: IBM Deutschland
smoser@xxxxxx Entwicklung GmbH
Team Lead BPEL Editor / .com Vorsitzender des
Websphere Integration Phone: Aufsichtsrats: Johann
Developer +49-7031-16-4 Weihen
Dept. 4722, Bldg. 71032-01, 304 Geschäftsführung:
Herbert
Room 086 Fax: Kircher
Websphere Solutions and +49-7031-16-4 Sitz der Gesellschaft:
Services 890 Böblingen
IBM Deutschland Entwicklung Registergericht:
GmbH Amtsgericht Stuttgart,
HRB
Schönaicherstr. 220, D – 243294
71032 Boeblingen
Michal
Chmielewski
<michal.chmielews
To
ki@xxxxxxxxxx> "BPEL Designer project
developer
Sent by: discussions."
bpel-dev-bounces@ <bpel-dev@xxxxxxxxxxx>
eclipse.org
cc
Subject
04/10/2007 12:36 [bpel-dev] DOM Facade work
AM
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
Bruno,
Any news on that ?
Simon,
I've actually taken a look at some of the code that's in there in
BPELWriter trying to fix an indent problem on save of the process
map.
Turns out there some strange settings in JDK5 on the transformer
defaults that can only be overwritten via bootclasspath settings ...
I
managed to locate this bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5064280
So I replaced the code in there (10 lines or so) with the xerces
specific XMLSerializer way of saving things (which is in an eclipse
plugin, so isolating that from the JDK issue)
Regarding the DOM facade, we derive almost everything from
WSDLElement
ultimately (via ExtensibilityElement) - there were a few EMF objects
that did not do that (like import for example and a couple of
others). I
had made the change to derive these from WSDLElement too just so that
I
can have the getElement() setElement() capability on all of our model
objects.
Now I reckon there is already some capability in that layer to
reconcile
changes which are applied to the model to the DOM elements present
within. I looked at the code down low and it seemed that all the
parts
around moving, attaching,detaching, etc. seem to be there. The only
thing that remains to be written I think is some way to flush the
current state of the EMF object to the DOM element it wraps when the
EMF
objects changes. This is not as nice a facade as it could be (since
it
is one directional) ... but it would serve our immediate purpose of
preserving some of the nodes which are currently destroyed during
reading/writing.
Thoughts ?
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
