Nabble - Daisy - General

Re: Array of Links as a Daisy Document Field?

2009-11-09T06:29:18Z

On Mon, Nov 9, 2009 at 3:14 PM, John Stubing <jstubing@...> wrote:
> Hello, does anybody know how to create an array of links as a daisy document
> field?

Create a new field, choose type='link', then check the 'multivalue' checkbox?

I know if you set the field type to string you can later set that
> field to a string array, but it doesn't seem to work the same way for links
> (VariantKeys). Has anybody ever done such a thing?

It should work exactly the same. Note that you can only specify the
multivalue property
when creating a field (that's the same for strings and for links), you
can't change it once it's created.

If you really need to change it, create a new field, use a document
task to set the initial values (wrap the
current single-values in an array and set the new field) - search the
archives for code samples.

HTH,
Karel

>
> Thank you.
>
> - John
>
> _______________________________________________
> daisy community mailing list
> Professional Daisy support:
> http://outerthought.org/en/services/daisy/support.html
> mail to: daisy@...
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>
>

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

Array of Links as a Daisy Document Field?

2009-11-09T06:14:00Z

Hello, does anybody know how to create an array of links as a daisy document field? I know if you set the field type to string you can later set that field to a string array, but it doesn't seem to work the same way for links (VariantKeys). Has anybody ever done such a thing?

Thank you.

- John

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Created: (DSY-743) Editor for publication properties is broken

2009-10-26T05:41:21Z

Editor for publication properties is broken
-------------------------------------------

Key: DSY-743
URL: http://issues.cocoondev.org//browse/DSY-743
Project: Daisy
Type: Bug
Components: Daisy Books
Versions: 2.3
Reporter: Karel Vervaeke
Priority: Minor

See PublicationTypesFormHelper.java;
some of code refers to widgets named 'name' and 'value' and others refer to widgets named 'nameUnion', 'editor, 'type-editor', 'required',
resulting in NPE's here and there.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

Re: Question regarding the 255 character limit for a String Field type

2009-10-18T23:56:55Z

In general, when fields tend to get that long, you really should
consider using a part instead of a field. (Alternatively you can
consider a multivalue string field, but usually that's not a very nice
solution.)

If you want to go ahead changing the length limit, there are a number
of locations where Daisy would need to be chaged.

At the very minimum (just to patch your local installation),
- change the limit in the repository database, table thefields, column
stringvalue.
- in the daisy installation directory, change the limit imposed in
fieldtype_to_widgetdefinition.xsl.

HTH,
Karel

On Fri, Oct 16, 2009 at 8:42 PM, Alex Bleasdale <rhodlite78@...> wrote:

>
> Hi,
>
> I'm hoping someone can help,
>
> I've created several Field types as strings and wanted to know whether there
> is there any way to raise their 255 character limit?
>
> Thanks in advance,
> A
> --
> View this message in context: http://www.nabble.com/Question-regarding-the-255-character-limit-for-a-String-Field-type-tp25929926p25929926.html
> Sent from the Daisy - General mailing list archive at Nabble.com.
>
> _______________________________________________
> daisy community mailing list
> Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
> mail to: daisy@...
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>

Question regarding the 255 character limit for a String Field type

2009-10-16T11:12:08Z

Hi,

I'm hoping someone can help,

I've created several Field types as strings and wanted to know whether there is there any way to raise their 255 character limit?

Thanks in advance,
A

Matthew Barbarello is out of the office.

2009-10-16T04:46:32Z

I will be out of the office starting 10/16/2009 and will not return until
10/19/2009.

I will respond to your message when I return.

If this has to do with a Technical Publications issue, please contact
Thomas Connally.

For questions or comments on the Functional Requirements template, please
contact Dhruv Gupta and James Chan.

Thank you.

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Created: (DSY-742) Support for discrete facets on DATETIME expressions

2009-10-15T05:44:21Z

Support for discrete facets on DATETIME expressions
---------------------------------------------------

Key: DSY-742
URL: http://issues.cocoondev.org//browse/DSY-742
Project: Daisy
Type: New Feature
Components: Frontend - faceted browser
Versions: 2.3
Reporter: Karel Vervaeke
Priority: Minor
Fix For: 2.4

Currently, discrete datetime facets are not supported. Defining a discrete date facet on a datetime field (or daisy builtin property such as creationTime) doesn't do the trick:

When you define use type='DATE' on a datetime expression (in the facetednavdef), the facet is rendered fine, showing the timestamp ranges, but when you click on a range, you get this error:
Received exception from repository server.
Error performing query.
Invalid datetime value: "2009-10-15".
Unparseable date: "2009-10-15"

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Created: (DSY-741) Editor change: Linkfields are automatically contextualized to the branch and language of the containing document

2009-10-14T03:14:21Z

Editor change: Linkfields are automatically contextualized to the branch and language of the containing document
----------------------------------------------------------------------------------------------------------------

Key: DSY-741
URL: http://issues.cocoondev.org//browse/DSY-741
Project: Daisy
Type: Task
Reporter: Marc Portier
Priority: Minor

The editor in 2.3 introduced a new link-editor that changed behavior concerning the branch and language of the edited link-fields.

Since 2.3 apparently the editor will automatically replace any set branch and language values in link-fields to -1 if the values match those of the containing document.

For most practical cases this should not be a problem since clients are expected to always contextualize the -1 values with respect to the branch/language values of the containing document.
* See http://daisycms.org/javadoc/daisy/2.3/org/outerj/daisy/repository/Field.html#getValue()
* Also note the handy 2.3 addition: http://daisycms.org/javadoc/daisy/2.3/org/outerj/daisy/repository/Document.html#contextualiseVariantKey(org.outerj.daisy.repository.VariantKey)

(in fact we should consider adding a /**@see javadoc between those)

The effect for future branching/translating of the containing document seems useful, but occasionally not desired. Making it configurable (on the level of the site? the linkfield?) might make sense?

Additionally we probably should check the consistency of this behavior
* on linkfields that are hierarchical and/or multivalue
* on links that are embedded in the daisy-html

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

Re: daisy 2.0.1 hangs without error

2009-10-14T01:44:17Z

On Wed, Oct 14, 2009 at 9:35 AM, Bart Van den Abeele
<bvda@...> wrote:
> Hi,
>
> I don't have a good feeling that upgrading just will fix the issue. I doubt
> it seriously. You give no clear reason why that would fix this issue.
Two years of development time is no clear reason, but it is a very
good reason to at least try an upgrade and to see if it fixes your
problem.

> 2 years back we also needed a stable product. I would rather feel out why my
> repo hangs and act on that but without a clear indication of the error that
> is very hard. You talk about jmx-monitoring and other stuff. How do i set
> this up?
Google is your friend. Search for "jmx monitoring" and "garbage
collection logging" respectively to find out which properties.
Once jmx monitoring is enabled you need jconsole or another similar tool.

> My guess is that it has to do with the cache : 10k docs (these are
> the default right?) and only 256mb ram 100kb/document requires 1024mb ram.
> Wouldn't i get an error of this?
Not having enough ram and a cache size that is much smaller than the
actively consulted set of documents is indeed a possible cause for
problems. I'm not sure which errors you should get.
The wrapper scripts usually log to
${wikidata}/logs/daisy-wiki-service.log and
${repodata}/logs/daisy-repository-server-service.log.

You can also try obtaining a stackdump (using jstack or hitting
ctrl-break with the repository running in a console) when the
repository hangs.

> Any other thoughts?
not immediately. Just gather as much information to analyse as you
can. Be prepared to analyse most of it yourself, I have only limited
time
to assist you on the mailing list.

> Where can i locate the logging of the wrapper-scripts?
The location is described here:
http://www.daisycms.org/daisydocs-2_3/admin/service/330-cd.html

> My college's are working hard with my product and the hangs are far to
> frequent to work fluently. It is starting to annoy them (and me). The
> java-version is 1.6.0.14. I hope we can resolve this issue soon.
As do I

regards,
Karel
_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

Re: daisy 2.0.1 hangs without error

2009-10-14T00:34:21Z

Hi,

I don't have a good feeling that upgrading just will fix the issue. I doubt it seriously. You give no clear reason why that would fix this issue. 2 years back we also needed a stable product. I would rather feel out why my repo hangs and act on that but without a clear indication of the error that is very hard. You talk about jmx-monitoring and other stuff. How do i set this up? My guess is that it has to do with the cache : 10k docs (these are the default right?) and only 256mb ram 100kb/document requires 1024mb ram. Wouldn't i get an error of this? Any other thoughts? Where can i locate the logging of the wrapper-scripts?

My college's are working hard with my product and the hangs are far to frequent to work fluently. It is starting to annoy them (and me). The java-version is 1.6.0.14. I hope we can resolve this issue soon.

Met vriendelijke groeten,
Bart Van den Abeele
Email: bvda@...
Helpdesk : +32 (09) 389 0560
Persoonlijk : +32 (09) 389 0564

Karel Vervaeke schreef:

Daisy 2.0.1 is almost 2 and a half years old.
The *most cost-effective way* to solve this would be to try upgrading
to a more recent Daisy version.

Then again, if you insist on finding the problem, there are lots of
things you can do to try to locate the problem (jmx monitoring,
logging on application, jvm (gc!) and os level, ...)
Did you check the logs of the wrapper scripts btw?  There should be at
least some information of the daisy instance hanging.
You are using the wrapper scripts, right?

We recently had some hanging problems, they were solved by changing
the jdk version. (upgraded from java -1.6.0.07 to java-1.6.0.16)

HTH,
Karel


On Tue, Oct 6, 2009 at 11:26 AM, Bart Van den Abeele
bvda@... wrote:

Hi,

I have several daisy-instances running (20+).  They are version 2.0.1.
Every week i have to restart daisy on several servers.  When i look in the
logs i get no message about the shutdown, i see no special exceptions.  I
look in data-dir/logs.  This is very annoying and it gives no good image of
the product to customers.  What can be done to improve this?

--
Met vriendelijke groeten,
Bart Van den Abeele
Email: bvda@...
Helpdesk : +32 (09) 389 0560
Persoonlijk : +32 (09) 389 0564

**** DISCLAIMER ****
http://www.schaubroeck.be/maildisclaimer.htm

_______________________________________________
daisy community mailing list
Professional Daisy support:
http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

**** DISCLAIMER ****
http://www.schaubroeck.be/maildisclaimer.htm

[JIRA] Created: (DSY-740) namespace error when upgrading empty daisy 2.2 repository to daisy 2.3

2009-10-13T05:02:21Z

namespace error when upgrading empty daisy 2.2 repository to daisy 2.3
----------------------------------------------------------------------

Key: DSY-740
URL: http://issues.cocoondev.org//browse/DSY-740
Project: Daisy
Type: Bug
Components: Repository
Versions: 2.3
Environment: Linux, Mysql 5.0, Daisy 2.3
Reporter: Tom Brusselle
Priority: Minor

When trying to add the first site to daisy that was recently upgraded from version 2.2 to 2.3, we got the following error message:
"Namespace 'www' is not managed by the repository. Could not generate an id. To solve this try making the namespace managed"
This 2.2 daisy was empty (no documents) when i upgraded it, and i think that was what caused problem.

When looking in the database what could cause this, i noticed that the "document_sequence" table was empty, where in a fresh daisy 2.3 installation, after starting the repository, a record (maxid=0, ns_id=1) already exists.
After manualy adding this record in the database of the upgraded daisy, it was possible to add a wiki site (and new documents).

I think the reason is that the database update script daisy-2_2-to-2_3.sql doesn't seem to account for the possibility that the table document_sequence might be empty. The relevant lines in the script are the following:

# Set the document sequence for the default namespace
update document_sequence set ns_id = 1;

If the table is empty, this wil not add a record, but apparently daisy 2.3 needs there to be a record with ns_id=1 to add a document.
So the database script should probably check for this condition, and if there is no record present in the table document_sequence, a record (maxid=0, ns_id=1) should be added.

it's probably an unlikely situation that someone has an empty daisy 2.2 instance and wants to update that to daisy 2.3, instead of installing a fresh daisy 2.3. So this is probably a minor issue.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Resolved: (DSY-739) Table formatting can not be saved

2009-10-12T01:33:21Z

[ http://issues.cocoondev.org//browse/DSY-739?page=all ]

Karel Vervaeke resolved DSY-739:
--------------------------------

Fix Version: 2.4
Resolution: Fixed

Fixed here: http://svn.daisycms.org/viewsvn/daisy?view=revision&revision=5352

> Table formatting can not be saved
> ---------------------------------
>
> Key: DSY-739
> URL: http://issues.cocoondev.org//browse/DSY-739
> Project: Daisy
> Type: Bug
> Components: Frontend - doc editing - HTML
> Versions: 2.4
> Environment: Firefox
> Reporter: Karel Vervaeke
> Priority: Minor
> Fix For: 2.4

>
> On save, the table width & class annotations disappear.
> Probably due to the HTMLCleaner being too agressive.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-739) Table formatting can not be saved

2009-10-12T00:41:21Z

[ http://issues.cocoondev.org//browse/DSY-739?page=comments#action_13845 ]

Karel Vervaeke commented on DSY-739:
------------------------------------

I'm experiencing quite the opposite (when building from trunk)

- html cleaner builds fine, unit test runs fine
- problem still persists.

Just to make sure we are talking about the same things:
by unit tests, I mean the unit tests included under services/htmlcleaner, not the integration tests under repository/test.

Can you verify that you don't accidentally have two htmlcleaner jars in WEB-INF/lib?

访问我的Netlog个人主页

2009-10-10T01:37:28Z

访问我的Netlog个人主页

如果你不想再接接收到来自朋友的任何邀请，则请点击此处.

夏伟
男生 - 25岁
北京

嗨！

我创建了Netlog的个人主页，包括了我的图片、视频影片、博客和参与的活动，我希望添加你为朋友，来将这些展示给你看！你首先需要在Netlog上注册！
然后你就可以创造自己的个人主页了。


		看一看

祝好,
夏伟

上方的按钮没有完全显示出来吗？
点击此处，或者复制下面，在浏览器地址栏中的链接。
http://zh.netlog.com/go/mailurl/type=invite_1&mailid=66999204&id=6&url=-L2dvL3JlZ2lzdGVyL2lkPTg3MTU5MDM1NiZpPWg5NQ__

如果你不想再接接收到来自朋友的任何邀请，则请点击此处.

Netlog NV/SA - E. Braunplein 18. B-9000 Gent. Belgium. .
BE0859635972 - abuse-zh@...

[JIRA] Commented: (DSY-739) Table formatting can not be saved

2009-10-09T02:39:21Z

[ http://issues.cocoondev.org//browse/DSY-739?page=comments#action_13844 ]

Matthias Bauer commented on DSY-739:
------------------------------------

I've had the same experience w/ 2.4-dev-r5327 a few days ago.

To me it looks like, the html-cleaner is not building correctly. So, there might be an old jar w/i the snapshot-builds.

I've tried to rebuild it manually. Compiling works fine. But the unit-tests fail due to some excess space characters in the cleaner output. Thus, the jar isn't created.

I've disabled the test to get the jar. I deployed it and it works fine.

[JIRA] Created: (DSY-739) Table formatting can not be saved

2009-10-08T09:11:21Z

Table formatting can not be saved
---------------------------------

Key: DSY-739
URL: http://issues.cocoondev.org//browse/DSY-739
Project: Daisy
Type: Bug
Components: Frontend - doc editing - HTML
Versions: 2.4
Environment: Firefox
Reporter: Karel Vervaeke
Priority: Minor

On save, the table width & class annotations disappear.
Probably due to the HTMLCleaner being too agressive.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

Re: daisy 2.0.1 hangs without error

2009-10-06T02:50:17Z

Daisy 2.0.1 is almost 2 and a half years old.
The *most cost-effective way* to solve this would be to try upgrading
to a more recent Daisy version.

Then again, if you insist on finding the problem, there are lots of
things you can do to try to locate the problem (jmx monitoring,
logging on application, jvm (gc!) and os level, ...)
Did you check the logs of the wrapper scripts btw? There should be at
least some information of the daisy instance hanging.
You are using the wrapper scripts, right?

We recently had some hanging problems, they were solved by changing
the jdk version. (upgraded from java -1.6.0.07 to java-1.6.0.16)

HTH,
Karel

On Tue, Oct 6, 2009 at 11:26 AM, Bart Van den Abeele
<bvda@...> wrote:

> Hi,
>
> I have several daisy-instances running (20+). They are version 2.0.1.
> Every week i have to restart daisy on several servers. When i look in the
> logs i get no message about the shutdown, i see no special exceptions. I
> look in data-dir/logs. This is very annoying and it gives no good image of
> the product to customers. What can be done to improve this?
>
> --
> Met vriendelijke groeten,
> Bart Van den Abeele
> Email: bvda@...
> Helpdesk : +32 (09) 389 0560
> Persoonlijk : +32 (09) 389 0564
>
> **** DISCLAIMER ****
> http://www.schaubroeck.be/maildisclaimer.htm
>
> _______________________________________________
> daisy community mailing list
> Professional Daisy support:
> http://outerthought.org/en/services/daisy/support.html
> mail to: daisy@...
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>
>

daisy 2.0.1 hangs without error

2009-10-06T02:25:06Z

Hi,

I have several daisy-instances running (20+). They are version 2.0.1. Every week i have to restart daisy on several servers. When i look in the logs i get no message about the shutdown, i see no special exceptions. I look in data-dir/logs. This is very annoying and it gives no good image of the product to customers. What can be done to improve this?

--
Met vriendelijke groeten,
Bart Van den Abeele
Email: bvda@...
Helpdesk : +32 (09) 389 0560
Persoonlijk : +32 (09) 389 0564

**** DISCLAIMER ****
http://www.schaubroeck.be/maildisclaimer.htm

[JIRA] Resolved: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-05T05:44:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=all ]

Karel Vervaeke resolved DSY-738:
--------------------------------

Resolution: Invalid

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-05T05:23:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13843 ]

Bart Van den Abeele commented on DSY-738:
-----------------------------------------

thx! i was still dependant to daisy-2.0.1.

This issue can be clossed.

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T08:09:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13842 ]

Karel Vervaeke commented on DSY-738:
------------------------------------

Depends on what's causing the issue.

* check the version number in your build files
* run find . -name "daisy*.jar" in your build directory (and delete the offending jars)

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T07:54:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13841 ]

Bart Van den Abeele commented on DSY-738:
-----------------------------------------

what is the fix then for this issue?

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T07:45:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13840 ]

Karel Vervaeke commented on DSY-738:
------------------------------------

addendum: The exception comes from the *remote* implementation.
Even though the repository may be running r5342, your code may accidentally be using an older daisy remote implementation.
Coming to mind: for webapps, you may accidentally have old jars in your WEB-INF/lib folder (even if your ant/maven/whatever build script is copying the newer jars correctly, classes from older jars may take precedence in the classloader.

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T07:39:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13839 ]

Karel Vervaeke commented on DSY-738:
------------------------------------

Are you sure you are running that Daisy version?

The stacktrace says:
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.instantiateVersion(RemoteDocumentStrategy.java:415)

However, daisy-2.4-dev-r5342 does not contain code at line 415 of said file.

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T07:01:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13838 ]

Bart Van den Abeele commented on DSY-738:
-----------------------------------------

I get this exception when i execute myDoc.getLastVersion() after the myDoc.save() statement. myDoc.getLastVerion() doesn't return null but an excpetion!

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T06:59:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13837 ]

Bart Van den Abeele commented on DSY-738:
-----------------------------------------

When i execute myDoc.getLastVersion() i get next exception :

java.lang.NullPointerException
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.instantiateVersion(RemoteDocumentStrategy.java:415)
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.loadShallowVersions(RemoteDocumentStrategy.java:389)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.loadVersions(DocumentVariantImpl.java:931)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getVersions(DocumentVariantImpl.java:915)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getLastVersion(DocumentVariantImpl.java:881)
at org.outerj.daisy.repository.commonimpl.DocumentImpl.getLastVersion(DocumentImpl.java:450)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.mapCommonSimpleProperties(DigidocumentDetailMapper.java:118)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.mapDigidocumentCommon(DigidocumentDetailMapper.java:107)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.toObject(DigidocumentDetailMapper.java:69)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.toObject(DigidocumentDetailMapper.java:1)
at be.schaubroeck.daisy.RepositoryTemplate$1.doExecute(RepositoryTemplate.java:240)
at be.schaubroeck.daisy.RepositoryTemplate.execute(RepositoryTemplate.java:67)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:194)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:139)
at be.schaubroeck.digidoc.dao.daisy.DaisyDigidocumentDAO.insert(DaisyDigidocumentDAO.java:390)
at be.schaubroeck.digidoc.dao.DigidocumentDAOITest.testNewInsertUpdateDeleteAkte(DigidocumentDAOITest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase.java:76)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
java.lang.NullPointerException
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.instantiateVersion(RemoteDocumentStrategy.java:415)
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.loadShallowVersions(RemoteDocumentStrategy.java:389)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.loadVersions(DocumentVariantImpl.java:931)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getVersions(DocumentVariantImpl.java:915)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getLastVersion(DocumentVariantImpl.java:881)
at org.outerj.daisy.repository.commonimpl.DocumentImpl.getLastVersion(DocumentImpl.java:450)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.mapCommonSimpleProperties(DigidocumentDetailMapper.java:118)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.mapDigidocumentCommon(DigidocumentDetailMapper.java:107)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.toObject(DigidocumentDetailMapper.java:69)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.toObject(DigidocumentDetailMapper.java:1)
at be.schaubroeck.daisy.RepositoryTemplate$1.doExecute(RepositoryTemplate.java:240)
at be.schaubroeck.daisy.RepositoryTemplate.execute(RepositoryTemplate.java:67)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:194)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:139)
at be.schaubroeck.digidoc.dao.daisy.DaisyDigidocumentDAO.insert(DaisyDigidocumentDAO.java:390)
at be.schaubroeck.digidoc.dao.DigidocumentDAOITest.testNewInsertUpdateDeleteAkte(DigidocumentDAOITest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase.java:76)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
java.lang.NullPointerException
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.instantiateVersion(RemoteDocumentStrategy.java:415)
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.loadShallowVersions(RemoteDocumentStrategy.java:389)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.loadVersions(DocumentVariantImpl.java:931)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getVersions(DocumentVariantImpl.java:915)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getLastVersion(DocumentVariantImpl.java:881)
at org.outerj.daisy.repository.commonimpl.DocumentImpl.getLastVersion(DocumentImpl.java:450)
at be.schaubroeck.daisy.RepositoryTemplate$1.doExecute(RepositoryTemplate.java:234)
at be.schaubroeck.daisy.RepositoryTemplate.execute(RepositoryTemplate.java:67)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:194)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:139)
at be.schaubroeck.digidoc.dao.daisy.DaisyDigidocumentDAO.insert(DaisyDigidocumentDAO.java:390)
at be.schaubroeck.digidoc.dao.DigidocumentDAOITest.testDocumentNotFoundException(DigidocumentDAOITest.java:244)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase.java:76)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T06:57:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13836 ]

Bart Van den Abeele commented on DSY-738:
-----------------------------------------

simmulation of code :

myRepo.createDocument(docName, docType, Language.DEFAULT_LANGUAGE_NAME, Branch.MAIN_BRANCH_NAME);

document.setName(digidocument.getDocumentName());
String oldDocumentType = schemaDAO.getDocumentType(document.getDocumentTypeId());
String newDocumentType = digidocument.getDocumentType();
if (!oldDocumentType.equals(newDocumentType))
{
Fields fields = document.getFields();
for (Field field : fields.getArray())
{
document.deleteField(field.getTypeId());
}
document.changeDocumentType(newDocumentType);
}
modifyCommonSimpleProperties(digidocument, document);
modifyUnknownFields(digidocument, document);
modifyPictures(digidocument, document);

myDoc.save(validate);

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T06:51:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13835 ]

Bart Van den Abeele commented on DSY-738:
-----------------------------------------

We have written our own framework around the daisy-api to avoid boiler-plate. Therefor its very difficult to post what exactly happens. I have a stacktrace. Does this tell you more?

2009-10-01 15:49:25 WARN: Could not load properties from URL [file:////home/bvda/sources/digidoc-all/digidoc-server/notexistingdigidoc-server.properties]: /home/bvda/sources/digidoc-all/digidoc-server/notexistingdigidoc-server.properties (Bestand of map bestaat niet)
java.lang.NullPointerException
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.instantiateVersion(RemoteDocumentStrategy.java:415)
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.loadShallowVersions(RemoteDocumentStrategy.java:389)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.loadVersions(DocumentVariantImpl.java:931)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getVersions(DocumentVariantImpl.java:915)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getLastVersion(DocumentVariantImpl.java:881)
at org.outerj.daisy.repository.commonimpl.DocumentImpl.getLastVersion(DocumentImpl.java:450)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.mapCommonSimpleProperties(DigidocumentDetailMapper.java:118)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.mapDigidocumentCommon(DigidocumentDetailMapper.java:107)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.toObject(DigidocumentDetailMapper.java:69)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.toObject(DigidocumentDetailMapper.java:1)
at be.schaubroeck.daisy.RepositoryTemplate$1.doExecute(RepositoryTemplate.java:240)
at be.schaubroeck.daisy.RepositoryTemplate.execute(RepositoryTemplate.java:67)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:194)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:139)
at be.schaubroeck.digidoc.dao.daisy.DaisyDigidocumentDAO.insert(DaisyDigidocumentDAO.java:390)
at be.schaubroeck.digidoc.dao.DigidocumentDAOITest.testNewInsertUpdateDeleteAkte(DigidocumentDAOITest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase.java:76)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
java.lang.NullPointerException
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.instantiateVersion(RemoteDocumentStrategy.java:415)
at org.outerj.daisy.repository.clientimpl.RemoteDocumentStrategy.loadShallowVersions(RemoteDocumentStrategy.java:389)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.loadVersions(DocumentVariantImpl.java:931)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getVersions(DocumentVariantImpl.java:915)
at org.outerj.daisy.repository.commonimpl.DocumentVariantImpl.getLastVersion(DocumentVariantImpl.java:881)
at org.outerj.daisy.repository.commonimpl.DocumentImpl.getLastVersion(DocumentImpl.java:450)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.mapCommonSimpleProperties(DigidocumentDetailMapper.java:118)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.mapDigidocumentCommon(DigidocumentDetailMapper.java:107)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.toObject(DigidocumentDetailMapper.java:69)
at be.schaubroeck.digidoc.dao.daisy.DigidocumentDetailMapper.toObject(DigidocumentDetailMapper.java:1)
at be.schaubroeck.daisy.RepositoryTemplate$1.doExecute(RepositoryTemplate.java:240)
at be.schaubroeck.daisy.RepositoryTemplate.execute(RepositoryTemplate.java:67)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:194)
at be.schaubroeck.daisy.RepositoryTemplate.save(RepositoryTemplate.java:139)
at be.schaubroeck.digidoc.dao.daisy.DaisyDigidocumentDAO.insert(DaisyDigidocumentDAO.java:390)
at be.schaubroeck.digidoc.dao.DigidocumentDAOITest.testNewInsertUpdateDeleteAkte(DigidocumentDAOITest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase.java:76)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T06:42:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13834 ]

Bart Van den Abeele commented on DSY-738:
-----------------------------------------

I have series of tests. With the previous version of daisy (2.0.1) this test succeded. When i upgraded the test failes. So i'm sure it's not a problem in our code. I'll look up the exact code and will post what happens. We use daisy-2.4-dev-r5342.

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T06:32:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13833 ]

Karel Vervaeke commented on DSY-738:
------------------------------------

It's probably nothing but I'm pointing it out to make sure:
in your original problem description your variable is called "document" except for just once ("myDoc").
This wouldn't be the problem in your actual code would it? :)

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[JIRA] Commented: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T06:30:21Z

[ http://issues.cocoondev.org//browse/DSY-738?page=comments#action_13832 ]

Karel Vervaeke commented on DSY-738:
------------------------------------

I can't reproduce it - getLastVersion() doesn't return null for me.

To test it, I added this to AbstractDocumentTestCase (after line 156)
assertNotNull("document.getLastVersion() should not be null after saving", document1.getLastVersion());

(the test now essentially reads:
doc = repo.createDocument(...)
doc.setField(...)
doc.setPart(....)
doc.save();
assertNotNull(..., doc.getLastVersion());

The local and remote implementations both work fine.
Are there any factors that might give another result on your environment? Can you run the tests (with the added line) or create a daisy-js file in which you demonstrate that the problem occurs?

> document.getLastVersion() should not return null for saved documents.
> ---------------------------------------------------------------------
>
> Key: DSY-738
> URL: http://issues.cocoondev.org//browse/DSY-738
> Project: Daisy
> Type: Bug
> Versions: 2.4
> Reporter: Bart Van den Abeele

>
> > I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> > I notice that document.getLastVersion() returns null after i execute
> > myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> > get the creation date. Because this returns null now, i get a
> > null-pointer-exception (document.getLastVersion().getCreated()). Is this
> > supposed to return null? Why has the behaviour changed? Am i safe to use
> > "document.getCreated()" instead?
> Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

Re: login failed via wiki & retry

2009-10-01T06:19:11Z

Daisy has behaved like this since a good number of versions AFAIK (at
least since version 2.1, probably longer).
The reason for the login menu not being rendered is a technical one:
Whenever you do a POST request and there is an error, the login, roles
and site switching links made unavailable.
These links send you to a page that redirects you back to the original
page (e.g. http://.../login?returnTo={whereyoucamefrom}
Because you can only redirect browsers by making them do a new GET
request, you would essentially be sending a user to a url
which does not necessarily support GET requests.

I agree that there are more elegant solutions (rendering a 'back' link
would be a good start), feel free to create another jira issue :)

Regards,
Karel

On Thu, Oct 1, 2009 at 1:57 PM, Bart Van den Abeele <bvda@...> wrote:

> Hi,
>
> When i upgraded to 2.4, the first thing i hoped to have changed was the
> login via the wiki. When you enter a wrong pasword, you are send to an
> error-page. When you try to press on login on that page, nothing happens.
> I want to be able to login on that page. Now i have to press on a site and
> then i can login again. Will this be resolved in 2.4?
>
> --
> Met vriendelijke groeten,
> Bart Van den Abeele
> Email: bvda@...
> Helpdesk : +32 (09) 389 0560
> Persoonlijk : +32 (09) 389 0564
>
> **** DISCLAIMER ****
> http://www.schaubroeck.be/maildisclaimer.htm
>
> _______________________________________________
> daisy community mailing list
> Professional Daisy support:
> http://outerthought.org/en/services/daisy/support.html
> mail to: daisy@...
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>
>

login failed via wiki & retry

2009-10-01T04:57:36Z

Hi,

When i upgraded to 2.4, the first thing i hoped to have changed was the login via the wiki. When you enter a wrong pasword, you are send to an error-page. When you try to press on login on that page, nothing happens. I want to be able to login on that page. Now i have to press on a site and then i can login again. Will this be resolved in 2.4?

--
Met vriendelijke groeten,
Bart Van den Abeele
Email: bvda@...
Helpdesk : +32 (09) 389 0560
Persoonlijk : +32 (09) 389 0564

**** DISCLAIMER ****
http://www.schaubroeck.be/maildisclaimer.htm

[JIRA] Created: (DSY-738) document.getLastVersion() should not return null for saved documents.

2009-10-01T04:53:21Z

document.getLastVersion() should not return null for saved documents.
---------------------------------------------------------------------

Key: DSY-738
URL: http://issues.cocoondev.org//browse/DSY-738
Project: Daisy
Type: Bug
Versions: 2.4
Reporter: Bart Van den Abeele

> I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> I notice that document.getLastVersion() returns null after i execute
> myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> get the creation date. Because this returns null now, i get a
> null-pointer-exception (document.getLastVersion().getCreated()). Is this
> supposed to return null? Why has the behaviour changed? Am i safe to use
> "document.getCreated()" instead?

Kabouter Wesley ;-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

Re: change api 2.0.1 -> 2.4 document.getLastVersion() returns null after creation new document

2009-10-01T02:00:32Z

document.getLastVersion() should not return null for saved documents.
That's a bug you found there.
If you would be so kind to file a bug report (issues.cocoondev.org)
I'll have it fixed before you can say "Kabouter Wesley" (give or take
a day) ;-)

document.getCreated() and document.getLastVersion().getCreated() are
definitely not the same, and
are not even guaranteed to be identical for entirely new documents.
You should not depend on the behaviour.

As a workaround, I suggest you use
document.getVersion(document.getLastVersionId()) or re-fetch the
document before calling document.getLastVersion().

HTH,
Karel

On Wed, Sep 30, 2009 at 2:08 PM, Bart Van den Abeele
<bvda@...> wrote:

> Hi,
>
> I am switching from daisy 2.0.1 to 2.4. I have used the api intensively.
> I notice that document.getLastVersion() returns null after i execute
> myDoc.save(validate); for a new document. In 2.0.1 i used this function to
> get the creation date. Because this returns null now, i get a
> null-pointer-exception (document.getLastVersion().getCreated()). Is this
> supposed to return null? Why has the behaviour changed? Am i safe to use
> "document.getCreated()" instead?
>
> --
> Met vriendelijke groeten,
> Bart Van den Abeele
> Email: bvda@...
> Helpdesk : +32 (09) 389 0560
> Persoonlijk : +32 (09) 389 0564
>
> **** DISCLAIMER ****
> http://www.schaubroeck.be/maildisclaimer.htm
>
> _______________________________________________
> daisy community mailing list
> Professional Daisy support:
> http://outerthought.org/en/services/daisy/support.html
> mail to: daisy@...
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>
>