[
https://issues.apache.org/jira/browse/TAPESTRY-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613886#action_12613886
]
Massimo Lusetti commented on TAPESTRY-2519:
-------------------------------------------
Does this could affect the way tapestry-spring is made?
> 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]
