Home » Modeling » EMF » advanced proxy resolution
|
| Re: advanced proxy resolution [message #424294 is a reply to message #424292] |
Wed, 22 October 2008 12:20   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Knut,
Comments below.
Knut Wannheden wrote:
> Hi,
>
> I would like to implement a proxy resolution strategy which attempts
> to resolve the proxy in multiple steps, much like Java will try to
> resolve a resource (or a class) against the ordered entries on the
> classpath and return on the first match. My question is now how to
> best do this in EMF using the resource API.
A classloader might do funkier things that just an ordered list of
entries...
>
> Let's assume I'm implementing an editor for a Java based scripting
> language where the language AST is backed by an EMF model. The
> references to other compilation units in the model instance for one
> compilation unit get initially created as proxies. So I might for
> instance have a CompilationUnit "A" with an "imports" reference (of
> type EList<CompilationUnit>) containing a CompilationUnit proxy object
> with URI "classpath:B".
I see. That sounds reasonable.
>
> I was thinking I would implement this multi-step proxy resolution in
> the normalize(URI) method of my custom URIConverter, which would then
> for every attempt (against the classpath entries) use the
> corresponding URIHandler (e.g. "file", "jar", or "platform") to check
> for existence and return the first normalized URI which exists.
So the idea is that you'd use a symbolic URI scheme, like perhaps
classpath:/org/example/Foo.extension? And you'd use normalization to
map this to a physical location URI. I suppose you might be able to
compute the normalization steps in the URI Map itself so you'd not have
to specialize the URI converter at all, just populate the map.
>
> Does this make sense?
An alternative might be to write a specialized URIHandlerImpl that
handles your specialized scheme so that any normalization behavior is
handled within your handler making it appear to suppose a real live URL
scheme. It's always possible to delegate back to the containing
URIHandler, as ArchiveURIHandlerImpl does...
>
> Thanks,
>
> --knut
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: advanced proxy resolution [message #424298 is a reply to message #424294] |
Wed, 22 October 2008 12:43 |
Knut Wannheden
Messages: 298
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Ed Merks wrote:
>
> Knut Wannheden wrote:
>> Hi,
>>
>> I would like to implement a proxy resolution strategy which attempts
>> to resolve the proxy in multiple steps, much like Java will try to
>> resolve a resource (or a class) against the ordered entries on the
>> classpath and return on the first match. My question is now how to
>> best do this in EMF using the resource API.
> A classloader might do funkier things that just an ordered list of
> entries...
True, so might I want to in the end :-) It was basically just a
convenient well-known example. Maybe I should have used the *nix PATH
instead :-)
> So the idea is that you'd use a symbolic URI scheme, like perhaps
> classpath:/org/example/Foo.extension? And you'd use normalization to
> map this to a physical location URI. I suppose you might be able to
> compute the normalization steps in the URI Map itself so you'd not have
> to specialize the URI converter at all, just populate the map.
Yes, I think a custom scheme like "classpath" seems reasonable.
I couldn't find a setter for URIMap on URIConverter. And since I can't
map a single URI prefix like classpath:/ to multiple values using the
default URIMap implementation I would still have to subclass
URIConverter to provide my own URIMap implementation in
getInternalURIMap(). But implementing the resolution strategy in
URIMap#getURI(URI) sounds a bit complicated. Or did I maybe
misunderstand you?
> An alternative might be to write a specialized URIHandlerImpl that
> handles your specialized scheme so that any normalization behavior is
> handled within your handler making it appear to suppose a real live URL
> scheme. It's always possible to delegate back to the containing
> URIHandler, as ArchiveURIHandlerImpl does...
You mean delegate back to the URIConverter, correct? That sounds like an
elegant solution. I assume I could also use the URIConverter#exists(URI,
Map) method before delegating back with the corresponding URI.
Thanks,
--knut
|
|
|
| Re: advanced proxy resolution [message #424299 is a reply to message #424298] |
Wed, 22 October 2008 13:00 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070604010200050704080909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Knut,
Comments below.
Knut Wannheden wrote:
> Hi Ed,
>
> Ed Merks wrote:
>>
>> Knut Wannheden wrote:
>>> Hi,
>>>
>>> I would like to implement a proxy resolution strategy which attempts
>>> to resolve the proxy in multiple steps, much like Java will try to
>>> resolve a resource (or a class) against the ordered entries on the
>>> classpath and return on the first match. My question is now how to
>>> best do this in EMF using the resource API.
>> A classloader might do funkier things that just an ordered list of
>> entries...
>
> True, so might I want to in the end :-) It was basically just a
> convenient well-known example. Maybe I should have used the *nix PATH
> instead :-)
>
>> So the idea is that you'd use a symbolic URI scheme, like perhaps
>> classpath:/org/example/Foo.extension? And you'd use normalization to
>> map this to a physical location URI. I suppose you might be able to
>> compute the normalization steps in the URI Map itself so you'd not
>> have to specialize the URI converter at all, just populate the map.
>
> Yes, I think a custom scheme like "classpath" seems reasonable.
>
> I couldn't find a setter for URIMap on URIConverter.
You'd just update the map that's there.
> And since I can't map a single URI prefix like classpath:/ to multiple
> values using the default URIMap implementation I would still have to
> subclass URIConverter to provide my own URIMap implementation in
> getInternalURIMap(). But implementing the resolution strategy in
> URIMap#getURI(URI) sounds a bit complicated. Or did I maybe
> misunderstand you?
I imagine you'd remap various branches, not just the root. The prefix
remapping will remap the longest path prefixes first. I.e., I expect
you'd probably know which packages are located where...
>
>> An alternative might be to write a specialized URIHandlerImpl that
>> handles your specialized scheme so that any normalization behavior is
>> handled within your handler making it appear to suppose a real live
>> URL scheme. It's always possible to delegate back to the containing
>> URIHandler, as ArchiveURIHandlerImpl does...
>
> You mean delegate back to the URIConverter, correct?
Yes, sorry.
> That sounds like an elegant solution.
I think so.
> I assume I could also use the URIConverter#exists(URI, Map) method
> before delegating back with the corresponding URI.
Yes, definitely. Note that there's a helper method for getting the
delegating URIConverter from the options and the URIConverter will
always pass in non-null options that contain a reference to itself.
/**
* Returns the value of the {@link
URIConverter#OPTION_URI_CONVERTER URI converter option}.
* @param options the options in which to look for the URI converter.
* @return the value of the URI converter option.
*/
protected URIConverter getURIConverter(Map<?, ?> options)
{
return (URIConverter)options.get(URIConverter.OPTION_URI_CONVERTER) ;
}
>
> Thanks,
>
> --knut
--------------070604010200050704080909
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">
Knut,<br>
<br>
Comments below.<br>
<br>
<br>
Knut Wannheden wrote:
<blockquote cite="mid:gdn76b$kp4$1@build.eclipse.org" type="cite">Hi
Ed,
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite"><br>
Knut Wannheden wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I would like to implement a proxy resolution strategy which attempts to
resolve the proxy in multiple steps, much like Java will try to resolve
a resource (or a class) against the ordered entries on the classpath
and return on the first match. My question is now how to best do this
in EMF using the resource API.
<br>
</blockquote>
A classloader might do funkier things that just an ordered list of
entries...
<br>
</blockquote>
<br>
True, so might I want to in the end :-) It was basically just a
convenient well-known example. Maybe I should have used the *nix PATH
instead :-)
<br>
<br>
<blockquote type="cite">So the idea is that you'd use a symbolic URI
scheme, like perhaps classpath:/org/example/Foo.extension? And you'd
use normalization to map this to a physical location URI. I suppose
you might be able to compute the normalization steps in the URI Map
itself so you'd not have to specialize the URI converter at all, just
populate the map.
<br>
</blockquote>
<br>
Yes, I think a custom scheme like "classpath" seems reasonable.
<br>
<br>
I couldn't find a setter for URIMap on URIConverter.</blockquote>
You'd just update the map that's there.<br>
<blockquote cite="mid:gdn76b$kp4$1@build.eclipse.org" type="cite"> And
since I can't map a single URI prefix like classpath:/ to multiple
values using the default URIMap implementation I would still have to
subclass URIConverter to provide my own URIMap implementation in
getInternalURIMap(). But implementing the resolution strategy in
URIMap#getURI(URI) sounds a bit complicated. Or did I maybe
misunderstand you?
<br>
</blockquote>
I imagine you'd remap various branches, not just the root. The prefix
remapping will remap the longest path prefixes first. I.e., I expect
you'd probably know which packages are located where...<br>
<blockquote cite="mid:gdn76b$kp4$1@build.eclipse.org" type="cite"><br>
<blockquote type="cite">An alternative might be to write a
specialized URIHandlerImpl that handles your specialized scheme so that
any normalization behavior is handled within your handler making it
appear to suppose a real live URL scheme. It's always possible to
delegate back to the containing URIHandler, as ArchiveURIHandlerImpl
does...
<br>
</blockquote>
<br>
You mean delegate back to the URIConverter, correct?</blockquote>
Yes, sorry.<br>
<blockquote cite="mid:gdn76b$kp4$1@build.eclipse.org" type="cite"> That
sounds like an elegant solution.</blockquote>
I think so.<br>
<blockquote cite="mid:gdn76b$kp4$1@build.eclipse.org" type="cite"> I
assume I could also use the URIConverter#exists(URI, Map) method before
delegating back with the corresponding URI.
<br>
</blockquote>
Yes, definitely. Note that there's a helper method for getting the
delegating URIConverter from the options and the URIConverter will
always pass in non-null options that contain a reference to itself.<br>
<blockquote><small> /**<br>
* Returns the value of the {@link URIConverter#OPTION_URI_CONVERTER
URI converter option}.<br>
* @param options the options in which to look for the URI converter.<br>
* @return the value of the URI converter option.<br>
*/<br>
protected URIConverter getURIConverter(Map<?, ?> options)<br>
{<br>
return (URIConverter)options.get(URIConverter.OPTION_URI_CONVERTER) ; <br>
}</small><br>
</blockquote>
<blockquote cite="mid:gdn76b$kp4$1@build.eclipse.org" type="cite"><br>
Thanks,
<br>
<br>
--knut
<br>
</blockquote>
</body>
</html>
--------------070604010200050704080909--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 21:19:53 GMT 2024
Powered by FUDForum. Page generated in 0.03269 seconds |
] 
Search
Help
Register
Login
Home
