Re: Need for normalization? (Re: svn commit: r980880 - in /cxf/trunk/tools/common/src)
To chime in: it's a really, really, bad idea for non-file URLs, as it
can violate stringprep.
For file URLs, it is an attempt to deal, with non-NFC (or NFKC)
strings in the URL failing to match the file system. However, file
system normalization is platform-dependendent. Linux does none at all,
for example. So it's not safe in general.
On Fri, Jul 30, 2010 at 9:50 PM, Glen Mazza wrote:
> May I ask why this normalization is helpful (instead of just using the
> intended file path to being with)?
> Does this affect just internal CXF use or external usage by users of CXF?
> If the latter, the potential problem I see is that not all URI's are file
> paths and, even if they were, I'm not sure that you can safely normalize in
> a platform-independent manner.
>
> Glen
>
> e...@apache.org wrote:
>>
>> Author: ema
>> Date: Fri Jul 30 16:07:40 2010
>> New Revision: 980880
>>
>> URL: http://svn.apache.org/viewvc?rev=980880&view=rev
>> Log:
>> [CXF-2918]:normalize the url like file:/home/cxf/org/apache/../../cxf in
>> URIParserUtil.getAbsoluteURL()
>>
>> Modified:
>>
>> cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java
>>
>> cxf/trunk/tools/common/src/test/java/org/apache/cxf/tools/util/URIParserUtilTest.java
>>
>> Modified:
>> cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java
>> URL:
>> http://svn.apache.org/viewvc/cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java?rev=980880&r1=980879&r2=980880&view=diff
>>
>> ==
>> ---
>> cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java
>> (original)
>> +++
>> cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java
>> Fri Jul 30 16:07:40 2010
>> @@ -248,18 +248,15 @@ public final class URIParserUtil {
>> }
>> public static String normalize(final String uri) {
>> URL url = null;
>> + String result = null;
>> try {
>> url = new URL(uri);
>> - return escapeChars(url.toString().replace("\\", "/"));
>> + result =
>> escapeChars(url.toURI().normalize().toString().replace("\\", "/"));
>>
>
>
>
JAX-RS spring config incompatibility/bug?
org.apache.cxf.endpoint.ServerImpl - Setting the server's publish address to be /Extraction Jul 31, 2010 7:54:31 AM org.springframework.beans.GenericTypeAwarePropertyDescriptor getWriteMethodForActualAccess WARNING: Invalid JavaBean property 'serviceBeans' being accessed! Ambiguous write methods found next to actually used [public void org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setServiceBeans(java.lang.Object[])]: [public void org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setServiceBeans(java.util.List)] This is with Spring 3.0.3.
Re: [GSOC] Simple and lightweight HTML-based browser for surveying Apache CXF logs
Hi Sergey, Referring to commit r981073, I introduce as fallows changes (include your comments): - Added word wrap to entry content; - Added fancy exception handler; - Hided security fields in "add/edit endpoint" dialog box; - Added Customer service and client (for easy interact) to sample - service produces log entries which simulate using LogBrowser in production environment; - Updated default AtomPullServer's pageSize from 40 to 25; - Added restoring entry selection when change page; - Added validation for "Copies" fiels in sample; - Added support for arrows in entries list; - Replace cutting message with "title" property; - Added milliseconds to datetime format; - Fixed clearing entries list - added removing all cells rather than clearing content; - Added validation for "name" and "url" in "add/edit endpoint" dialog box; I think all issues and missing features has been resolved. If you mind I'll come back to refactoring, adding documentation etc. Below I gather all your previous comments, which has been resolved in last commit: On Thu, Jul 29, 2010 at 1:38 PM, Sergey Beryozkin wrote: >> However I also found issues (I will fix them ASAP): >> >> - Hide security fields (username, password etc) in "Add/Edit endpoint" >> dialog box (because I won't implemented authentication for endpoints >> in the near future,) >> - Add more advanced exception handler for easy investigating exception; >> - Add word wrap to entry content; Done. >> > - the log entry content does not show now date/level but it has some >> > prefixes which I'm not sure about, ex, if the log entry in the list in >> the >> > top right corner reads DEBUG SomeTime "1" then what is displayed below id >> > "[12]1", so no level & time but some bogus "[12]" prefix Done. >> > - GenerateServlet still causes issues for me, had to enter 40 entries 1 by >> > 1 Fixed - it should work without any problem, but to make sure I add numbers only ability to input and fail fast when can't parse number in GenerateServlet. >> > but rather introduce a JAXRS app >> > endpoint which generates some custom log entries and have the browser >> > involking on that endpoint as discussed earlier on. Done. >> > - Update AtomPullServer to have say a 20-25 limit per page by default - I >> > put 40 originally but it is too much.. Done. >> > - Key Focus is lost periodically. Example, I have to select an individual >> > log entry in the top right corner. But it has to be selected once I >> select >> > TestEndpoint in the left pane (if the entries already exist) or after >> > Refresh and the focus should stay there on that initial entry. If I now >> > press 'next' I should see the first entry in the next list selected again >> > and the same should happen when I press previous. May be this is not easy Done. >> If possible :-) It would also be nice to be able to browse using just > keyboard (using up and down arrows) - but it would be an additional > enhancement Done. -- Best regards, Tomasz Oponowicz
Re: Need for normalization? (Re: svn commit: r980880 - in /cxf/trunk/tools/common/src)
What might be a similar issue
(https://jaxb.dev.java.net/issues/show_bug.cgi?id=774) came up recently on
the JAXB issue tracker, I believe the decision there was *not* to normalize;
however, I'm not sure how related Jim's simplification here is to that
issue.
Glen
Benson Margulies wrote:
>
> To chime in: it's a really, really, bad idea for non-file URLs, as it
> can violate stringprep.
>
> For file URLs, it is an attempt to deal, with non-NFC (or NFKC)
> strings in the URL failing to match the file system. However, file
> system normalization is platform-dependendent. Linux does none at all,
> for example. So it's not safe in general.
>
>
> On Fri, Jul 30, 2010 at 9:50 PM, Glen Mazza wrote:
>> May I ask why this normalization is helpful (instead of just using the
>> intended file path to being with)?
>> Does this affect just internal CXF use or external usage by users of CXF?
>> If the latter, the potential problem I see is that not all URI's are
>> file
>> paths and, even if they were, I'm not sure that you can safely normalize
>> in
>> a platform-independent manner.
>>
>> Glen
>>
>> e...@apache.org wrote:
>>>
>>> Author: ema
>>> Date: Fri Jul 30 16:07:40 2010
>>> New Revision: 980880
>>>
>>> URL: http://svn.apache.org/viewvc?rev=980880&view=rev
>>> Log:
>>> [CXF-2918]:normalize the url like file:/home/cxf/org/apache/../../cxf in
>>> URIParserUtil.getAbsoluteURL()
>>>
>>> Modified:
>>>
>>> cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java
>>>
>>> cxf/trunk/tools/common/src/test/java/org/apache/cxf/tools/util/URIParserUtilTest.java
>>>
>>> Modified:
>>> cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java
>>> URL:
>>> http://svn.apache.org/viewvc/cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java?rev=980880&r1=980879&r2=980880&view=diff
>>>
>>> ==
>>> ---
>>> cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java
>>> (original)
>>> +++
>>> cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/util/URIParserUtil.java
>>> Fri Jul 30 16:07:40 2010
>>> @@ -248,18 +248,15 @@ public final class URIParserUtil {
>>> }
>>> public static String normalize(final String uri) {
>>> URL url = null;
>>> + String result = null;
>>> try {
>>> url = new URL(uri);
>>> - return escapeChars(url.toString().replace("\\", "/"));
>>> + result =
>>> escapeChars(url.toURI().normalize().toString().replace("\\", "/"));
>>>
>>
>>
>>
>
>
--
View this message in context:
http://cxf.547215.n5.nabble.com/Need-for-normalization-Re-svn-commit-r980880-in-cxf-trunk-tools-common-src-tp2260268p2260637.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Why org.eclipse.jetty.server.Server instead of org.mortbay.jetty.Server?
Team, our org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine uses Eclipse's wrapper of the Jetty server (org.eclipse.jetty.server.Server) instead of the actual object (org.mortbay.jetty.Server). Out of curiosity, is there a reason for that--is the Eclipse wrappered version more useful or more up-to-date or? Thanks, Glen -- View this message in context: http://cxf.547215.n5.nabble.com/Why-org-eclipse-jetty-server-Server-instead-of-org-mortbay-jetty-Server-tp2260638p2260638.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Why org.eclipse.jetty.server.Server instead of org.mortbay.jetty.Server?
On Saturday 31 July 2010 4:02:11 pm Glen Mazza wrote: > Team, our org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine uses > Eclipse's wrapper of the Jetty server (org.eclipse.jetty.server.Server) > instead of the actual object (org.mortbay.jetty.Server). Out of curiosity, > is there a reason for that--is the Eclipse wrappered version more useful or > more up-to-date or? This is on trunk. 2.2.x still uses org.mortbay. The basic reason is that 6.x will be the last org.mortbay versions.jetty is now officially an Eclipse project and versions 7 and greater will be org.eclipse, not org.mortbay.The org.eclipse stuff doesn't wrapper the org.mortbay, it replaces it.On trunk, we've updated to 7.x (and will probably go to 8.x once 8.0 is released). -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
