PrettyPrinter interface makes it hard/impossible to tweak the pretty printing about jackson-core HOT 10 CLOSED

This can not be changed: number of elements is not known when writeStartObject() is called; it is also known once elements have been output. So you will need to figure out another way to achieve the same result.

from jackson-core.

Unfortunately I was thinking that might be the reason. Thanks for the (quick) answer.

from jackson-core.

No problem -- unfortunately it is a hard limitation. I hope you can figure out alternative way to do this.

from jackson-core.

i've been writing my own prettyprinter and i encountered similar issue.

actually, there seem to be a problem with the writeEndObject().
it is calling :
...
_writeContext = _writeContext.getParent();
if (_cfgPrettyPrinter != null) {
_cfgPrettyPrinter.writeEndObject(this, _writeContext.getEntryCount());

therefore, the supplied entry count is incorrect.
i suspect we should restore the write context once the writing is done (see #writeEndArray ())

i've checked at the trunk and code is still exhibiting the same behavior.
is it possible to re-open the issue to perform the fix ?

PS: i'm using json resources in test cases and was encountering false errors because of this behavior when comparing results with resources contents.

from jackson-core.

Ok, it does look like entry count should be taken from the open context. Will reopen.

from jackson-core.

tatu,

btw: i'm using maven to perform builds. do you publish patches on the maven
repositories?

thank you / kiitos

On Mon, Jun 11, 2012 at 7:56 PM, Tatu Saloranta <
[email protected]

wrote:

Ok, it does look like entry count should be taken from the open context.
Will reopen.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

from jackson-core.

Hi there! (and "ole hyva!")

I occasionally publish snapshots to Sonatype Maven OSS repository, whenever someone requests them.
But there is no automated nightly build system.

from jackson-core.

Fixed for 1.9.8, 2.0.3 and 2.1; was as simple as moving context change after output.

from jackson-core.

thank you, tatu.

have a good day.

ps: how do you decide when you do release the code ? time-based (ie: twice
a quarter) ? depending on volume of changes ? depending on a feature
completion ?

On Tue, Jun 12, 2012 at 8:12 AM, Tatu Saloranta <
[email protected]

wrote:

Fixed for 1.9.8, 2.0.3 and 2.1; was as simple as moving context change
after output.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

from jackson-core.

No strict criteria for patch releases, i.e. "when I feel like it" or "when enough users ask for a release". Will try to consider both time and number of bugs; no point releasing a version with just one fix usually; so with 3-4 fixes, and at least 1 month between seems a typical interval.

For major/minor releases I try to figure out a rough scope for release, usually 1-2 months after I actually start implementing new features. This is just so that I resist the urge to keep on piling things up; it is good to have 2 or 3 minor releases per year, as work involved for these is bigger than for patches.

from jackson-core.