[ 
https://issues.apache.org/jira/browse/TAPESTRY-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615813#action_12615813
 ] 

Howard M. Lewis Ship commented on TAPESTRY-2519:
------------------------------------------------

So, does convert() return null if it can't convert?  I do like the idea of 
splitting the logic up a little bit.  It's also looking like ClassNameLocator 
should become a service, rather than a utility, to support overrides and 
decoration.  Can you document what convert() is exactly supposed to do?  
Convert from a OSGi bundle URL to a native jar: or file: URL?

> Make ClassNameLocatorImpl resolve resources from URLs that use a 
> client-defined protocol
> ----------------------------------------------------------------------------------------
>
>                 Key: TAPESTRY-2519
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2519
>             Project: Tapestry
>          Issue Type: Improvement
>    Affects Versions: 5.0.14
>            Reporter: Igor Drobiazko
>            Assignee: Igor Drobiazko
>
> ClassNameLocatorImpl is only able to resolve resources from URLs that use a 
> protocol which is native to the Java class library (file, jar, http, etc). In 
> OSGi environment all the URLs use the protocol "bundleresource" or 
> "bundleentry". Here is an example:
> bundleresource://5642/org/apache/tapestry5/corelib/pages/
> A very simple solution is to create your own ClassNameLocator and contribute 
> it to AliasOverrides. Well, this solution is bad because it requires a copy 
> of the ClassNameLocatorImpl.
> A better solution would be to make ClassNameLocatorImpl use a service called 
> URLConverter or similar.
> public interface URLConverter
> {
>     URL convert(URL url);
> }
> Tapestry would provide a default implementation of the interface:
> public class URLConverterImpl implements URLConverter
> {
>     public URL convert(URL url)
>     {
>         return url;
>     }
> }
> In an OSGi environment (in my case Equinox)  one could override this service 
> by using e.g Eclipse Core API. This approach is much easier then overriding 
> of the ClassNameLocator.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to