You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Reto Bachmann-Gmür <re...@apache.org> on 2012/11/21 12:44:13 UTC
Changes to get rid of jersey dependencies
Hi
I've commited quite massive changes under
STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
.
While Viewable and pojo based freemarker Readme should be dropped in favor
of LdViewables I've added a near-drop in replacement for the jersey
Viewable. The new Viewable no longer relies on the template being located
using WebFragment.getTemplateLoader() which is no longer called (but not
yet removed) instead the templates are expected to be in a folder named
"templates" in any bundle. To support different templates for different
target media types the templates are located in templates/html. templates
imported in other templates are located directivity in templates as some
snippets may have to be rendered in the same way for different target media
types.
There re some remaining imports of com.sun.jersey packages in some of the
modules. Namely:
Unproblematic I think:
- com.sun.jersey.api.client.*: I Think the client API is no problem
Need replacement if jersey doesn't offer them in a Jax-RS implementation
independent way:
- com.sun.jersey.multipart.BodyPart
- com.sun.jersey.multipart.FormDataBodyPart
- com.sun.jersey.multipart.FormDataParam
- com.sun.jersey.multipart.FormDataMultiPart
- com.sun.jersey.core.util.MultivaluedMapImpl
Not sure what they are for:
- com.sun.jersey.core.header.FormDataContentDisposition
- com.sun.jersey.spi.resource.Singleton
- com.sun.jersey.core.header.FormDataContentDisposition
- com.sun.jersey.api.view.ImplicitProduces
- com.sun.jersey.spi.resource.Singleton
- com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
- com.sun.jersey.api.representation.Form
- com.sun.jersey.api.core.HttpContext
- com.sun.jersey.api.core.HttpRequestContext;
Especially if you introduced code that uses one of the classes in the last
category it would be good if you could have a look at it an either change
the code to use standard jax-rs classes or describe what they do and what
you need them for.
Cheers,
Reto
Re: Changes to get rid of jersey dependencies
Posted by Rupert Westenthaler <ru...@gmail.com>.
yes this was the wrong thread ... sorry ... no change to the
contentitem.ftl. AFAIK this is duplicated to avoid a dependency
between the enhancer and the contenthub.
best
Rupert
On Mon, Nov 26, 2012 at 7:53 PM, Reto Bachmann-Gmür <re...@wymiwyg.com> wrote:
> Glad to hear, also this seems t have been the wrong thread. Or the wrong
> pathc link as I see no reference to the duplicate contentitem.ftl there.
>
> Cheers,
> Reto
>
> On Mon, Nov 26, 2012 at 4:43 PM, Rupert Westenthaler <
> rupert.westenthaler@gmail.com> wrote:
>
>> Hi all
>>
>> with http://svn.apache.org/viewvc?rev=1413674&view=rev the trunk
>> should be fixed.
>>
>> best
>> Rupert
>>
>> On Sat, Nov 24, 2012 at 4:41 PM, Reto Bachmann-Gmür <re...@apache.org>
>> wrote:
>> > Hi Rupert,
>> >
>> > I see two templates by that name in the source:
>> >
>> > ./contenthub/web/target/classes/templates/imports/contentitem.ftl
>> > ./enhancer/jersey/src/main/resources/templates/imports/contentitem.ftl
>> >
>> > The two templates seem to differ only by a bit of formatting and they are
>> > registered at the same location where they should be included with
>> > <#include "/imports/contentitem">.
>> >
>> > Furthermore I see:
>> >
>> >
>> ./enhancer/jersey/src/main/resources/org/apache/stanbol/enhancer/jersey/templates/ajax/contentitem.ftl
>> >
>> > At that location it is not accessible to the templating system.
>> > I couldn't find an include for ajax/contentitem, the root for includes is
>> > the templates folder (not templates/html so to allow to include other
>> media
>> > types). From the error message I now moved the file to be where its is
>> > expected, verified with
>> >
>> > zz>val b = bundleContext.getBundle(28)
>> > b: org.osgi.framework.Bundle = org.apache.stanbol.enhancer.jersey [28]
>> >
>> zz>b.getResource("templates/html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem.ftl")
>> > res3: java.net.URL =
>> >
>> bundle://28.3:1/templates/html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem.ftl
>> >
>> > The error is gone now.
>> >
>> > Cheers,
>> > Reto
>> >
>> > On Sat, Nov 24, 2012 at 1:22 PM, Rupert Westenthaler <
>> > rupert.westenthaler@gmail.com> wrote:
>> >
>> >> Hi Reto,
>> >>
>> >> I think I discovered an other issue with the new template loading
>> >> mechanism while re-integrating the stanbol-nlp-proessing brach.
>> >> However also a test on the current trunk shows the same issue.
>> >>
>> >> When I post an Request to the Stanbol Enhancer via the Web UI I do get
>> >> an "Invalid query" because of
>> >>
>> >> 24.11.2012 13:17:17.994 *WARN* [1346380557@qtp-2082765220-174]
>> >> org.apache.felix.http.jetty /enhancer (java.lang.RuntimeException:
>> >> java.io.FileNotFoundException: Template
>> >>
>> >>
>> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
>> >> not found.) java.lang.RuntimeException: java.io.FileNotFoundException:
>> >> Template
>> >>
>> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
>> >> not found.
>> >> at
>> >>
>> org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:173)
>> >> at
>> >>
>> org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:80)
>> >> at
>> >>
>> org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:53)
>> >> [..]
>> >> Caused by: java.io.FileNotFoundException: Template
>> >>
>> >>
>> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
>> >> not found.
>> >> at freemarker.template.Configuration.getTemplate(Configuration.java:580)
>> >> at freemarker.template.Configuration.getTemplate(Configuration.java:543)
>> >> at
>> >>
>> org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:169)
>> >> ... 48 more
>> >>
>> >> I think this is because all the imports are still in the old location.
>> >> Can you please have a look at this. How do import work with the new
>> >> infrastructure?
>> >>
>> >> best
>> >> Rupert
>> >>
>> >> On Fri, Nov 23, 2012 at 12:00 PM, Andrea Di Menna <ni...@gmail.com>
>> >> wrote:
>> >> > Looks like someone else noticed ;-)
>> >> >
>> >> > https://issues.apache.org/jira/browse/STANBOL-814
>> >> >
>> >> > Andrea
>> >> >
>> >> > 2012/11/23 Reto Bachmann-Gmür <re...@apache.org>:
>> >> >> Indeed stanbol.css disappeared from the sources! Investigating what
>> >> >> happened.
>> >> >>
>> >> >> Thanks for noticing this!
>> >> >>
>> >> >> Reto
>> >> >>
>> >> >> On Fri, Nov 23, 2012 at 8:46 AM, Rupert Westenthaler <
>> >> >> rupert.westenthaler@gmail.com> wrote:
>> >> >>
>> >> >>> Hi Reto,
>> >> >>>
>> >> >>> might it be the case that your changes have broken the CSS for
>> Stanbol.
>> >> >>>
>> >> >>> Just recognized it on http://dev.iks-project.eu:8080 and
>> >> >>> http://dev.iks-project.eu:8081 as those Server do use nightly
>> builds
>> >> >>>
>> >> >>> best
>> >> >>> Rupert
>> >> >>>
>> >> >>> On Wed, Nov 21, 2012 at 12:44 PM, Reto Bachmann-Gmür <
>> reto@apache.org>
>> >> >>> wrote:
>> >> >>> > Hi
>> >> >>> >
>> >> >>> > I've commited quite massive changes under
>> >> >>> > STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
>> >> >>> > .
>> >> >>> >
>> >> >>> > While Viewable and pojo based freemarker Readme should be dropped
>> in
>> >> >>> favor
>> >> >>> > of LdViewables I've added a near-drop in replacement for the
>> jersey
>> >> >>> > Viewable. The new Viewable no longer relies on the template being
>> >> located
>> >> >>> > using WebFragment.getTemplateLoader() which is no longer called
>> (but
>> >> not
>> >> >>> > yet removed) instead the templates are expected to be in a folder
>> >> named
>> >> >>> > "templates" in any bundle. To support different templates for
>> >> different
>> >> >>> > target media types the templates are located in templates/html.
>> >> templates
>> >> >>> > imported in other templates are located directivity in templates
>> as
>> >> some
>> >> >>> > snippets may have to be rendered in the same way for different
>> target
>> >> >>> media
>> >> >>> > types.
>> >> >>> >
>> >> >>> > There re some remaining imports of com.sun.jersey packages in some
>> >> of the
>> >> >>> > modules. Namely:
>> >> >>> >
>> >> >>> > Unproblematic I think:
>> >> >>> > - com.sun.jersey.api.client.*: I Think the client API is no
>> problem
>> >> >>> >
>> >> >>> > Need replacement if jersey doesn't offer them in a Jax-RS
>> >> implementation
>> >> >>> > independent way:
>> >> >>> > - com.sun.jersey.multipart.BodyPart
>> >> >>> > - com.sun.jersey.multipart.FormDataBodyPart
>> >> >>> > - com.sun.jersey.multipart.FormDataParam
>> >> >>> > - com.sun.jersey.multipart.FormDataMultiPart
>> >> >>> > - com.sun.jersey.core.util.MultivaluedMapImpl
>> >> >>> >
>> >> >>> > Not sure what they are for:
>> >> >>> > - com.sun.jersey.core.header.FormDataContentDisposition
>> >> >>> > - com.sun.jersey.spi.resource.Singleton
>> >> >>> > - com.sun.jersey.core.header.FormDataContentDisposition
>> >> >>> > - com.sun.jersey.api.view.ImplicitProduces
>> >> >>> > - com.sun.jersey.spi.resource.Singleton
>> >> >>> > - com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
>> >> >>> > - com.sun.jersey.api.representation.Form
>> >> >>> > - com.sun.jersey.api.core.HttpContext
>> >> >>> > - com.sun.jersey.api.core.HttpRequestContext;
>> >> >>> >
>> >> >>> >
>> >> >>> > Especially if you introduced code that uses one of the classes in
>> the
>> >> >>> last
>> >> >>> > category it would be good if you could have a look at it an either
>> >> change
>> >> >>> > the code to use standard jax-rs classes or describe what they do
>> and
>> >> what
>> >> >>> > you need them for.
>> >> >>> >
>> >> >>> > Cheers,
>> >> >>> > Reto
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> >> >>> | Bodenlehenstraße 11 ++43-699-11108907
>> >> >>> | A-5500 Bischofshofen
>> >> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> >> | Bodenlehenstraße 11 ++43-699-11108907
>> >> | A-5500 Bischofshofen
>> >>
>>
>>
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Changes to get rid of jersey dependencies
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
Glad to hear, also this seems t have been the wrong thread. Or the wrong
pathc link as I see no reference to the duplicate contentitem.ftl there.
Cheers,
Reto
On Mon, Nov 26, 2012 at 4:43 PM, Rupert Westenthaler <
rupert.westenthaler@gmail.com> wrote:
> Hi all
>
> with http://svn.apache.org/viewvc?rev=1413674&view=rev the trunk
> should be fixed.
>
> best
> Rupert
>
> On Sat, Nov 24, 2012 at 4:41 PM, Reto Bachmann-Gmür <re...@apache.org>
> wrote:
> > Hi Rupert,
> >
> > I see two templates by that name in the source:
> >
> > ./contenthub/web/target/classes/templates/imports/contentitem.ftl
> > ./enhancer/jersey/src/main/resources/templates/imports/contentitem.ftl
> >
> > The two templates seem to differ only by a bit of formatting and they are
> > registered at the same location where they should be included with
> > <#include "/imports/contentitem">.
> >
> > Furthermore I see:
> >
> >
> ./enhancer/jersey/src/main/resources/org/apache/stanbol/enhancer/jersey/templates/ajax/contentitem.ftl
> >
> > At that location it is not accessible to the templating system.
> > I couldn't find an include for ajax/contentitem, the root for includes is
> > the templates folder (not templates/html so to allow to include other
> media
> > types). From the error message I now moved the file to be where its is
> > expected, verified with
> >
> > zz>val b = bundleContext.getBundle(28)
> > b: org.osgi.framework.Bundle = org.apache.stanbol.enhancer.jersey [28]
> >
> zz>b.getResource("templates/html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem.ftl")
> > res3: java.net.URL =
> >
> bundle://28.3:1/templates/html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem.ftl
> >
> > The error is gone now.
> >
> > Cheers,
> > Reto
> >
> > On Sat, Nov 24, 2012 at 1:22 PM, Rupert Westenthaler <
> > rupert.westenthaler@gmail.com> wrote:
> >
> >> Hi Reto,
> >>
> >> I think I discovered an other issue with the new template loading
> >> mechanism while re-integrating the stanbol-nlp-proessing brach.
> >> However also a test on the current trunk shows the same issue.
> >>
> >> When I post an Request to the Stanbol Enhancer via the Web UI I do get
> >> an "Invalid query" because of
> >>
> >> 24.11.2012 13:17:17.994 *WARN* [1346380557@qtp-2082765220-174]
> >> org.apache.felix.http.jetty /enhancer (java.lang.RuntimeException:
> >> java.io.FileNotFoundException: Template
> >>
> >>
> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
> >> not found.) java.lang.RuntimeException: java.io.FileNotFoundException:
> >> Template
> >>
> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
> >> not found.
> >> at
> >>
> org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:173)
> >> at
> >>
> org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:80)
> >> at
> >>
> org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:53)
> >> [..]
> >> Caused by: java.io.FileNotFoundException: Template
> >>
> >>
> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
> >> not found.
> >> at freemarker.template.Configuration.getTemplate(Configuration.java:580)
> >> at freemarker.template.Configuration.getTemplate(Configuration.java:543)
> >> at
> >>
> org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:169)
> >> ... 48 more
> >>
> >> I think this is because all the imports are still in the old location.
> >> Can you please have a look at this. How do import work with the new
> >> infrastructure?
> >>
> >> best
> >> Rupert
> >>
> >> On Fri, Nov 23, 2012 at 12:00 PM, Andrea Di Menna <ni...@gmail.com>
> >> wrote:
> >> > Looks like someone else noticed ;-)
> >> >
> >> > https://issues.apache.org/jira/browse/STANBOL-814
> >> >
> >> > Andrea
> >> >
> >> > 2012/11/23 Reto Bachmann-Gmür <re...@apache.org>:
> >> >> Indeed stanbol.css disappeared from the sources! Investigating what
> >> >> happened.
> >> >>
> >> >> Thanks for noticing this!
> >> >>
> >> >> Reto
> >> >>
> >> >> On Fri, Nov 23, 2012 at 8:46 AM, Rupert Westenthaler <
> >> >> rupert.westenthaler@gmail.com> wrote:
> >> >>
> >> >>> Hi Reto,
> >> >>>
> >> >>> might it be the case that your changes have broken the CSS for
> Stanbol.
> >> >>>
> >> >>> Just recognized it on http://dev.iks-project.eu:8080 and
> >> >>> http://dev.iks-project.eu:8081 as those Server do use nightly
> builds
> >> >>>
> >> >>> best
> >> >>> Rupert
> >> >>>
> >> >>> On Wed, Nov 21, 2012 at 12:44 PM, Reto Bachmann-Gmür <
> reto@apache.org>
> >> >>> wrote:
> >> >>> > Hi
> >> >>> >
> >> >>> > I've commited quite massive changes under
> >> >>> > STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
> >> >>> > .
> >> >>> >
> >> >>> > While Viewable and pojo based freemarker Readme should be dropped
> in
> >> >>> favor
> >> >>> > of LdViewables I've added a near-drop in replacement for the
> jersey
> >> >>> > Viewable. The new Viewable no longer relies on the template being
> >> located
> >> >>> > using WebFragment.getTemplateLoader() which is no longer called
> (but
> >> not
> >> >>> > yet removed) instead the templates are expected to be in a folder
> >> named
> >> >>> > "templates" in any bundle. To support different templates for
> >> different
> >> >>> > target media types the templates are located in templates/html.
> >> templates
> >> >>> > imported in other templates are located directivity in templates
> as
> >> some
> >> >>> > snippets may have to be rendered in the same way for different
> target
> >> >>> media
> >> >>> > types.
> >> >>> >
> >> >>> > There re some remaining imports of com.sun.jersey packages in some
> >> of the
> >> >>> > modules. Namely:
> >> >>> >
> >> >>> > Unproblematic I think:
> >> >>> > - com.sun.jersey.api.client.*: I Think the client API is no
> problem
> >> >>> >
> >> >>> > Need replacement if jersey doesn't offer them in a Jax-RS
> >> implementation
> >> >>> > independent way:
> >> >>> > - com.sun.jersey.multipart.BodyPart
> >> >>> > - com.sun.jersey.multipart.FormDataBodyPart
> >> >>> > - com.sun.jersey.multipart.FormDataParam
> >> >>> > - com.sun.jersey.multipart.FormDataMultiPart
> >> >>> > - com.sun.jersey.core.util.MultivaluedMapImpl
> >> >>> >
> >> >>> > Not sure what they are for:
> >> >>> > - com.sun.jersey.core.header.FormDataContentDisposition
> >> >>> > - com.sun.jersey.spi.resource.Singleton
> >> >>> > - com.sun.jersey.core.header.FormDataContentDisposition
> >> >>> > - com.sun.jersey.api.view.ImplicitProduces
> >> >>> > - com.sun.jersey.spi.resource.Singleton
> >> >>> > - com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
> >> >>> > - com.sun.jersey.api.representation.Form
> >> >>> > - com.sun.jersey.api.core.HttpContext
> >> >>> > - com.sun.jersey.api.core.HttpRequestContext;
> >> >>> >
> >> >>> >
> >> >>> > Especially if you introduced code that uses one of the classes in
> the
> >> >>> last
> >> >>> > category it would be good if you could have a look at it an either
> >> change
> >> >>> > the code to use standard jax-rs classes or describe what they do
> and
> >> what
> >> >>> > you need them for.
> >> >>> >
> >> >>> > Cheers,
> >> >>> > Reto
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> | Rupert Westenthaler rupert.westenthaler@gmail.com
> >> >>> | Bodenlehenstraße 11 ++43-699-11108907
> >> >>> | A-5500 Bischofshofen
> >> >>>
> >>
> >>
> >>
> >> --
> >> | Rupert Westenthaler rupert.westenthaler@gmail.com
> >> | Bodenlehenstraße 11 ++43-699-11108907
> >> | A-5500 Bischofshofen
> >>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
Re: Changes to get rid of jersey dependencies
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi all
with http://svn.apache.org/viewvc?rev=1413674&view=rev the trunk
should be fixed.
best
Rupert
On Sat, Nov 24, 2012 at 4:41 PM, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Hi Rupert,
>
> I see two templates by that name in the source:
>
> ./contenthub/web/target/classes/templates/imports/contentitem.ftl
> ./enhancer/jersey/src/main/resources/templates/imports/contentitem.ftl
>
> The two templates seem to differ only by a bit of formatting and they are
> registered at the same location where they should be included with
> <#include "/imports/contentitem">.
>
> Furthermore I see:
>
> ./enhancer/jersey/src/main/resources/org/apache/stanbol/enhancer/jersey/templates/ajax/contentitem.ftl
>
> At that location it is not accessible to the templating system.
> I couldn't find an include for ajax/contentitem, the root for includes is
> the templates folder (not templates/html so to allow to include other media
> types). From the error message I now moved the file to be where its is
> expected, verified with
>
> zz>val b = bundleContext.getBundle(28)
> b: org.osgi.framework.Bundle = org.apache.stanbol.enhancer.jersey [28]
> zz>b.getResource("templates/html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem.ftl")
> res3: java.net.URL =
> bundle://28.3:1/templates/html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem.ftl
>
> The error is gone now.
>
> Cheers,
> Reto
>
> On Sat, Nov 24, 2012 at 1:22 PM, Rupert Westenthaler <
> rupert.westenthaler@gmail.com> wrote:
>
>> Hi Reto,
>>
>> I think I discovered an other issue with the new template loading
>> mechanism while re-integrating the stanbol-nlp-proessing brach.
>> However also a test on the current trunk shows the same issue.
>>
>> When I post an Request to the Stanbol Enhancer via the Web UI I do get
>> an "Invalid query" because of
>>
>> 24.11.2012 13:17:17.994 *WARN* [1346380557@qtp-2082765220-174]
>> org.apache.felix.http.jetty /enhancer (java.lang.RuntimeException:
>> java.io.FileNotFoundException: Template
>>
>> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
>> not found.) java.lang.RuntimeException: java.io.FileNotFoundException:
>> Template
>> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
>> not found.
>> at
>> org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:173)
>> at
>> org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:80)
>> at
>> org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:53)
>> [..]
>> Caused by: java.io.FileNotFoundException: Template
>>
>> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
>> not found.
>> at freemarker.template.Configuration.getTemplate(Configuration.java:580)
>> at freemarker.template.Configuration.getTemplate(Configuration.java:543)
>> at
>> org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:169)
>> ... 48 more
>>
>> I think this is because all the imports are still in the old location.
>> Can you please have a look at this. How do import work with the new
>> infrastructure?
>>
>> best
>> Rupert
>>
>> On Fri, Nov 23, 2012 at 12:00 PM, Andrea Di Menna <ni...@gmail.com>
>> wrote:
>> > Looks like someone else noticed ;-)
>> >
>> > https://issues.apache.org/jira/browse/STANBOL-814
>> >
>> > Andrea
>> >
>> > 2012/11/23 Reto Bachmann-Gmür <re...@apache.org>:
>> >> Indeed stanbol.css disappeared from the sources! Investigating what
>> >> happened.
>> >>
>> >> Thanks for noticing this!
>> >>
>> >> Reto
>> >>
>> >> On Fri, Nov 23, 2012 at 8:46 AM, Rupert Westenthaler <
>> >> rupert.westenthaler@gmail.com> wrote:
>> >>
>> >>> Hi Reto,
>> >>>
>> >>> might it be the case that your changes have broken the CSS for Stanbol.
>> >>>
>> >>> Just recognized it on http://dev.iks-project.eu:8080 and
>> >>> http://dev.iks-project.eu:8081 as those Server do use nightly builds
>> >>>
>> >>> best
>> >>> Rupert
>> >>>
>> >>> On Wed, Nov 21, 2012 at 12:44 PM, Reto Bachmann-Gmür <re...@apache.org>
>> >>> wrote:
>> >>> > Hi
>> >>> >
>> >>> > I've commited quite massive changes under
>> >>> > STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
>> >>> > .
>> >>> >
>> >>> > While Viewable and pojo based freemarker Readme should be dropped in
>> >>> favor
>> >>> > of LdViewables I've added a near-drop in replacement for the jersey
>> >>> > Viewable. The new Viewable no longer relies on the template being
>> located
>> >>> > using WebFragment.getTemplateLoader() which is no longer called (but
>> not
>> >>> > yet removed) instead the templates are expected to be in a folder
>> named
>> >>> > "templates" in any bundle. To support different templates for
>> different
>> >>> > target media types the templates are located in templates/html.
>> templates
>> >>> > imported in other templates are located directivity in templates as
>> some
>> >>> > snippets may have to be rendered in the same way for different target
>> >>> media
>> >>> > types.
>> >>> >
>> >>> > There re some remaining imports of com.sun.jersey packages in some
>> of the
>> >>> > modules. Namely:
>> >>> >
>> >>> > Unproblematic I think:
>> >>> > - com.sun.jersey.api.client.*: I Think the client API is no problem
>> >>> >
>> >>> > Need replacement if jersey doesn't offer them in a Jax-RS
>> implementation
>> >>> > independent way:
>> >>> > - com.sun.jersey.multipart.BodyPart
>> >>> > - com.sun.jersey.multipart.FormDataBodyPart
>> >>> > - com.sun.jersey.multipart.FormDataParam
>> >>> > - com.sun.jersey.multipart.FormDataMultiPart
>> >>> > - com.sun.jersey.core.util.MultivaluedMapImpl
>> >>> >
>> >>> > Not sure what they are for:
>> >>> > - com.sun.jersey.core.header.FormDataContentDisposition
>> >>> > - com.sun.jersey.spi.resource.Singleton
>> >>> > - com.sun.jersey.core.header.FormDataContentDisposition
>> >>> > - com.sun.jersey.api.view.ImplicitProduces
>> >>> > - com.sun.jersey.spi.resource.Singleton
>> >>> > - com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
>> >>> > - com.sun.jersey.api.representation.Form
>> >>> > - com.sun.jersey.api.core.HttpContext
>> >>> > - com.sun.jersey.api.core.HttpRequestContext;
>> >>> >
>> >>> >
>> >>> > Especially if you introduced code that uses one of the classes in the
>> >>> last
>> >>> > category it would be good if you could have a look at it an either
>> change
>> >>> > the code to use standard jax-rs classes or describe what they do and
>> what
>> >>> > you need them for.
>> >>> >
>> >>> > Cheers,
>> >>> > Reto
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> >>> | Bodenlehenstraße 11 ++43-699-11108907
>> >>> | A-5500 Bischofshofen
>> >>>
>>
>>
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Changes to get rid of jersey dependencies
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hi Rupert,
I see two templates by that name in the source:
./contenthub/web/target/classes/templates/imports/contentitem.ftl
./enhancer/jersey/src/main/resources/templates/imports/contentitem.ftl
The two templates seem to differ only by a bit of formatting and they are
registered at the same location where they should be included with
<#include "/imports/contentitem">.
Furthermore I see:
./enhancer/jersey/src/main/resources/org/apache/stanbol/enhancer/jersey/templates/ajax/contentitem.ftl
At that location it is not accessible to the templating system.
I couldn't find an include for ajax/contentitem, the root for includes is
the templates folder (not templates/html so to allow to include other media
types). From the error message I now moved the file to be where its is
expected, verified with
zz>val b = bundleContext.getBundle(28)
b: org.osgi.framework.Bundle = org.apache.stanbol.enhancer.jersey [28]
zz>b.getResource("templates/html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem.ftl")
res3: java.net.URL =
bundle://28.3:1/templates/html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem.ftl
The error is gone now.
Cheers,
Reto
On Sat, Nov 24, 2012 at 1:22 PM, Rupert Westenthaler <
rupert.westenthaler@gmail.com> wrote:
> Hi Reto,
>
> I think I discovered an other issue with the new template loading
> mechanism while re-integrating the stanbol-nlp-proessing brach.
> However also a test on the current trunk shows the same issue.
>
> When I post an Request to the Stanbol Enhancer via the Web UI I do get
> an "Invalid query" because of
>
> 24.11.2012 13:17:17.994 *WARN* [1346380557@qtp-2082765220-174]
> org.apache.felix.http.jetty /enhancer (java.lang.RuntimeException:
> java.io.FileNotFoundException: Template
>
> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
> not found.) java.lang.RuntimeException: java.io.FileNotFoundException:
> Template
> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
> not found.
> at
> org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:173)
> at
> org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:80)
> at
> org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:53)
> [..]
> Caused by: java.io.FileNotFoundException: Template
>
> html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
> not found.
> at freemarker.template.Configuration.getTemplate(Configuration.java:580)
> at freemarker.template.Configuration.getTemplate(Configuration.java:543)
> at
> org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:169)
> ... 48 more
>
> I think this is because all the imports are still in the old location.
> Can you please have a look at this. How do import work with the new
> infrastructure?
>
> best
> Rupert
>
> On Fri, Nov 23, 2012 at 12:00 PM, Andrea Di Menna <ni...@gmail.com>
> wrote:
> > Looks like someone else noticed ;-)
> >
> > https://issues.apache.org/jira/browse/STANBOL-814
> >
> > Andrea
> >
> > 2012/11/23 Reto Bachmann-Gmür <re...@apache.org>:
> >> Indeed stanbol.css disappeared from the sources! Investigating what
> >> happened.
> >>
> >> Thanks for noticing this!
> >>
> >> Reto
> >>
> >> On Fri, Nov 23, 2012 at 8:46 AM, Rupert Westenthaler <
> >> rupert.westenthaler@gmail.com> wrote:
> >>
> >>> Hi Reto,
> >>>
> >>> might it be the case that your changes have broken the CSS for Stanbol.
> >>>
> >>> Just recognized it on http://dev.iks-project.eu:8080 and
> >>> http://dev.iks-project.eu:8081 as those Server do use nightly builds
> >>>
> >>> best
> >>> Rupert
> >>>
> >>> On Wed, Nov 21, 2012 at 12:44 PM, Reto Bachmann-Gmür <re...@apache.org>
> >>> wrote:
> >>> > Hi
> >>> >
> >>> > I've commited quite massive changes under
> >>> > STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
> >>> > .
> >>> >
> >>> > While Viewable and pojo based freemarker Readme should be dropped in
> >>> favor
> >>> > of LdViewables I've added a near-drop in replacement for the jersey
> >>> > Viewable. The new Viewable no longer relies on the template being
> located
> >>> > using WebFragment.getTemplateLoader() which is no longer called (but
> not
> >>> > yet removed) instead the templates are expected to be in a folder
> named
> >>> > "templates" in any bundle. To support different templates for
> different
> >>> > target media types the templates are located in templates/html.
> templates
> >>> > imported in other templates are located directivity in templates as
> some
> >>> > snippets may have to be rendered in the same way for different target
> >>> media
> >>> > types.
> >>> >
> >>> > There re some remaining imports of com.sun.jersey packages in some
> of the
> >>> > modules. Namely:
> >>> >
> >>> > Unproblematic I think:
> >>> > - com.sun.jersey.api.client.*: I Think the client API is no problem
> >>> >
> >>> > Need replacement if jersey doesn't offer them in a Jax-RS
> implementation
> >>> > independent way:
> >>> > - com.sun.jersey.multipart.BodyPart
> >>> > - com.sun.jersey.multipart.FormDataBodyPart
> >>> > - com.sun.jersey.multipart.FormDataParam
> >>> > - com.sun.jersey.multipart.FormDataMultiPart
> >>> > - com.sun.jersey.core.util.MultivaluedMapImpl
> >>> >
> >>> > Not sure what they are for:
> >>> > - com.sun.jersey.core.header.FormDataContentDisposition
> >>> > - com.sun.jersey.spi.resource.Singleton
> >>> > - com.sun.jersey.core.header.FormDataContentDisposition
> >>> > - com.sun.jersey.api.view.ImplicitProduces
> >>> > - com.sun.jersey.spi.resource.Singleton
> >>> > - com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
> >>> > - com.sun.jersey.api.representation.Form
> >>> > - com.sun.jersey.api.core.HttpContext
> >>> > - com.sun.jersey.api.core.HttpRequestContext;
> >>> >
> >>> >
> >>> > Especially if you introduced code that uses one of the classes in the
> >>> last
> >>> > category it would be good if you could have a look at it an either
> change
> >>> > the code to use standard jax-rs classes or describe what they do and
> what
> >>> > you need them for.
> >>> >
> >>> > Cheers,
> >>> > Reto
> >>>
> >>>
> >>>
> >>> --
> >>> | Rupert Westenthaler rupert.westenthaler@gmail.com
> >>> | Bodenlehenstraße 11 ++43-699-11108907
> >>> | A-5500 Bischofshofen
> >>>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
Re: Changes to get rid of jersey dependencies
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Reto,
I think I discovered an other issue with the new template loading
mechanism while re-integrating the stanbol-nlp-proessing brach.
However also a test on the current trunk shows the same issue.
When I post an Request to the Stanbol Enhancer via the Web UI I do get
an "Invalid query" because of
24.11.2012 13:17:17.994 *WARN* [1346380557@qtp-2082765220-174]
org.apache.felix.http.jetty /enhancer (java.lang.RuntimeException:
java.io.FileNotFoundException: Template
html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
not found.) java.lang.RuntimeException: java.io.FileNotFoundException:
Template html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
not found.
at org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:173)
at org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:80)
at org.apache.stanbol.commons.ldviewable.mbw.ViewableWriter.writeTo(ViewableWriter.java:53)
[..]
Caused by: java.io.FileNotFoundException: Template
html/org/apache/stanbol/enhancer/jersey/resource/ContentItemResource/ajax/contentitem
not found.
at freemarker.template.Configuration.getTemplate(Configuration.java:580)
at freemarker.template.Configuration.getTemplate(Configuration.java:543)
at org.apache.stanbol.commons.ldpathtemplate.LdRenderer.renderPojo(LdRenderer.java:169)
... 48 more
I think this is because all the imports are still in the old location.
Can you please have a look at this. How do import work with the new
infrastructure?
best
Rupert
On Fri, Nov 23, 2012 at 12:00 PM, Andrea Di Menna <ni...@gmail.com> wrote:
> Looks like someone else noticed ;-)
>
> https://issues.apache.org/jira/browse/STANBOL-814
>
> Andrea
>
> 2012/11/23 Reto Bachmann-Gmür <re...@apache.org>:
>> Indeed stanbol.css disappeared from the sources! Investigating what
>> happened.
>>
>> Thanks for noticing this!
>>
>> Reto
>>
>> On Fri, Nov 23, 2012 at 8:46 AM, Rupert Westenthaler <
>> rupert.westenthaler@gmail.com> wrote:
>>
>>> Hi Reto,
>>>
>>> might it be the case that your changes have broken the CSS for Stanbol.
>>>
>>> Just recognized it on http://dev.iks-project.eu:8080 and
>>> http://dev.iks-project.eu:8081 as those Server do use nightly builds
>>>
>>> best
>>> Rupert
>>>
>>> On Wed, Nov 21, 2012 at 12:44 PM, Reto Bachmann-Gmür <re...@apache.org>
>>> wrote:
>>> > Hi
>>> >
>>> > I've commited quite massive changes under
>>> > STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
>>> > .
>>> >
>>> > While Viewable and pojo based freemarker Readme should be dropped in
>>> favor
>>> > of LdViewables I've added a near-drop in replacement for the jersey
>>> > Viewable. The new Viewable no longer relies on the template being located
>>> > using WebFragment.getTemplateLoader() which is no longer called (but not
>>> > yet removed) instead the templates are expected to be in a folder named
>>> > "templates" in any bundle. To support different templates for different
>>> > target media types the templates are located in templates/html. templates
>>> > imported in other templates are located directivity in templates as some
>>> > snippets may have to be rendered in the same way for different target
>>> media
>>> > types.
>>> >
>>> > There re some remaining imports of com.sun.jersey packages in some of the
>>> > modules. Namely:
>>> >
>>> > Unproblematic I think:
>>> > - com.sun.jersey.api.client.*: I Think the client API is no problem
>>> >
>>> > Need replacement if jersey doesn't offer them in a Jax-RS implementation
>>> > independent way:
>>> > - com.sun.jersey.multipart.BodyPart
>>> > - com.sun.jersey.multipart.FormDataBodyPart
>>> > - com.sun.jersey.multipart.FormDataParam
>>> > - com.sun.jersey.multipart.FormDataMultiPart
>>> > - com.sun.jersey.core.util.MultivaluedMapImpl
>>> >
>>> > Not sure what they are for:
>>> > - com.sun.jersey.core.header.FormDataContentDisposition
>>> > - com.sun.jersey.spi.resource.Singleton
>>> > - com.sun.jersey.core.header.FormDataContentDisposition
>>> > - com.sun.jersey.api.view.ImplicitProduces
>>> > - com.sun.jersey.spi.resource.Singleton
>>> > - com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
>>> > - com.sun.jersey.api.representation.Form
>>> > - com.sun.jersey.api.core.HttpContext
>>> > - com.sun.jersey.api.core.HttpRequestContext;
>>> >
>>> >
>>> > Especially if you introduced code that uses one of the classes in the
>>> last
>>> > category it would be good if you could have a look at it an either change
>>> > the code to use standard jax-rs classes or describe what they do and what
>>> > you need them for.
>>> >
>>> > Cheers,
>>> > Reto
>>>
>>>
>>>
>>> --
>>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>>>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Changes to get rid of jersey dependencies
Posted by Andrea Di Menna <ni...@gmail.com>.
Looks like someone else noticed ;-)
https://issues.apache.org/jira/browse/STANBOL-814
Andrea
2012/11/23 Reto Bachmann-Gmür <re...@apache.org>:
> Indeed stanbol.css disappeared from the sources! Investigating what
> happened.
>
> Thanks for noticing this!
>
> Reto
>
> On Fri, Nov 23, 2012 at 8:46 AM, Rupert Westenthaler <
> rupert.westenthaler@gmail.com> wrote:
>
>> Hi Reto,
>>
>> might it be the case that your changes have broken the CSS for Stanbol.
>>
>> Just recognized it on http://dev.iks-project.eu:8080 and
>> http://dev.iks-project.eu:8081 as those Server do use nightly builds
>>
>> best
>> Rupert
>>
>> On Wed, Nov 21, 2012 at 12:44 PM, Reto Bachmann-Gmür <re...@apache.org>
>> wrote:
>> > Hi
>> >
>> > I've commited quite massive changes under
>> > STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
>> > .
>> >
>> > While Viewable and pojo based freemarker Readme should be dropped in
>> favor
>> > of LdViewables I've added a near-drop in replacement for the jersey
>> > Viewable. The new Viewable no longer relies on the template being located
>> > using WebFragment.getTemplateLoader() which is no longer called (but not
>> > yet removed) instead the templates are expected to be in a folder named
>> > "templates" in any bundle. To support different templates for different
>> > target media types the templates are located in templates/html. templates
>> > imported in other templates are located directivity in templates as some
>> > snippets may have to be rendered in the same way for different target
>> media
>> > types.
>> >
>> > There re some remaining imports of com.sun.jersey packages in some of the
>> > modules. Namely:
>> >
>> > Unproblematic I think:
>> > - com.sun.jersey.api.client.*: I Think the client API is no problem
>> >
>> > Need replacement if jersey doesn't offer them in a Jax-RS implementation
>> > independent way:
>> > - com.sun.jersey.multipart.BodyPart
>> > - com.sun.jersey.multipart.FormDataBodyPart
>> > - com.sun.jersey.multipart.FormDataParam
>> > - com.sun.jersey.multipart.FormDataMultiPart
>> > - com.sun.jersey.core.util.MultivaluedMapImpl
>> >
>> > Not sure what they are for:
>> > - com.sun.jersey.core.header.FormDataContentDisposition
>> > - com.sun.jersey.spi.resource.Singleton
>> > - com.sun.jersey.core.header.FormDataContentDisposition
>> > - com.sun.jersey.api.view.ImplicitProduces
>> > - com.sun.jersey.spi.resource.Singleton
>> > - com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
>> > - com.sun.jersey.api.representation.Form
>> > - com.sun.jersey.api.core.HttpContext
>> > - com.sun.jersey.api.core.HttpRequestContext;
>> >
>> >
>> > Especially if you introduced code that uses one of the classes in the
>> last
>> > category it would be good if you could have a look at it an either change
>> > the code to use standard jax-rs classes or describe what they do and what
>> > you need them for.
>> >
>> > Cheers,
>> > Reto
>>
>>
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>>
Re: Changes to get rid of jersey dependencies
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Indeed stanbol.css disappeared from the sources! Investigating what
happened.
Thanks for noticing this!
Reto
On Fri, Nov 23, 2012 at 8:46 AM, Rupert Westenthaler <
rupert.westenthaler@gmail.com> wrote:
> Hi Reto,
>
> might it be the case that your changes have broken the CSS for Stanbol.
>
> Just recognized it on http://dev.iks-project.eu:8080 and
> http://dev.iks-project.eu:8081 as those Server do use nightly builds
>
> best
> Rupert
>
> On Wed, Nov 21, 2012 at 12:44 PM, Reto Bachmann-Gmür <re...@apache.org>
> wrote:
> > Hi
> >
> > I've commited quite massive changes under
> > STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
> > .
> >
> > While Viewable and pojo based freemarker Readme should be dropped in
> favor
> > of LdViewables I've added a near-drop in replacement for the jersey
> > Viewable. The new Viewable no longer relies on the template being located
> > using WebFragment.getTemplateLoader() which is no longer called (but not
> > yet removed) instead the templates are expected to be in a folder named
> > "templates" in any bundle. To support different templates for different
> > target media types the templates are located in templates/html. templates
> > imported in other templates are located directivity in templates as some
> > snippets may have to be rendered in the same way for different target
> media
> > types.
> >
> > There re some remaining imports of com.sun.jersey packages in some of the
> > modules. Namely:
> >
> > Unproblematic I think:
> > - com.sun.jersey.api.client.*: I Think the client API is no problem
> >
> > Need replacement if jersey doesn't offer them in a Jax-RS implementation
> > independent way:
> > - com.sun.jersey.multipart.BodyPart
> > - com.sun.jersey.multipart.FormDataBodyPart
> > - com.sun.jersey.multipart.FormDataParam
> > - com.sun.jersey.multipart.FormDataMultiPart
> > - com.sun.jersey.core.util.MultivaluedMapImpl
> >
> > Not sure what they are for:
> > - com.sun.jersey.core.header.FormDataContentDisposition
> > - com.sun.jersey.spi.resource.Singleton
> > - com.sun.jersey.core.header.FormDataContentDisposition
> > - com.sun.jersey.api.view.ImplicitProduces
> > - com.sun.jersey.spi.resource.Singleton
> > - com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
> > - com.sun.jersey.api.representation.Form
> > - com.sun.jersey.api.core.HttpContext
> > - com.sun.jersey.api.core.HttpRequestContext;
> >
> >
> > Especially if you introduced code that uses one of the classes in the
> last
> > category it would be good if you could have a look at it an either change
> > the code to use standard jax-rs classes or describe what they do and what
> > you need them for.
> >
> > Cheers,
> > Reto
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
Re: Changes to get rid of jersey dependencies
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Reto,
might it be the case that your changes have broken the CSS for Stanbol.
Just recognized it on http://dev.iks-project.eu:8080 and
http://dev.iks-project.eu:8081 as those Server do use nightly builds
best
Rupert
On Wed, Nov 21, 2012 at 12:44 PM, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Hi
>
> I've commited quite massive changes under
> STANBOL-742<https://issues.apache.org/jira/browse/STANBOL-742>
> .
>
> While Viewable and pojo based freemarker Readme should be dropped in favor
> of LdViewables I've added a near-drop in replacement for the jersey
> Viewable. The new Viewable no longer relies on the template being located
> using WebFragment.getTemplateLoader() which is no longer called (but not
> yet removed) instead the templates are expected to be in a folder named
> "templates" in any bundle. To support different templates for different
> target media types the templates are located in templates/html. templates
> imported in other templates are located directivity in templates as some
> snippets may have to be rendered in the same way for different target media
> types.
>
> There re some remaining imports of com.sun.jersey packages in some of the
> modules. Namely:
>
> Unproblematic I think:
> - com.sun.jersey.api.client.*: I Think the client API is no problem
>
> Need replacement if jersey doesn't offer them in a Jax-RS implementation
> independent way:
> - com.sun.jersey.multipart.BodyPart
> - com.sun.jersey.multipart.FormDataBodyPart
> - com.sun.jersey.multipart.FormDataParam
> - com.sun.jersey.multipart.FormDataMultiPart
> - com.sun.jersey.core.util.MultivaluedMapImpl
>
> Not sure what they are for:
> - com.sun.jersey.core.header.FormDataContentDisposition
> - com.sun.jersey.spi.resource.Singleton
> - com.sun.jersey.core.header.FormDataContentDisposition
> - com.sun.jersey.api.view.ImplicitProduces
> - com.sun.jersey.spi.resource.Singleton
> - com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap;
> - com.sun.jersey.api.representation.Form
> - com.sun.jersey.api.core.HttpContext
> - com.sun.jersey.api.core.HttpRequestContext;
>
>
> Especially if you introduced code that uses one of the classes in the last
> category it would be good if you could have a look at it an either change
> the code to use standard jax-rs classes or describe what they do and what
> you need them for.
>
> Cheers,
> Reto
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen