Re: Introducing Croquet: Combining Wicket, Jetty, Hibernate, and Guice
I agree that JPA can be clunky. I have found the CriteriaBuilder way of building queries to be manageable (if a bit verbose). So far, I’ve used JQL queries (defined in @NamedQuery annotations) for the queries that have a well-defined structure, and CriteriaBuilder for the more complex cases (such as filtering by a user-defined set of parameters). My use cases have been relatively simple, though. -Chris On Tue, Apr 15, 2014 at 8:49 AM, William Speirs wrote: > I hadn't heard of it. There are a few ORMs out there. I've looked at this > library as well: http://jdbi.org/ However, that's a bit too much SQL > writing for just the basic objects for me. Though it is a GREAT setup to > make unit testing REALLY easy. > > I just find the JPA API so clumsy, especially when building dynamic > queries. Even Hibernate's "native" interface is MUCH better than JPA. > > Bill- > > > On Tue, Apr 15, 2014 at 3:26 AM, Martin Grigorov >wrote: > > > what do you think about JOOQ ? > > > > > > > http://www.petrikainulainen.net/programming/jooq/using-jooq-with-spring-crud/ > > > > Martin Grigorov > > Wicket Training and Consulting > > > > > > On Tue, Apr 15, 2014 at 6:00 AM, William Speirs > > wrote: > > > > > Off-topic a bit... on the JPA front, I'm still relatively new and > finding > > > it not as useful as I would have hoped. Beyond VERY simple > > > read-by-primary-key and update/create/delete, anything else seems > > tedious. > > > I'm having to learn the JPA query language (yes, you can use SQL but > then > > > you lose generics/typing). I'm highly considering updating another one > of > > > my projects SOP4J-DBUTILS (https://github.com/wspeirs/sop4j-dbutils) > to > > > handle JPA annotations for the basic CRUD operations, then just making > it > > > slightly easier to use complex where clauses to populate POJOs. > > > > > > Thoughts? > > > > > > Bill- > > > > > > P.S. We should probably take this off the Wicket list if folks want to > > > continue discussing... > > > > > > > > > > > > On Mon, Apr 14, 2014 at 9:03 AM, Chris Snyder < > chris.sny...@biologos.org > > > >wrote: > > > > > > > Thanks for the reply - no worries on the delay. > > > > > > > > In my case, I'm using EclipseLink. I originally was using Hibernate, > > but > > > > switched after encountering a known bug in Hibernate (the specifics > of > > > > which I no longer recall). Since I was sticking to using the pure JPA > > > API, > > > > it was a quick drop-in replacement. Recently, however, I have used a > > > couple > > > > of EclipseLink-specific features, so it wouldn't be as quick to > switch > > > back > > > > (assuming that the bug in Hibernate has been fixed). > > > > > > > > This certainly wouldn't stop me from checking out Croquet - if I end > up > > > > adapting it to use EclipseLink, I'll be sure to share my changes. > > > > > > > > Best, > > > > Chris > > > > > > > > > > > > On Mon, Apr 14, 2014 at 8:44 AM, Bill Speirs > > > > wrote: > > > > > > > > > Chris, sorry for not responding more quickly... was traveling back > > from > > > > > ApacheCon NA. > > > > > > > > > > Honestly, it would be non-trivial to drop in a replacement to > > > Hibernate. > > > > > The JpaPersistService (http://goo.gl/FeI6xU) handles the > > configuration > > > > > coming from persistence.xml and has nothing Hibernate specific. The > > > > problem > > > > > is the CroquetPersistService, DataSourceHibernateModule, and > > > > > EntityManagerProxyFactory classes. > > > > > > > > > > What JPA provider would you rather use? I've never used anything > but > > > > > Hibernate, and never had issues with it... just curious why you'd > > like > > > to > > > > > use something else. > > > > > > > > > > Also, patches/pull requests are always happily accepted :-) > > > > > > > > > > Thanks for checking it out... > > > > > > > > > > Bill- > > > > > > > > > > > > > > > On Wed, Apr 9, 2014 at 1:05 PM, Chris Snyder < > &g
Re: Introducing Croquet: Combining Wicket, Jetty, Hibernate, and Guice
Thanks for the reply - no worries on the delay. In my case, I'm using EclipseLink. I originally was using Hibernate, but switched after encountering a known bug in Hibernate (the specifics of which I no longer recall). Since I was sticking to using the pure JPA API, it was a quick drop-in replacement. Recently, however, I have used a couple of EclipseLink-specific features, so it wouldn't be as quick to switch back (assuming that the bug in Hibernate has been fixed). This certainly wouldn't stop me from checking out Croquet - if I end up adapting it to use EclipseLink, I'll be sure to share my changes. Best, Chris On Mon, Apr 14, 2014 at 8:44 AM, Bill Speirs wrote: > Chris, sorry for not responding more quickly... was traveling back from > ApacheCon NA. > > Honestly, it would be non-trivial to drop in a replacement to Hibernate. > The JpaPersistService (http://goo.gl/FeI6xU) handles the configuration > coming from persistence.xml and has nothing Hibernate specific. The problem > is the CroquetPersistService, DataSourceHibernateModule, and > EntityManagerProxyFactory classes. > > What JPA provider would you rather use? I've never used anything but > Hibernate, and never had issues with it... just curious why you'd like to > use something else. > > Also, patches/pull requests are always happily accepted :-) > > Thanks for checking it out... > > Bill- > > > On Wed, Apr 9, 2014 at 1:05 PM, Chris Snyder >wrote: > > > Looks like awesome work - very clean page design and excellent > > documentation, and I'm sure that the quality extends to the code as well. > > I'll definitely be looking into this for my next project, if not porting > > some of my current ones. > > > > When using Croquet, how easy would it be to drop in a different JPA > > implementation in place of Hibernate? > > > > Best, > > Chris > > > > > > On Wed, Apr 9, 2014 at 12:51 PM, William Speirs > > wrote: > > > > > I gave a talk at ApacheCon NA yesterday on Croquet. It is a combination > > of > > > Wicket, Jetty, Hibernate, and Guice to make it super-easy to start > > writing > > > Wicket code almost immediately, instead of spending time configuring > > > everything. > > > > > > Slides: > > > > > > > > > https://docs.google.com/presentation/d/1m3jdbpYoSBOCPz8Wes9mPvhf8TLp_3dndj_gW08iFL8/ > > > Code: https://github.com/metrink/croquet > > > Docs: http://croquet.metrink.com > > > > > > Thanks... > > > > > > Bill- > > > > > > -- Chris Snyder Web Developer, BioLogos 616.328.5218 x203 biologos.org
Re: Introducing Croquet: Combining Wicket, Jetty, Hibernate, and Guice
Looks like awesome work - very clean page design and excellent documentation, and I'm sure that the quality extends to the code as well. I'll definitely be looking into this for my next project, if not porting some of my current ones. When using Croquet, how easy would it be to drop in a different JPA implementation in place of Hibernate? Best, Chris On Wed, Apr 9, 2014 at 12:51 PM, William Speirs wrote: > I gave a talk at ApacheCon NA yesterday on Croquet. It is a combination of > Wicket, Jetty, Hibernate, and Guice to make it super-easy to start writing > Wicket code almost immediately, instead of spending time configuring > everything. > > Slides: > > https://docs.google.com/presentation/d/1m3jdbpYoSBOCPz8Wes9mPvhf8TLp_3dndj_gW08iFL8/ > Code: https://github.com/metrink/croquet > Docs: http://croquet.metrink.com > > Thanks... > > Bill- >
Re: The wicket way of getting application base URL
I think that such a configuration option is likely your only choice, and is something I often see in other webapps. The only other option I can think of would be if the proxy was passing a header with the original requested URL. However, I don't see such functionality in mod_proxy (at least from a quick skim of its documentation). I can imagine a hacky way of using Javascript to pass it in. I'm only mentioning it to dissuade you from considering it (if you were), as it would be a huge security risk: Someone could send incorrect data to the server, causing it to send out the wrong URLs. That would make for an effective phishing campaign - emails from a legitimate source with links to the cracker's server. Best, Chris On Thu, Mar 13, 2014 at 9:22 AM, jchappelle wrote: > We just use a configuration property in our application that is stored in > our > "properties" database table. So our solution really doesn't involve wicket > at all. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/The-wicket-way-of-getting-application-base-URL-tp4664925p4664938.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Chris Snyder Web Developer, BioLogos biologos.org
Re: Best practice for updating JPA object without persisting changes
Thanks, Igor - that's very helpful. Not sure how I missed that article while I was searching. It would be a bit tricky to implement in my situation (as I described in another response, the JPA implementation of the data storage is abstracted behind a service API), but I could make it work - perhaps by adding detach and merge methods to the API; that would perhaps expose a little too much of the implementation, but I think that other (hypothetical) implementations could also need to expose similar functionality. Of course, I might be over-engineering this whole abstraction anyways. I have no intention of implementing a non-JPA version - perhaps I should embrace a hard dependency on JPA and simplify everything. JPA is itself an abstraction layer, after all... Thanks, Chris On Wed, Mar 5, 2014 at 11:44 AM, Igor Vaynberg wrote: > have a look here: > > > https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/ > > -igor > > On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder > wrote: > > I'm dealing with an issue that I'm sure has been solved by many people on > > this list, but I'm struggling to ascertain the best way to solve it. > > > > I'm working on implementing in-place-edit functionality for some of our > > site content. The content is stored in a database and mapped via JPA. The > > edit form has the JPA entity as the backing model object. > > > > One of the features I'm implementing is the ability to preview what's > been > > entered in the form without the updates being committed to the database > > (until the user explicitly clicks on the "Save" button). I can think of a > > few ways to accomplish this: > > > > 1. Rollback the transaction when not saving - This would require me to > > manage the transaction manually (right now, they're being managed > > automatically by Guice's PersistFilter). > > > > 2. Detach the object from the persistence context, merge it to save - > This > > seems like the most elegant solution, but I can see how there could be > > issues (not intractable) with lazy loading. > > > > 3. Prevent the form from updating the model until save - This would break > > my preview panel, and seems to be contrary to how forms normally behave. > > > > 4. Copy the data into a non-managed DTO, copying it back to the JPA > object > > on save - Would require a lot of clone/copy code. > > > > This seems like such a common problem to solve - I think my relative > > unfamiliarity with JPA is the main stumbling block here. How have others > > implemented it? Is there a best-practice pattern that my Googling didn't > > discover? > > > > Thanks in advance for the help. I hope that it isn't too off-topic since > it > > is mainly JPA-related. > > > > Best, > > Chris > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Chris Snyder Web Developer, BioLogos 616.328.5218 x203 biologos.org
Re: Best practice for updating JPA object without persisting changes
Hi Haiko, Thanks for the response. You raise some good points - it certainly would be cleaner and easier to understand. It also could be better for my layout, given the way I've organized the code: The data layer is abstracted behind a service API, so we could plug in a different storage engine (Cassandra instead of JPA, for example) without needing to modify the other layers. The editor code currently has no knowledge of JPA, so I'd have to expose some of the business layer to implement either of my first two options. Do you use any tools to make the copying easier, or do you code it by hand? Thanks, Chris On Wed, Mar 5, 2014 at 8:07 AM, wrote: > Hi Chris, > > I would go for option 4. This is how I implement such cases. It has an > explicit distinction between states 'previewMode' and 'commited Mode'. > Looks like more coding, but actually is clear about distinction between > preview and saved. And that would help the programmer that picks this code > up a half year from now. > > My 2 cents. > > Best, > > Haiko > > Chris Snyder schreef: > > > I'm dealing with an issue that I'm sure has been solved by many people on >> this list, but I'm struggling to ascertain the best way to solve it. >> >> I'm working on implementing in-place-edit functionality for some of our >> site content. The content is stored in a database and mapped via JPA. The >> edit form has the JPA entity as the backing model object. >> >> One of the features I'm implementing is the ability to preview what's been >> entered in the form without the updates being committed to the database >> (until the user explicitly clicks on the "Save" button). I can think of a >> few ways to accomplish this: >> >> 1. Rollback the transaction when not saving - This would require me to >> manage the transaction manually (right now, they're being managed >> automatically by Guice's PersistFilter). >> >> 2. Detach the object from the persistence context, merge it to save - This >> seems like the most elegant solution, but I can see how there could be >> issues (not intractable) with lazy loading. >> >> 3. Prevent the form from updating the model until save - This would break >> my preview panel, and seems to be contrary to how forms normally behave. >> >> 4. Copy the data into a non-managed DTO, copying it back to the JPA object >> on save - Would require a lot of clone/copy code. >> >> This seems like such a common problem to solve - I think my relative >> unfamiliarity with JPA is the main stumbling block here. How have others >> implemented it? Is there a best-practice pattern that my Googling didn't >> discover? >> >> Thanks in advance for the help. I hope that it isn't too off-topic since >> it >> is mainly JPA-related. >> >> Best, >> Chris >> > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Best practice for updating JPA object without persisting changes
Hi Patrick, Thanks for the response. does the Guice's PersistFilter really automatically find and re-attach > the backed object in the request while leaving the in-place-edit situation? Guice doesn't do anything with whether the objects are attached - I'm simply never detaching them (unless I implement option #2), so any changes made to the object are automatically persisted by the JPA engine. Guice's role here is with transactions - the PersistFilter starts a transaction at the beginning of the request, and commits it at the end. Thanks, Chris On Wed, Mar 5, 2014 at 8:29 AM, Patrick Davids wrote: > Hi Chris, > > I thought... as long as "nothing"/nobody finds and re-attach the backed > object, your changes are "naturally" temporary and only stored on page > cache. > > I would expect, it should already work out-of-the-box... But I did not > work with Guice's PersistFilter, yet. May I miss something... > > kind regards > Patrick > > Am 05.03.2014 12:47, schrieb Chris Snyder: > > I'm dealing with an issue that I'm sure has been solved by many people on > > this list, but I'm struggling to ascertain the best way to solve it. > > > > I'm working on implementing in-place-edit functionality for some of our > > site content. The content is stored in a database and mapped via JPA. The > > edit form has the JPA entity as the backing model object. > > > > One of the features I'm implementing is the ability to preview what's > been > > entered in the form without the updates being committed to the database > > (until the user explicitly clicks on the "Save" button). I can think of a > > few ways to accomplish this: > > > > 1. Rollback the transaction when not saving - This would require me to > > manage the transaction manually (right now, they're being managed > > automatically by Guice's PersistFilter). > > > > 2. Detach the object from the persistence context, merge it to save - > This > > seems like the most elegant solution, but I can see how there could be > > issues (not intractable) with lazy loading. > > > > 3. Prevent the form from updating the model until save - This would break > > my preview panel, and seems to be contrary to how forms normally behave. > > > > 4. Copy the data into a non-managed DTO, copying it back to the JPA > object > > on save - Would require a lot of clone/copy code. > > > > This seems like such a common problem to solve - I think my relative > > unfamiliarity with JPA is the main stumbling block here. How have others > > implemented it? Is there a best-practice pattern that my Googling didn't > > discover? > > > > Thanks in advance for the help. I hope that it isn't too off-topic since > it > > is mainly JPA-related. > > > > Best, > > Chris > > >
Best practice for updating JPA object without persisting changes
I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the "Save" button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris
Re: Show textfield as plaintext when disabled?
One potential issue: Depending on where you're using the technique, it could lead to problems. For instance, if you are implementing in-place-edit functionality on a public-facing page, having a lot of your content in tags could make the content invisible to search engines (I'm just guessing here - it would make sense for search engines to ignore form content, but I don't know if this is true). Even if search engines aren't a concern, it's contrary to semantic HTML, and could lead to problems for non-graphical browsers. Nevertheless, it's easy, and certainly acceptable for many situations. Still, I stand by my initial "cludgy" assertion. :-) -Chris On Mon, Mar 3, 2014 at 4:04 AM, Stijn de Witt < stijn.dew...@planonsoftware.com> wrote: > I wouldn't call it cludgy... 'pragmatic' is the word that comes to mind :) > > Big advantage of styling the input as regular text instead of completely > replacing the HTML element is that all other behavior remains as expected. > The field is still submitted with the form etc. > > -Stijn > > > -Original Message- > From: Chris Snyder [mailto:chris.sny...@biologos.org] > Sent: zaterdag 1 maart 2014 17:54 > To: Wicket users mailing list mailing list > Subject: Re: Show textfield as plaintext when disabled? > > I also ended up going the panel route for this. > > An alternative - perhaps a bit cludgy - would be to style the input fields > as plain text using CSS (remove the border & outline, alter the padding, > etc.). > > -Chris > > On Sat, Mar 1, 2014 at 6:35 AM, Andrea Del Bene >wrote: > > > Hi, l've tried to do a similar thing a couple of months ago but it was > > very tricky and l ended up using a panel with two components (text > > field and a label). > > You can use methods oncomponenttag and onxomponenttagbody to > > dynamically change the tag and the body depending on component status > (view or edit)... > > Good luck :). > > On Feb 28, 2014 8:34 PM, "Entropy" wrote: > > > > > Is there a way to have my textfield show as plain text when in a > > > readonly mode rather than as a disabled textbox? > > > > > > Backup question: I can imagine making a panel to do this...having a > > > textfield and label and hiding whichever I didn't want, but I would > > > want > > my > > > panel to bind to a textbox in the parent page and replace that tag > > > (otherwise I would have two textboxes, right). How would I go about > > that? > > > > > > -- > > > View this message in context: > > > > > http://apache-wicket.1842946.n4.nabble.com/Show-textfield-as-plaintext > > -when-disabled-tp4664723.html > > > Sent from the Users forum mailing list archive at Nabble.com. > > > > > > > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > >
Re: Show textfield as plaintext when disabled?
I also ended up going the panel route for this. An alternative - perhaps a bit cludgy - would be to style the input fields as plain text using CSS (remove the border & outline, alter the padding, etc.). -Chris On Sat, Mar 1, 2014 at 6:35 AM, Andrea Del Bene wrote: > Hi, l've tried to do a similar thing a couple of months ago but it was very > tricky and l ended up using a panel with two components (text field and a > label). > You can use methods oncomponenttag and onxomponenttagbody to dynamically > change the tag and the body depending on component status (view or edit)... > Good luck :). > On Feb 28, 2014 8:34 PM, "Entropy" wrote: > > > Is there a way to have my textfield show as plain text when in a readonly > > mode rather than as a disabled textbox? > > > > Backup question: I can imagine making a panel to do this...having a > > textfield and label and hiding whichever I didn't want, but I would want > my > > panel to bind to a textbox in the parent page and replace that tag > > (otherwise I would have two textboxes, right). How would I go about > that? > > > > -- > > View this message in context: > > > http://apache-wicket.1842946.n4.nabble.com/Show-textfield-as-plaintext-when-disabled-tp4664723.html > > Sent from the Users forum mailing list archive at Nabble.com. > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
Re: Nested Forms
Nested elements (what I'm assuming you're referring to) aren't allowed, per the HTML spec: http://www.w3.org/TR/html5/forms.html I wouldn't expect Wicket to follow any kind of predictable behavior (especially since different browsers likely exhibit different behaviors themselves). Best, Chris On Fri, Jan 10, 2014 at 12:04 PM, gmparker2000 wrote: > When submitting an inner form it appears that the request contains all of > the > outer and inner form fields. Is this the expected behaviour? From what I > can see it appears that the outer form is submitted, and only the inner > form > parameters are validated and used for model updates. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Nested-Forms-tp4663620.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Prefixing CDN URL to resources base path
I'm planning to do something similar. In my searches, I came across the following: http://blog.55minutes.com/2012/01/simplecdn-and-the-newly-released-fiftyfive-wicket-32/ I haven't tried it yet, but it seems like a solid idea. -Chris Snyder On Fri, Dec 13, 2013 at 9:26 AM, Arjun Dhar wrote: > Hi, > I'm trying to make the use of CDN hassle free with my Wicket Apps. > .. where *IF* a CDN location is specified then all paths like > > > > .. become > > > > This applies to JS, CSS, and img tags mainly. > > Am wondering where the best place to automate this would be ? > 1. Build Process; do a REPLACE during production BUILD > 2. Wicket code that loads using IResourceStream UrlResourceStream(url) ; > Intercept the raw HTML stream and re-generate it? (if this is cached may be > efficient??) > 3. HttpServletFilter --> Just before its passed back from the Web Server. > Do > a RegEx scan and replace (Maybe too inefficient , but less intrusive to any > Wicket Vodoo) > > Thoughts? > > > > - > Software documentation is like sex: when it is good, it is very, very > good; and when it is bad, it is still better than nothing! > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Prefixing-CDN-URL-to-resources-base-path-tp4662997.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Chris Snyder Web Developer, BioLogos biologos.org
Re: SVG mime-type incorrect
Good catch - thanks. Though it turns out that the mailcap stuff is all a red
herring - they're just a stub for some code that somebody (probably in 1996 or
thereabouts) thought they'd implement someday:
> // For backward compatibility -- mailcap format files
> // This is not currently used, but may in the future when we add ability
> // to read BOTH the properties format and the mailcap format.
Here's where the actual content-type loading takes place:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/MimeTable.java#229
To get this working, I copied the content-types.properties file from the Java
lib directory to in the package next to the Wicket Start class, added an entry
for SVG (the stock file is quite sparse), and added the following line in
Start#main:
> System.setProperty("content.types.user.table",
> Start.class.getResource("content-types.properties").getPath());
After doing that, it works properly - the correct mime-type is served, and
Chrome displays the image. This is hardly a good solution for a production
environment, but it will suffice for now.
Given how much of a mess that Java code is, it seems to me that Wicket's
UrlResourceStream#getData method should be modified to not call
URLConnection#getContentType at all. The behavior for when getContentType
returns null - ask the Application [if it exists], or consult
URLConnection#getFileNameMap - looks to be better for all cases.
Thanks so much for your help. I'm just getting into Wicket programming, and am
very impressed with the helpfulness of the community.
Thanks,
Chris
--
Chris Snyder
Web Developer, BioLogos
616.328.5208 x203
biologos.org
On Jul 30, 2013, at 14:23, Martin Grigorov wrote:
> You are right.
> It tries with getHeaderName(String) which looks in MimeTable and falls back
> to by stream.
> I think you need to set the type in your mailcap file.
>
>
> On Tue, Jul 30, 2013 at 8:16 PM, Chris Snyder
> wrote:
>
>> Except that URLConnection#getContentType doesn't even use MimeTable:
>>
>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/URLConnection.java?av=f#147
>>
>> URLConnection#guessContentTypeFromStream is what it's using:
>>
>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/net/URLConnection.java#URLConnection.guessContentTypeFromStream%28java.io.InputStream%29
>> Ugh - what a mess. That seems like a very arbitrary set of filetypes to
>> test for (FlashPix?). It sees that the SVG file starts with > returns application/xml - not wrong, per se - but not accurate enough.
>>
>>> On my
>>> machine
>> System.err.println(URLConnection.getFileNameMap().getContentTypeFor("file.svg"));
>>> prints null
>> Same here. However, the following returns "application/xml" (test.svg must
>> be an SVG file, of course):
>>
>> System.err.println(URLConnection.guessContentTypeFromStream(getClass().getResourceAsStream("test.svg")));
>>
>> Thanks,
>> Chris
>> --
>> Chris Snyder
>> Web Developer, BioLogos
>> 616.328.5208 x203
>> biologos.org
>>
>> On Jul 30, 2013, at 13:52, Martin Grigorov wrote:
>>
>>> This is nasty indeed!
>>>
>>> According to
>>>
>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/MimeTable.java#MimeTable
>>> the
>>> mime types are loaded from mailcap files.
>>> See "man update-mime"
>>>
>>>
>>> On Tue, Jul 30, 2013 at 7:40 PM, Chris Snyder >> wrote:
>>>
>>>> However, just above that (line 122) it gets the contentType from the
>>>> URLConnection, which returns "application/xml". Since
>>>> streamData.contentType is not null, it never gets to line 126.
>>>>
>>>> Thanks so much for your help!
>>>>
>>>> -Chris
>>>> --
>>>> Chris Snyder
>>>> Web Developer, BioLogos
>>>> 616.328.5208 x203
>>>> biologos.org
>>>>
>>>> On Jul 30, 2013, at 13:30, Martin Grigorov
>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> According to
>>>>>
>>>>
>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/resource/UrlResourceStream.java?source=cc#L126
>>>>> if
>>>>> theere is an application then it should be used before falling back.
>>>>
>>>>
>>
>>
Re: SVG mime-type incorrect
Except that URLConnection#getContentType doesn't even use MimeTable:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/URLConnection.java?av=f#147
URLConnection#guessContentTypeFromStream is what it's using:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/net/URLConnection.java#URLConnection.guessContentTypeFromStream%28java.io.InputStream%29
Ugh - what a mess. That seems like a very arbitrary set of filetypes to test
for (FlashPix?). It sees that the SVG file starts with On my
> machine
> System.err.println(URLConnection.getFileNameMap().getContentTypeFor("file.svg"));
> prints null
Same here. However, the following returns "application/xml" (test.svg must be
an SVG file, of course):
System.err.println(URLConnection.guessContentTypeFromStream(getClass().getResourceAsStream("test.svg")));
Thanks,
Chris
--
Chris Snyder
Web Developer, BioLogos
616.328.5208 x203
biologos.org
On Jul 30, 2013, at 13:52, Martin Grigorov wrote:
> This is nasty indeed!
>
> According to
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/MimeTable.java#MimeTable
> the
> mime types are loaded from mailcap files.
> See "man update-mime"
>
>
> On Tue, Jul 30, 2013 at 7:40 PM, Chris Snyder
> wrote:
>
>> However, just above that (line 122) it gets the contentType from the
>> URLConnection, which returns "application/xml". Since
>> streamData.contentType is not null, it never gets to line 126.
>>
>> Thanks so much for your help!
>>
>> -Chris
>> --
>> Chris Snyder
>> Web Developer, BioLogos
>> 616.328.5208 x203
>> biologos.org
>>
>> On Jul 30, 2013, at 13:30, Martin Grigorov wrote:
>>
>>> Hi,
>>>
>>> According to
>>>
>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/resource/UrlResourceStream.java?source=cc#L126
>>> if
>>> theere is an application then it should be used before falling back.
>>
>>
Re: SVG mime-type incorrect
However, just above that (line 122) it gets the contentType from the URLConnection, which returns "application/xml". Since streamData.contentType is not null, it never gets to line 126. Thanks so much for your help! -Chris -- Chris Snyder Web Developer, BioLogos 616.328.5208 x203 biologos.org On Jul 30, 2013, at 13:30, Martin Grigorov wrote: > Hi, > > According to > https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/resource/UrlResourceStream.java?source=cc#L126 > if > theere is an application then it should be used before falling back.
Re: SVG mime-type incorrect
Hi Martin, Thanks for the extremely prompt response. Unfortunately, it appears that Application#getMimeType isn't called for UrlResourceStream resources - UrlResourceStream#getData calls URLConnection#getContentType, at which point we've entrusted the mime-type to Java. Versions I should have included in my first email: I'm using Wicket 6.9.1, using the Jetty server referenced in the quickstart. Thanks, Chris -- Chris Snyder Web Developer, BioLogos 616.328.5208 x203 biologos.org On Jul 30, 2013, at 13:06, Martin Grigorov wrote: > Hi, > > You can override org.apache.wicket.Application#getMimeType > > > On Tue, Jul 30, 2013 at 7:01 PM, Chris Snyder > wrote: > >> I'm trying to serve SVG images as package resources. However, when I do >> so, the image files are served with a mime-type of application/xml, rather >> than the correct image/svg+xml. This causes strange behavior in Google >> Chrome - the image displays as a broken link when included in an >> tag, but renders fine when the image URL is opened directly. If the >> resource is served from the main webapp directory rather than as a package >> resource, the correct mime-type is sent and Chrome displays the image >> properly. >> >> Delving into the code, it appears that the problem is Java's >> URLConnection.guessContentTypeFromStream() method, which doesn't support >> SVG files. I've verified this problem on both the Apple-supplied Java 1.6 >> and the official Oracle Java 1.7, both on MacOS X. >> >> What would be the best way to work around this issue? I tried creating my >> own custom PackageResource wrapper, which had its own PackageResourceStream >> wrapper, but it quickly got unwieldy (as well as being a nightmare for >> future maintainability). >> >> My goal is to have a subclass of Image that returns either a reference to >> an SVG or a PNG depending on the browser version. I first noticed the >> mime-type problem with my subclass, but I verified that it also exists when >> using the standard Image class. >> >> Thanks in advance for your help! >> -Chris Snyder >> -- >> Chris Snyder >> Web Developer, BioLogos >> 616.328.5208 x203 >> biologos.org >> >>
SVG mime-type incorrect
I'm trying to serve SVG images as package resources. However, when I do so, the image files are served with a mime-type of application/xml, rather than the correct image/svg+xml. This causes strange behavior in Google Chrome - the image displays as a broken link when included in an tag, but renders fine when the image URL is opened directly. If the resource is served from the main webapp directory rather than as a package resource, the correct mime-type is sent and Chrome displays the image properly. Delving into the code, it appears that the problem is Java's URLConnection.guessContentTypeFromStream() method, which doesn't support SVG files. I've verified this problem on both the Apple-supplied Java 1.6 and the official Oracle Java 1.7, both on MacOS X. What would be the best way to work around this issue? I tried creating my own custom PackageResource wrapper, which had its own PackageResourceStream wrapper, but it quickly got unwieldy (as well as being a nightmare for future maintainability). My goal is to have a subclass of Image that returns either a reference to an SVG or a PNG depending on the browser version. I first noticed the mime-type problem with my subclass, but I verified that it also exists when using the standard Image class. Thanks in advance for your help! -Chris Snyder -- Chris Snyder Web Developer, BioLogos 616.328.5208 x203 biologos.org
