[jira] Created: (TAPESTRY-2519) Make ClassNameLocatorImpl resolve resources from URLs that use a client-defined protocol

[Tapestry - Dev mailing list]

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tapestry - Dev mailing list]

    [ 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tapestry - Dev mailing list]

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

Igor Drobiazko commented on TAPESTRY-2519:
------------------------------------------

What exactly do you mean?

> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tapestry - Dev mailing list]

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

Massimo Lusetti commented on TAPESTRY-2519:
-------------------------------------------

I ask if this modifications could be used as bridge for spring integration too instead of the current way, which is the implementation of ModuleDef[] provideExtraModuleDefs(ServletContext context) inside the TapestrySpringFilter.

Regards.

> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tapestry - Dev mailing list]

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

Igor Drobiazko commented on TAPESTRY-2519:
------------------------------------------

Nope, this modification is supposed to be resolve classes whose URLs are different from those Tapestry  is able to resolve. That's all. ModuleDef on its part is responsible for embedding services into Tapestry that are binded outside the AppModule. Since in OSGi we also have a bunch of service we may contribute the OSGi services to Tapestry by using the ModuleDefs.

> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tapestry - Dev mailing list]

    [ 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tapestry - Dev mailing list]

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

Igor Drobiazko commented on TAPESTRY-2519:
------------------------------------------

If the converter is not able to convert it should return the original url. The osgi converter would convert the url into native jar or file urls. We could also allow the converter to be chained. In this case returning of  null would make sense. This way the next converter in the chain could try to convert. By default Tapestry would put only one converter into this chain.

ClassNameLocator is already a service. It is absolutely no problem to override it. The problem is how to do it. The new implementation of ClassNameLocator will need the most code of the original implementation. Only a small part needs to be overridden. So it makes sense to extend ClassNameLocatorImpl and replace it.The problem is that ClassNameLocatorImpl was not designed for extension. It is not possible to extend it by overriding one of the methods.  That's why I suggested to use the converter service.

> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tapestry - Dev mailing list]

     [ https://issues.apache.org/jira/browse/TAPESTRY-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship reassigned TAPESTRY-2519:
----------------------------------------------

    Assignee: Howard M. Lewis Ship  (was: Igor Drobiazko)

> 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: Howard M. Lewis Ship
>
> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tapestry - Dev mailing list]

     [ https://issues.apache.org/jira/browse/TAPESTRY-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAPESTRY-2519.
------------------------------------------

       Resolution: Fixed
    Fix Version/s: 5.0.14

> 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: Howard M. Lewis Ship
>             Fix For: 5.0.14
>
>
> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...