Like I said, its not a concern for me (no servlet, no hibernate, no flute),
but for those who want to stick gwt-user.jar in a WEB-INF/lib/, it would be
nice to not have to renamed it "zwt-user.jar".

My knee-jerk reaction is to put it in gwt-servlet (since other relatively
new classes like AutoBeanFactorySource also made it in there) - does that
seem like a reasonable step?


On Mon, Jun 9, 2014 at 6:22 PM, John A. Tamplin <[email protected]> wrote:

> On Mon, Jun 9, 2014 at 6:33 PM, Colin Alworth <[email protected]> wrote:
>
>> Currently SafeHtml &co live in gwt-user, though they are for the most
>> part listed in a shared package, implying that a server can use them.
>> However, gwt-user.jar also includes javax packages as well as hibernate,
>> w3c, etc, so can't reasonably be imported to a server which already uses
>> any of those packages (i.e. any servlet container). Is this an oversight in
>> the publicly packaged GWT and is SafeHtml used by teams that package
>> differently, or instead is this package not actually intended for server
>> use, but instead just compile-time tasks where gwt-user is on the classpath
>> like compiling or linking?
>>
>> I'm doing some work on a non-servlet server which hasn't so far seen
>> concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy
>> way to get server generated HTML from code that is shared with the client.
>> This use case *appears* to be implied from the package name, but presently
>> isn't possible for the majority of GWT backends.
>>
>> Ideas on why it is the way it is? Thoughts on how to make it available to
>> the server (without giving it yet another jar a la requestfactory-server)?
>> Interest in a contributed SafeHtmlTemplates implementation for JVM?
>>
>
> Yes, SafeHtml is intended to be usable on the server.  There have been
> various discussions about splitting up gwt-user into parts for client-only,
> shared (and perhaps server-only), but that wasn't ever done.
>
> Mostly, putting gwt-user last on the classpath on your server won't cause
> any issues, though at least one JVM used to be unhappy with native methods
> without corresponding binaries.
>
> --
> John A. Tamplin
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
218.248.6165
[email protected]

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMzdu5cz3bjvWYW7%3DvUm%3D%3DfC0b83sg0%3Dbs7j%2BmTNDjFSeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to