date:20140425

Re: [collections] Problems compiling w/gentoo

2014-04-25 Thread Jörg Schaible

sebb wrote:

 On 24 April 2014 19:29, Gary Gregory garydgreg...@gmail.com wrote:
 Should we fix 3.x for Java 8 and release?
 
 The fix works by renaming a public method so IMO is not appropriate for
 3.x.
 
 It would break any existing code that used the remove method,
 requiring the user to edit their source and rebuild.
 
 AFAICT there is no nice solution here.
 
 I think we will just have to accept that 3.x cannot be used on Java 8.
 Seems to me that is better than breaking existing use of the library.

IMHO it just cannot be compiled in Java 8, but existing code will run. You 
can even build your own stuff with Java 8 and a dependency to cc-3.x as long 
as you do not use the MultiValueMap or code that uses it internally hiding 
behind the Map interface.

Maybe we should evaluate further what is actually broken in combination with 
a Java 8 runtime and the problem will manifest at runtime.

- Jörg


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [CSV] Wish: format-specific date generation

2014-04-25 Thread Benedikt Ritter

Agreed, feel free to raise an improvement ticket.


2014-04-22 14:24 GMT+02:00 Gary Gregory garydgreg...@gmail.com:

 For 1.0 at least, we do not plan on doing any type conversion. Later,
 perhaps, but the current thought is to leave type conversion to other
 components.

 Gary


 On Tue, Apr 22, 2014 at 7:22 AM, Rupert Wood m...@rupey.net wrote:

  Hi -
 
 
 
  It would be useful if printing a Java Date or Calendar to a
 CSVFormat.EXCEL
  CSVPrinter would generate output that Excel recognises as a
 date-and-time.
  For example the following
 
 
 
  PrintWriter outputWriter = new PrintWriter(new
  FileOutputStream(output.csv));
 
  CSVPrinter printer = new CSVPrinter(outputWriter, CSVFormat.EXCEL);
 
  printer.print(new Date());
 
  printer.println();
 
  printer.close();
 
 
 
  outputs the raw Date.toString()
 
 
 
  Tue Apr 22 12:06:42 BST 2014
 
 
 
  which Excel only treats as a string. (It will recognise e.g. /mm/dd
 as
  a
  date but I wouldn't know where to look for a definitive set of formats it
  will consume.) Ditto probably printing Calendar.getInstance(), or the new
  Java 8 LocalDate etc. classes.
 
 
 
  One argument against though is then the library perhaps ought to do the
  reverse, i.e. spot that it has been passed a date in and construct a Date
  class for the value at parse time which may be expensive and often
  unnecessary.
 
 
 
  Thanks for your consideration. Happy to raise a JIRA 'Wish' ticket if
 this
  seems reasonable.
 
 
 
  Rupert.
 
 
 
 


 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory




-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [JXPATH] Am I doing something stupid here?

2014-04-25 Thread Matt Benson

Hi, John. Sorry for the long delay.

  The original authors of JXPath are long gone, but from what I can
reconstruct the intent of nested JXPathContexts is only to unify treatment
of things like variables, namespaces, and at a guess, functions. AFAICT
your test case appears to have overcomplicated the issue, although notably
my alternative does resort to some string concatentation to accomplish the
same apparent purpose of the test case. Certainly the whole JXPath codebase
could benefit from some modernization. In any event, I have:

@Test
public void anotherTest() throws Exception {
final InputStream is =

Thread.currentThread().getContextClassLoader().getResourceAsStream(jxpath/simple.pom.xml);

final Document document =
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is);

final JXPathContext ctx = JXPathContext.newContext(document);

// not sure why this was done, but I have preserved it
document.getDocumentElement().removeAttribute(xmlns);

for (@SuppressWarnings(unchecked)
IteratorPointer ptrs =
ctx.iteratePointers(/project/dependencies/dependency); ptrs.hasNext();) {
final Pointer ptr = ptrs.next();
dump((Node) ptr.getNode());
System.out.printf(declared by project with groupId '%s'%n,
ctx.getValue(ptr.asPath() + /ancestor::project/groupId));
}
}

which yields output:

dependency
  groupIdorg.group/groupId
  artifactIdartifact-id/artifactId
  version2.6/version
/dependency

declared by project with groupId 'org.test'

Does this help?

Matt


On Mon, Apr 14, 2014 at 1:09 PM, John Casey jdca...@apache.org wrote:

 Hi all,

 I'm trying to learn how to use JXPath with DOM in order to speed up some
 code that uses a lot of xpath. I've seen blog posts suggesting it's about
 twice as fast as JAXP's XPath processor...

 The problem I'm running into is when I construct a JXPathContext around a
 node down in the DOM tree, then try to select a node elsewhere in the tree
 using the ancestor:: axis. I'm attaching a sample XML file and unit test
 that shows what I'm trying to do.

 I've run this through a debugger, and it appears that the 
 DOMNodePointer.getImmediateParent()
 doesn't even try to look at the Node.getParentNode()...if it doesn't have a
 pre-existing parent (from its ctor) then it just dumbly returns the null
 parent.

 I haven't done enough research yet to know how to get DOMNodePointer to
 populate its parent (using the public API, not the nuts-and-bolts impl
 details), but in the attached example you can see I try two approaches:

 1. the naive approach, which is also the last one in the code. IMO, this
 one should work!

 2. a brute-force alternative, where JXPathContext instances for each
 intermediate node are created to inherit in the right order, all the way
 back to the document itself. From my partial reading of the code, this
 should work even if the naive approach doesn't.

 Neither of these works, though. Can someone shed some light on it, or let
 me know if I've found a bug (seems like a common use case)...

 Thanks,

 -john

 --
 John Casey
 GitHub - http://github.com/jdcasey


 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JXPATH] Am I doing something stupid here?

2014-04-25 Thread Matt Benson

Pointer is an interface that is considered part of the public API. Very
possibly the intent could have been more elegantly expressed by using the
NodePointer API, but this *would* be a case of relying on an implementation
detail, as NodePointer is the Pointer implementation used by
JXPathContextReferenceImpl.

Matt


On Fri, Apr 25, 2014 at 12:39 PM, John Casey jdca...@commonjava.org wrote:

  Yep, that makes a certain kind of sense, though I guess I wouldn't
 exactly call it intuitive. I can see how creating a new context each time
 could be a bad idea (and very inefficient, I suspect)...though it seems (to
 a newbie anyway) that the pointers are an implementation detail that leak
 out in this case.

 Or, maybe I just haven't read enough of the docs?

 At any rate, thanks for your reply. Maybe once this project I'm working on
 is done, I'll take a look at modernizing JXPath. It does seem faster than
 the built-in JAXP stuff.

 -john



 On 04/25/2014 12:33 PM, Matt Benson wrote:

 Hi, John. Sorry for the long delay.

The original authors of JXPath are long gone, but from what I can
 reconstruct the intent of nested JXPathContexts is only to unify treatment
 of things like variables, namespaces, and at a guess, functions. AFAICT
 your test case appears to have overcomplicated the issue, although notably
 my alternative does resort to some string concatentation to accomplish the
 same apparent purpose of the test case. Certainly the whole JXPath codebase
 could benefit from some modernization. In any event, I have:

  @Test
 public void anotherTest() throws Exception {
 final InputStream is =

 Thread.currentThread().getContextClassLoader().getResourceAsStream(jxpath/simple.pom.xml);

  final Document document =
 DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is);

  final JXPathContext ctx = JXPathContext.newContext(document);

  // not sure why this was done, but I have preserved it
 document.getDocumentElement().removeAttribute(xmlns);

  for (@SuppressWarnings(unchecked)
 IteratorPointer ptrs =
 ctx.iteratePointers(/project/dependencies/dependency); ptrs.hasNext();) {
 final Pointer ptr = ptrs.next();
 dump((Node) ptr.getNode());
 System.out.printf(declared by project with groupId '%s'%n,
 ctx.getValue(ptr.asPath() + /ancestor::project/groupId));
 }
 }

  which yields output:

  dependency
   groupIdorg.group/groupId
   artifactIdartifact-id/artifactId
   version2.6/version
 /dependency

  declared by project with groupId 'org.test'

  Does this help?

  Matt


 On Mon, Apr 14, 2014 at 1:09 PM, John Casey jdca...@apache.org wrote:

 Hi all,

 I'm trying to learn how to use JXPath with DOM in order to speed up some
 code that uses a lot of xpath. I've seen blog posts suggesting it's about
 twice as fast as JAXP's XPath processor...

 The problem I'm running into is when I construct a JXPathContext around a
 node down in the DOM tree, then try to select a node elsewhere in the tree
 using the ancestor:: axis. I'm attaching a sample XML file and unit test
 that shows what I'm trying to do.

 I've run this through a debugger, and it appears that the
 DOMNodePointer.getImmediateParent() doesn't even try to look at the
 Node.getParentNode()...if it doesn't have a pre-existing parent (from its
 ctor) then it just dumbly returns the null parent.

 I haven't done enough research yet to know how to get DOMNodePointer to
 populate its parent (using the public API, not the nuts-and-bolts impl
 details), but in the attached example you can see I try two approaches:

 1. the naive approach, which is also the last one in the code. IMO, this
 one should work!

 2. a brute-force alternative, where JXPathContext instances for each
 intermediate node are created to inherit in the right order, all the way
 back to the document itself. From my partial reading of the code, this
 should work even if the naive approach doesn't.

 Neither of these works, though. Can someone shed some light on it, or let
 me know if I've found a bug (seems like a common use case)...

 Thanks,

 -john

 --
 John Casey
 GitHub - http://github.com/jdcasey


 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org



 --
 John Casey
 ---
 GitHub:  https://github.com/jdcasey/
 Twitter: http://twitter.com/buildchimp

Re: [JXPATH] Am I doing something stupid here?

2014-04-25 Thread John Casey

Yep, that makes a certain kind of sense, though I guess I wouldn't 
exactly call it intuitive. I can see how creating a new context each 
time could be a bad idea (and very inefficient, I suspect)...though it 
seems (to a newbie anyway) that the pointers are an implementation 
detail that leak out in this case.


Or, maybe I just haven't read enough of the docs?

At any rate, thanks for your reply. Maybe once this project I'm working 
on is done, I'll take a look at modernizing JXPath. It does seem faster 
than the built-in JAXP stuff.


-john


On 04/25/2014 12:33 PM, Matt Benson wrote:

Hi, John. Sorry for the long delay.

  The original authors of JXPath are long gone, but from what I can 
reconstruct the intent of nested JXPathContexts is only to unify 
treatment of things like variables, namespaces, and at a guess, 
functions. AFAICT your test case appears to have overcomplicated the 
issue, although notably my alternative does resort to some string 
concatentation to accomplish the same apparent purpose of the test 
case. Certainly the whole JXPath codebase could benefit from some 
modernization. In any event, I have:


@Test
public void anotherTest() throws Exception {
final InputStream is =
Thread.currentThread().getContextClassLoader().getResourceAsStream(jxpath/simple.pom.xml);

final Document document = 
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is);


final JXPathContext ctx = JXPathContext.newContext(document);

// not sure why this was done, but I have preserved it
document.getDocumentElement().removeAttribute(xmlns);

for (@SuppressWarnings(unchecked)
IteratorPointer ptrs = 
ctx.iteratePointers(/project/dependencies/dependency); 
ptrs.hasNext();) {

final Pointer ptr = ptrs.next();
dump((Node) ptr.getNode());
System.out.printf(declared by project with groupId 
'%s'%n, ctx.getValue(ptr.asPath() + /ancestor::project/groupId));

}
}

which yields output:

dependency
  groupIdorg.group/groupId
  artifactIdartifact-id/artifactId
  version2.6/version
/dependency

declared by project with groupId 'org.test'

Does this help?

Matt


On Mon, Apr 14, 2014 at 1:09 PM, John Casey jdca...@apache.org 
mailto:jdca...@apache.org wrote:


Hi all,

I'm trying to learn how to use JXPath with DOM in order to speed
up some code that uses a lot of xpath. I've seen blog posts
suggesting it's about twice as fast as JAXP's XPath processor...

The problem I'm running into is when I construct a JXPathContext
around a node down in the DOM tree, then try to select a node
elsewhere in the tree using the ancestor:: axis. I'm attaching a
sample XML file and unit test that shows what I'm trying to do.

I've run this through a debugger, and it appears that the
DOMNodePointer.getImmediateParent() doesn't even try to look at
the Node.getParentNode()...if it doesn't have a pre-existing
parent (from its ctor) then it just dumbly returns the null parent.

I haven't done enough research yet to know how to get
DOMNodePointer to populate its parent (using the public API, not
the nuts-and-bolts impl details), but in the attached example you
can see I try two approaches:

1. the naive approach, which is also the last one in the code.
IMO, this one should work!

2. a brute-force alternative, where JXPathContext instances for
each intermediate node are created to inherit in the right order,
all the way back to the document itself. From my partial reading
of the code, this should work even if the naive approach doesn't.

Neither of these works, though. Can someone shed some light on it,
or let me know if I've found a bug (seems like a common use case)...

Thanks,

-john

-- 
John Casey

GitHub - http://github.com/jdcasey


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
mailto:user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
mailto:user-h...@commons.apache.org




--
John Casey
---
GitHub:  https://github.com/jdcasey/
Twitter: http://twitter.com/buildchimp

Re: [JXPATH] Am I doing something stupid here?

2014-04-25 Thread John Casey



On 04/25/2014 12:42 PM, Matt Benson wrote:
Pointer is an interface that is considered part of the public API. 
Very possibly the intent could have been more elegantly expressed by 
using the NodePointer API, but this *would* be a case of relying on an 
implementation detail, as NodePointer is the Pointer implementation 
used by JXPathContextReferenceImpl.


Okay, so I need to read the docs more thoroughly. :)

Thanks for the help!



Matt


On Fri, Apr 25, 2014 at 12:39 PM, John Casey jdca...@commonjava.org 
mailto:jdca...@commonjava.org wrote:


Yep, that makes a certain kind of sense, though I guess I wouldn't
exactly call it intuitive. I can see how creating a new context
each time could be a bad idea (and very inefficient, I
suspect)...though it seems (to a newbie anyway) that the pointers
are an implementation detail that leak out in this case.

Or, maybe I just haven't read enough of the docs?

At any rate, thanks for your reply. Maybe once this project I'm
working on is done, I'll take a look at modernizing JXPath. It
does seem faster than the built-in JAXP stuff.

-john



On 04/25/2014 12:33 PM, Matt Benson wrote:

Hi, John. Sorry for the long delay.

  The original authors of JXPath are long gone, but from what I
can reconstruct the intent of nested JXPathContexts is only to
unify treatment of things like variables, namespaces, and at a
guess, functions. AFAICT your test case appears to have
overcomplicated the issue, although notably my alternative does
resort to some string concatentation to accomplish the same
apparent purpose of the test case. Certainly the whole JXPath
codebase could benefit from some modernization. In any event, I have:

@Test
public void anotherTest() throws Exception {
final InputStream is =

Thread.currentThread().getContextClassLoader().getResourceAsStream(jxpath/simple.pom.xml);

final Document document =
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is);

final JXPathContext ctx = JXPathContext.newContext(document);

// not sure why this was done, but I have preserved it
document.getDocumentElement().removeAttribute(xmlns);

for (@SuppressWarnings(unchecked)
IteratorPointer ptrs =
ctx.iteratePointers(/project/dependencies/dependency);
ptrs.hasNext();) {
final Pointer ptr = ptrs.next();
dump((Node) ptr.getNode());
System.out.printf(declared by project with groupId
'%s'%n, ctx.getValue(ptr.asPath() + /ancestor::project/groupId));
}
}

which yields output:

dependency
groupIdorg.group/groupId
artifactIdartifact-id/artifactId
  version2.6/version
/dependency

declared by project with groupId 'org.test'

Does this help?

Matt


On Mon, Apr 14, 2014 at 1:09 PM, John Casey jdca...@apache.org
mailto:jdca...@apache.org wrote:

Hi all,

I'm trying to learn how to use JXPath with DOM in order to
speed up some code that uses a lot of xpath. I've seen blog
posts suggesting it's about twice as fast as JAXP's XPath
processor...

The problem I'm running into is when I construct a
JXPathContext around a node down in the DOM tree, then try to
select a node elsewhere in the tree using the ancestor::
axis. I'm attaching a sample XML file and unit test that
shows what I'm trying to do.

I've run this through a debugger, and it appears that the
DOMNodePointer.getImmediateParent() doesn't even try to look
at the Node.getParentNode()...if it doesn't have a
pre-existing parent (from its ctor) then it just dumbly
returns the null parent.

I haven't done enough research yet to know how to get
DOMNodePointer to populate its parent (using the public API,
not the nuts-and-bolts impl details), but in the attached
example you can see I try two approaches:

1. the naive approach, which is also the last one in the
code. IMO, this one should work!

2. a brute-force alternative, where JXPathContext instances
for each intermediate node are created to inherit in the
right order, all the way back to the document itself. From my
partial reading of the code, this should work even if the
naive approach doesn't.

Neither of these works, though. Can someone shed some light
on it, or let me know if I've found a bug (seems like a
common use case)...

Thanks,

-john

-- 
John Casey

GitHub - http://github.com/jdcasey


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
mailto:user-unsubscr...@commons.apache.org

Re: [collections] Problems compiling w/gentoo

Re: [CSV] Wish: format-specific date generation

Re: [JXPATH] Am I doing something stupid here?

Re: [JXPATH] Am I doing something stupid here?

Re: [JXPATH] Am I doing something stupid here?

Re: [JXPATH] Am I doing something stupid here?

6 matches

Site Navigation

Mail list logo

Footer information