Home » Modeling » EMF » [CDO] Possibilities and constraints of using CDO
| [CDO] Possibilities and constraints of using CDO [message #488546] |
Tue, 29 September 2009 08:28  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'm trying to understand how the possibilities and constraints of using
CDO. The context of this is the toolkit model of e4, so a model in this
context corresponds to a (live) UI, possibly with a related data model.
It's my understanding that there's two ways to get a CDO-ready model:
you either use dynamic instances or generate CDO-supporting code using
an edited genmodel. (replacing the superclass of the interface and
implementation). Hence, if you want to support using the model in two
modes, one without CDO and one with, you must generate two versions, one
with and one without CDO-support? How should these to versions (naming,
package uri, ...) be handled to ensure the correct factory and/or
resource is used?
I'm considering the following scenario: I have a large model which
supports containment proxies, so a large EObject hierarchy can easily be
split into several resources, each containing a sub-tree. Now I want to
1) select a sub-tree, press a "Share..." button and prompt for a CDO
repository location
2) somehow copy that sub-tree into a CDO-managed resource in the
provided repository
3) replace the in-memory sub-tree by the CDO-managed resource and
4) send a link (CDO uri) to the person I want to share that resource
with. The other person will load that resource (without the surrounding
tree) and take part in a shared editing session.
Is it possible to support such a mode, where a sub-tree (resource) is
managed by CDO and the rest isn't? Would I instead have to share the
whole model, but still be able to split it into smaller resources, to
limit the scope of sharing (by not revealing the uri to the whole model)?
Hallvard
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #488593 is a reply to message #488546] |
Tue, 29 September 2009 11:41  |
|
Hi Hallvard,
I'm currently not in the office, but below some brief comments...
Hallvard Trætteberg schrieb:
> Hi,
>
> I'm trying to understand how the possibilities and constraints of
> using CDO. The context of this is the toolkit model of e4, so a model
> in this context corresponds to a (live) UI, possibly with a related
> data model.
Cool that e4 starts thinking about CDO. I'll have more time to assist
you later on.
>
> It's my understanding that there's two ways to get a CDO-ready model:
> you either use dynamic instances or generate CDO-supporting code using
> an edited genmodel. (replacing the superclass of the interface and
> implementation).
We'll have a third option available soon: legacy model support. But some
of CDO's advanced functions and characteristics will not be available
with "normal" Ecore models.
> Hence, if you want to support using the model in two modes, one
> without CDO and one with, you must generate two versions, one with and
> one without CDO-support? How should these to versions (naming, package
> uri, ...) be handled to ensure the correct factory and/or resource is
> used?
You can also use the CDO'ified version of the model without CDO.
>
> I'm considering the following scenario: I have a large model which
> supports containment proxies, so a large EObject hierarchy can easily
> be split into several resources, each containing a sub-tree. Now I
> want to
> 1) select a sub-tree, press a "Share..." button and prompt for a CDO
> repository location
> 2) somehow copy that sub-tree into a CDO-managed resource in the
> provided repository
That should be easy. Even external cross references are supported by CDO.
> 3) replace the in-memory sub-tree by the CDO-managed resource and
Maybe this can work with containment proxies, but I never tried it. Can
you test it?
> 4) send a link (CDO uri) to the person I want to share that resource
> with. The other person will load that resource (without the
> surrounding tree) and take part in a shared editing session.
Perfectly possible. But keep in mind, that the CDO URI format references
a repository only by its well-known repo UUID! In other words the URI
does not specify *how* to connect to this repository. Usually
application code is necessary to open the needed CDOSession and
CDOTransaction. There are advanced approaches that use e.g. the
extension registry. Do you need more info on this?
>
> Is it possible to support such a mode, where a sub-tree (resource) is
> managed by CDO and the rest isn't?
Containment proxies are the only possibility that pops into my mind.
> Would I instead have to share the whole model, but still be able to
> split it into smaller resources, to limit the scope of sharing (by not
> revealing the uri to the whole model)?
Cross references could easily interfere with this policy! But CDO does
support arbitrary partitioning of the object graph in a repository into
multiple Resources.
Hope that helps for now ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #488683 is a reply to message #488593] |
Tue, 29 September 2009 17:50 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Eike Stepper wrote:
>
>> I'm trying to understand how the possibilities and constraints of
>> using CDO. The context of this is the toolkit model of e4, so a model
>> in this context corresponds to a (live) UI, possibly with a related
>> data model.
> Cool that e4 starts thinking about CDO. I'll have more time to assist
> you later on.
I hope to make some progress in the coming weeks. Cloud computing, here
we come!
> We'll have a third option available soon: legacy model support.
That'll be great!
> You can also use the CDO'ified version of the model without CDO.
Yes, but then you still reference CDO classes and require CDO plugins?
Wouldn't it be possible to use some class loading tricks (AOP) to set
the correct interface and superclass, so you can delay the choice?
>> 1) select a sub-tree, press a "Share..." button and prompt for a CDO
>> repository location
>> 2) somehow copy that sub-tree into a CDO-managed resource in the
>> provided repository
> That should be easy. Even external cross references are supported by CDO.
>
>> 3) replace the in-memory sub-tree by the CDO-managed resource and
> Maybe this can work with containment proxies, but I never tried it. Can
> you test it?
I'm not sure how this is done in practice, perhaps Ed has a recipe? What
happens if we just take the root object of a resource and add it to a
container that supports proxies, but in a different resource.
>> 4) send a link (CDO uri) to the person I want to share that resource
>> with. The other person will load that resource (without the
>> surrounding tree) and take part in a shared editing session.
> Perfectly possible. But keep in mind, that the CDO URI format references
> a repository only by its well-known repo UUID! In other words the URI
> does not specify *how* to connect to this repository.
Yes, I think you answered this question in a different thread. I think I
recall seeing a discussion about a different CDO URI format with
connection-oriented information. Isn't one of the problems that the URI
doesn't reference an input source, i.e. something for which you can
return an InputStream? Hence, the URI must be handled earlier in the
process of resolving it?
> There are advanced approaches that use e.g. the
> extension registry. Do you need more info on this?
I'll perhaps have more specific questions later.
Hallvard
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #488764 is a reply to message #488683] |
Wed, 30 September 2009 08:09 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
Hallvard Trætteberg wrote:
> Eike Stepper wrote:
>>
>>> I'm trying to understand how the possibilities and constraints of
>>> using CDO. The context of this is the toolkit model of e4, so a
>>> model in this context corresponds to a (live) UI, possibly with a
>>> related data model.
>> Cool that e4 starts thinking about CDO. I'll have more time to assist
>> you later on.
>
> I hope to make some progress in the coming weeks. Cloud computing,
> here we come!
>
>> We'll have a third option available soon: legacy model support.
>
> That'll be great!
>
>> You can also use the CDO'ified version of the model without CDO.
>
> Yes, but then you still reference CDO classes and require CDO plugins?
> Wouldn't it be possible to use some class loading tricks (AOP) to set
> the correct interface and superclass, so you can delay the choice?
Perhaps https://bugs.eclipse.org/bugs/show_bug.cgi?id=256706 will help
with that. We also expect to look into a CDO-enabled version of Ecore
itself, to fully enable a CDO-enabled version of UML which extends Ecore
and uses Ecore for Profiles.
>
>>> 1) select a sub-tree, press a "Share..." button and prompt for a CDO
>>> repository location
>>> 2) somehow copy that sub-tree into a CDO-managed resource in the
>>> provided repository
>> That should be easy. Even external cross references are supported by
>> CDO.
>>
>>> 3) replace the in-memory sub-tree by the CDO-managed resource and
>> Maybe this can work with containment proxies, but I never tried it.
>> Can you test it?
>
> I'm not sure how this is done in practice, perhaps Ed has a recipe?
> What happens if we just take the root object of a resource and add it
> to a container that supports proxies, but in a different resource.
If a containment reference has resolveProxies true (you have to enable
generation of that) then any object in that reference can also be
directly contained by a different resource so this should "just work."
>
>>> 4) send a link (CDO uri) to the person I want to share that resource
>>> with. The other person will load that resource (without the
>>> surrounding tree) and take part in a shared editing session.
>> Perfectly possible. But keep in mind, that the CDO URI format
>> references a repository only by its well-known repo UUID! In other
>> words the URI does not specify *how* to connect to this repository.
>
> Yes, I think you answered this question in a different thread. I think
> I recall seeing a discussion about a different CDO URI format with
> connection-oriented information. Isn't one of the problems that the
> URI doesn't reference an input source, i.e. something for which you
> can return an InputStream? Hence, the URI must be handled earlier in
> the process of resolving it?
I always wondered if the streams could be used to communicate the
connection information...
>
>> There are advanced approaches that use e.g. the extension registry.
>> Do you need more info on this?
>
> I'll perhaps have more specific questions later.
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #488787 is a reply to message #488683] |
Wed, 30 September 2009 08:51 |
|
>> You can also use the CDO'ified version of the model without CDO.
>
> Yes, but then you still reference CDO classes and require CDO plugins?
Yes, these:
org.eclipse.emf.cdo
org.eclipse.emf.cdo.common
org.eclipse.net4j.util
> Wouldn't it be possible to use some class loading tricks (AOP) to set
> the correct interface and superclass, so you can delay the choice?
Before 2.0 we've had such an approach, our CDOWeaver. But i found this
too fragile because it heavily relied on internals of EMF classes and
user model classes. Vik told me that his company also had BCE based
approach that worked well. I cc'ed him.
>
>>> 4) send a link (CDO uri) to the person I want to share that resource
>>> with. The other person will load that resource (without the
>>> surrounding tree) and take part in a shared editing session.
>> Perfectly possible. But keep in mind, that the CDO URI format
>> references a repository only by its well-known repo UUID! In other
>> words the URI does not specify *how* to connect to this repository.
>
> Yes, I think you answered this question in a different thread. I think
> I recall seeing a discussion about a different CDO URI format with
> connection-oriented information. Isn't one of the problems that the
> URI doesn't reference an input source, i.e. something for which you
> can return an InputStream? Hence, the URI must be handled earlier in
> the process of resolving it?
You're right, the main "problem" is that we agreed on a URI format for
resources that is agnostic to the way a repository is technically
*reached*. This is mainly because this way may be different on other
machines. Maybe we can introduce additional URI formats for resources
that are URIConverter'ed to the primary format after extracting
connection infos...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #488809 is a reply to message #488764] |
Wed, 30 September 2009 10:16 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Ed Merks wrote:
>>>> 3) replace the in-memory sub-tree by the CDO-managed resource and
>>> Maybe this can work with containment proxies, but I never tried it.
>>> Can you test it?
>>
>> I'm not sure how this is done in practice, perhaps Ed has a recipe?
>> What happens if we just take the root object of a resource and add it
>> to a container that supports proxies, but in a different resource.
> If a containment reference has resolveProxies true (you have to enable
> generation of that) then any object in that reference can also be
> directly contained by a different resource so this should "just work."
I tried it and it did just work! The only thing that wasn't as expected
was the serialization. The sub-tree that moved to a new resource,
included a reference to its container in the XMI:
<tm.widgets:Label xmi:version="2.0" text="Password:">
<composite xsi:type="tm.widgets:Composite" href="login.tm#/"/>
Normally, the container is implicitly the XML parent, but when the child
was the root object of an XMI resource, the reference to the parent in a
different resource was included. This must be handled if the sub-tree is
supposed to be loaded without the rest of the tree.
Would it make sense (and work) to make the container reference (the
opposite of the containment reference) transient?
>> Yes, I think you answered this question in a different thread. I think
>> I recall seeing a discussion about a different CDO URI format with
>> connection-oriented information. Isn't one of the problems that the
>> URI doesn't reference an input source, i.e. something for which you
>> can return an InputStream? Hence, the URI must be handled earlier in
>> the process of resolving it?
> I always wondered if the streams could be used to communicate the
> connection information...
You mean that the stream doesn't contain the actual resource, but
information about how to load the actual resource from the repository. I
guess the important thing is that the resource is populated with the
desired objects after loading from the stream.
Hallvard
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #488839 is a reply to message #488809] |
Wed, 30 September 2009 13:15 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
Hallvard Trætteberg wrote:
> Ed Merks wrote:
>
>>>>> 3) replace the in-memory sub-tree by the CDO-managed resource and
>>>> Maybe this can work with containment proxies, but I never tried it.
>>>> Can you test it?
>>>
>>> I'm not sure how this is done in practice, perhaps Ed has a recipe?
>>> What happens if we just take the root object of a resource and add
>>> it to a container that supports proxies, but in a different resource.
>> If a containment reference has resolveProxies true (you have to
>> enable generation of that) then any object in that reference can also
>> be directly contained by a different resource so this should "just
>> work."
>
> I tried it and it did just work!
Can't say I'm surprised. :-P
> The only thing that wasn't as expected was the serialization. The
> sub-tree that moved to a new resource, included a reference to its
> container in the XMI:
>
> <tm.widgets:Label xmi:version="2.0" text="Password:">
> <composite xsi:type="tm.widgets:Composite" href="login.tm#/"/>
>
> Normally, the container is implicitly the XML parent, but when the
> child was the root object of an XMI resource, the reference to the
> parent in a different resource was included. This must be handled if
> the sub-tree is supposed to be loaded without the rest of the tree.
>
> Would it make sense (and work) to make the container reference (the
> opposite of the containment reference) transient?
It's generally important for cross document references to be serialized
at both ends, so the Ecore validator might complain...
>
>>> Yes, I think you answered this question in a different thread. I
>>> think I recall seeing a discussion about a different CDO URI format
>>> with connection-oriented information. Isn't one of the problems that
>>> the URI doesn't reference an input source, i.e. something for which
>>> you can return an InputStream? Hence, the URI must be handled
>>> earlier in the process of resolving it?
>> I always wondered if the streams could be used to communicate the
>> connection information...
>
> You mean that the stream doesn't contain the actual resource, but
> information about how to load the actual resource from the repository.
That was my suggestion, yes.
> I guess the important thing is that the resource is populated with the
> desired objects after loading from the stream.
Exactly.
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #488846 is a reply to message #488839] |
Wed, 30 September 2009 13:29 |
|
Ed Merks schrieb:
>>>> Yes, I think you answered this question in a different thread. I
>>>> think I recall seeing a discussion about a different CDO URI format
>>>> with connection-oriented information. Isn't one of the problems
>>>> that the URI doesn't reference an input source, i.e. something for
>>>> which you can return an InputStream? Hence, the URI must be handled
>>>> earlier in the process of resolving it?
>>> I always wondered if the streams could be used to communicate the
>>> connection information...
>>
>> You mean that the stream doesn't contain the actual resource, but
>> information about how to load the actual resource from the repository.
>
> That was my suggestion, yes.
Ok, putting the needed connection info into the resource URI and let
"something" in CDO analyze that and create (re-use?) the CDOSession and
the CDOView/Transaction is not too trivial since there are various ways
to create such a connection. But in the end URIs are made for this, or
was it URLs??
I wonder how/where we convert these connection-aware URIs to the
normal(ized) ones. In the URIConverter? would we have to cache the
stripped information somewhere to be able to re-use the existing
transaction for new resources instead of opening new transactions over
and over again (which would not work since CDO has a restriction of a
single view per resource set / repository!)...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #488873 is a reply to message #488846] |
Wed, 30 September 2009 14:55 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050801030401020608050804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
Comments below.
Eike Stepper wrote:
> Ed Merks schrieb:
>
>>>>> Yes, I think you answered this question in a different thread. I
>>>>> think I recall seeing a discussion about a different CDO URI format
>>>>> with connection-oriented information. Isn't one of the problems
>>>>> that the URI doesn't reference an input source, i.e. something for
>>>>> which you can return an InputStream? Hence, the URI must be handled
>>>>> earlier in the process of resolving it?
>>>>>
>>>> I always wondered if the streams could be used to communicate the
>>>> connection information...
>>>>
>>> You mean that the stream doesn't contain the actual resource, but
>>> information about how to load the actual resource from the repository.
>>>
>> That was my suggestion, yes.
>>
> Ok, putting the needed connection info into the resource URI and let
> "something" in CDO analyze that and create (re-use?) the CDOSession and
> the CDOView/Transaction is not too trivial since there are various ways
> to create such a connection. But in the end URIs are made for this, or
> was it URLs??
>
I wasn't suggesting to encode it in the URI itself but rather to encode
it in the bytes of the stream
> I wonder how/where we convert these connection-aware URIs to the
> normal(ized) ones. In the URIConverter?
Yes. In a URIHandler actually.
> would we have to cache the
> stripped information somewhere to be able to re-use the existing
> transaction for new resources instead of opening new transactions over
> and over again (which would not work since CDO has a restriction of a
> single view per resource set / repository!)...
>
It's just a vague idea, but yes, the opening of streams would just
transmit in the bytes of the stream the information for accessing the
appropriate shared transaction.
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
--------------050801030401020608050804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
Comments below.<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:h9vmfq$5na$1@build.eclipse.org" type="cite">
<pre wrap="">Ed Merks schrieb:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Yes, I think you answered this question in a different thread. I
think I recall seeing a discussion about a different CDO URI format
with connection-oriented information. Isn't one of the problems
that the URI doesn't reference an input source, i.e. something for
which you can return an InputStream? Hence, the URI must be handled
earlier in the process of resolving it?
</pre>
</blockquote>
<pre wrap="">I always wondered if the streams could be used to communicate the
connection information...
</pre>
</blockquote>
<pre wrap="">You mean that the stream doesn't contain the actual resource, but
information about how to load the actual resource from the repository.
</pre>
</blockquote>
<pre wrap="">That was my suggestion, yes.
</pre>
</blockquote>
<pre wrap=""><!---->Ok, putting the needed connection info into the resource URI and let
"something" in CDO analyze that and create (re-use?) the CDOSession and
the CDOView/Transaction is not too trivial since there are various ways
to create such a connection. But in the end URIs are made for this, or
was it URLs??
</pre>
</blockquote>
I wasn't suggesting to encode it in the URI itself but rather to encode
it in the bytes of the stream<br>
<blockquote cite="mid:h9vmfq$5na$1@build.eclipse.org" type="cite">
<pre wrap="">
I wonder how/where we convert these connection-aware URIs to the
normal(ized) ones. In the URIConverter?</pre>
</blockquote>
Yes. In a URIHandler actually.<br>
<blockquote cite="mid:h9vmfq$5na$1@build.eclipse.org" type="cite">
<pre wrap=""> would we have to cache the
stripped information somewhere to be able to re-use the existing
transaction for new resources instead of opening new transactions over
and over again (which would not work since CDO has a restriction of a
single view per resource set / repository!)...
</pre>
</blockquote>
It's just a vague idea, but yes, the opening of streams would just
transmit in the bytes of the stream the information for accessing the
appropriate shared transaction.<br>
<blockquote cite="mid:h9vmfq$5na$1@build.eclipse.org" type="cite">
<pre wrap="">
Cheers
/Eike
----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>
</pre>
</blockquote>
</body>
</html>
--------------050801030401020608050804--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #489065 is a reply to message #488787] |
Thu, 01 October 2009 12:15 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Guys,
comments below
>> Wouldn't it be possible to use some class loading tricks (AOP) to set
>> the correct interface and superclass, so you can delay the choice?
> Before 2.0 we've had such an approach, our CDOWeaver. But i found this
> too fragile because it heavily relied on internals of EMF classes and
> user model classes. Vik told me that his company also had BCE based
> approach that worked well. I cc'ed him.
What I successfully did was to substitute the bytecode of one class on
runtime, using ASM. Basically I contributed my own classloader, which
would look for an specific class to be loaded, then intercepts the call
and returns specially crafted bytecode.
ASM provides a great Eclipse View which provides you the sequence of ASM
ops to create certain piece of code. You only have to select the
modified code (for instance, EObjectImpl) and the view will show
automatically the ASM op sequence.
Then, from the custom classloader, you only have to call the static
method that contains all the sequence of ASM operations to obtain the
modified bytecode and return it to the default classloader.
Not sure if this is the best solution, but it works, at least.
If you need more info on this, don't hesitate pinging me.
>>>> 4) send a link (CDO uri) to the person I want to share that resource
>>>> with. The other person will load that resource (without the
>>>> surrounding tree) and take part in a shared editing session.
>>> Perfectly possible. But keep in mind, that the CDO URI format
>>> references a repository only by its well-known repo UUID! In other
>>> words the URI does not specify *how* to connect to this repository.
>> Yes, I think you answered this question in a different thread. I think
>> I recall seeing a discussion about a different CDO URI format with
>> connection-oriented information. Isn't one of the problems that the
>> URI doesn't reference an input source, i.e. something for which you
>> can return an InputStream? Hence, the URI must be handled earlier in
>> the process of resolving it?
> You're right, the main "problem" is that we agreed on a URI format for
> resources that is agnostic to the way a repository is technically
> *reached*. This is mainly because this way may be different on other
> machines. Maybe we can introduce additional URI formats for resources
> that are URIConverter'ed to the primary format after extracting
> connection infos...
I love this idea. I've been struggling in maintaining in our products a
CDO URI translator facade, as we needed URIs meaninful to end users. I
think the URIConverter approach perfectly fit this requirement.
Should we raise a zilla?
Cheers,
ViK.
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #489087 is a reply to message #489065] |
Thu, 01 October 2009 13:18 |
|
Hi Vik,
Please file a bugzilla for the URIConverter thing. And maybe we should
discuss your ASM approach some time via Skype...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Víctor Roldán Betancort schrieb:
> Guys,
>
> comments below
>
> >> Wouldn't it be possible to use some class loading tricks (AOP) to set
> >> the correct interface and superclass, so you can delay the choice?
> > Before 2.0 we've had such an approach, our CDOWeaver. But i found this
> > too fragile because it heavily relied on internals of EMF classes and
> > user model classes. Vik told me that his company also had BCE based
> > approach that worked well. I cc'ed him.
>
> What I successfully did was to substitute the bytecode of one class on
> runtime, using ASM. Basically I contributed my own classloader, which
> would look for an specific class to be loaded, then intercepts the
> call and returns specially crafted bytecode.
> ASM provides a great Eclipse View which provides you the sequence of
> ASM ops to create certain piece of code. You only have to select the
> modified code (for instance, EObjectImpl) and the view will show
> automatically the ASM op sequence.
> Then, from the custom classloader, you only have to call the static
> method that contains all the sequence of ASM operations to obtain the
> modified bytecode and return it to the default classloader.
>
> Not sure if this is the best solution, but it works, at least.
>
> If you need more info on this, don't hesitate pinging me.
>
>
> >>>> 4) send a link (CDO uri) to the person I want to share that resource
> >>>> with. The other person will load that resource (without the
> >>>> surrounding tree) and take part in a shared editing session.
> >>> Perfectly possible. But keep in mind, that the CDO URI format
> >>> references a repository only by its well-known repo UUID! In other
> >>> words the URI does not specify *how* to connect to this repository.
> >> Yes, I think you answered this question in a different thread. I think
> >> I recall seeing a discussion about a different CDO URI format with
> >> connection-oriented information. Isn't one of the problems that the
> >> URI doesn't reference an input source, i.e. something for which you
> >> can return an InputStream? Hence, the URI must be handled earlier in
> >> the process of resolving it?
> > You're right, the main "problem" is that we agreed on a URI format for
> > resources that is agnostic to the way a repository is technically
> > *reached*. This is mainly because this way may be different on other
> > machines. Maybe we can introduce additional URI formats for resources
> > that are URIConverter'ed to the primary format after extracting
> > connection infos...
>
> I love this idea. I've been struggling in maintaining in our products
> a CDO URI translator facade, as we needed URIs meaninful to end users.
> I think the URIConverter approach perfectly fit this requirement.
> Should we raise a zilla?
>
> Cheers,
> ViK.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Possibilities and constraints of using CDO [message #490084 is a reply to message #489087] |
Wed, 07 October 2009 09:38 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Bug 291574 - Provide connection-aware URI format through
URIConverter/URIHandler
https://bugs.eclipse.org/bugs/show_bug.cgi?id=291574
Cheers,
Víctor.
Eike Stepper escribió:
> Hi Vik,
>
> Please file a bugzilla for the URIConverter thing. And maybe we should
> discuss your ASM approach some time via Skype...
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Víctor Roldán Betancort schrieb:
>> Guys,
>>
>> comments below
>>
>>>> Wouldn't it be possible to use some class loading tricks (AOP) to set
>>>> the correct interface and superclass, so you can delay the choice?
>>> Before 2.0 we've had such an approach, our CDOWeaver. But i found this
>>> too fragile because it heavily relied on internals of EMF classes and
>>> user model classes. Vik told me that his company also had BCE based
>>> approach that worked well. I cc'ed him.
>> What I successfully did was to substitute the bytecode of one class on
>> runtime, using ASM. Basically I contributed my own classloader, which
>> would look for an specific class to be loaded, then intercepts the
>> call and returns specially crafted bytecode.
>> ASM provides a great Eclipse View which provides you the sequence of
>> ASM ops to create certain piece of code. You only have to select the
>> modified code (for instance, EObjectImpl) and the view will show
>> automatically the ASM op sequence.
>> Then, from the custom classloader, you only have to call the static
>> method that contains all the sequence of ASM operations to obtain the
>> modified bytecode and return it to the default classloader.
>>
>> Not sure if this is the best solution, but it works, at least.
>>
>> If you need more info on this, don't hesitate pinging me.
>>
>>
>>>>>> 4) send a link (CDO uri) to the person I want to share that resource
>>>>>> with. The other person will load that resource (without the
>>>>>> surrounding tree) and take part in a shared editing session.
>>>>> Perfectly possible. But keep in mind, that the CDO URI format
>>>>> references a repository only by its well-known repo UUID! In other
>>>>> words the URI does not specify *how* to connect to this repository.
>>>> Yes, I think you answered this question in a different thread. I think
>>>> I recall seeing a discussion about a different CDO URI format with
>>>> connection-oriented information. Isn't one of the problems that the
>>>> URI doesn't reference an input source, i.e. something for which you
>>>> can return an InputStream? Hence, the URI must be handled earlier in
>>>> the process of resolving it?
>>> You're right, the main "problem" is that we agreed on a URI format for
>>> resources that is agnostic to the way a repository is technically
>>> *reached*. This is mainly because this way may be different on other
>>> machines. Maybe we can introduce additional URI formats for resources
>>> that are URIConverter'ed to the primary format after extracting
>>> connection infos...
>> I love this idea. I've been struggling in maintaining in our products
>> a CDO URI translator facade, as we needed URIs meaninful to end users.
>> I think the URIConverter approach perfectly fit this requirement.
>> Should we raise a zilla?
>>
>> Cheers,
>> ViK.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 04:28:29 GMT 2024
Powered by FUDForum. Page generated in 0.04035 seconds |
] 
Search
Help
Register
Login
Home
