Re: [skalli-dev] Commit for bugs 347537, 347536
regarding the xstream behaviour - I don't really have a good explanation for that. Just a strange gut feeling:
What I've observed so far is that the default constructors haven't been called by xstream. Neither have field declarations with initializations been working (e.g. final String var = "Hello"). This led to the funny situation that those fields were NULL, which was kind of awkward.
It seemed to me that xstream is doing some really strange stuff, maybe using the java object de/serialization mechanism to create new object instances. But I never looked into that any closer. Obviously without bootdelegation, xstream can't do that anymore, so it relies on the default constructors. So adding them certainly was a good idea...
2011/6/7 Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx>
I submitted changes for the sample data and more missing import package statements. Those raised as with sample data in storagedir, data will be loaded during startup, which lead to missing import package statements regarding XML parser.
There was one very strange problem: when starting skalli with osgi.compatibility.bootdelegation=false, the xstream library will raise an exception that ProjectMember can not be instantiated.
I have no idea why it occures only in this OSGi framework mode. I've added a default constructor, and it seems to work fine.
The pom.xml file for the orbit feature is still missing.
See stacktrace (excerpt):
07.06.2011 11:52:42 INFO [org.eclipse.skalli.log] Loading models from /data/p/CodeHub/wsp-skalli-deploy/org.eclipse.skalli/org.eclipse.skalli.target/workdir/storage/Project
07.06.2011 11:52:42 INFO [org.eclipse.skalli.log] Loading /data/p/CodeHub/wsp-skalli-deploy/org.eclipse.skalli/org.eclipse.skalli.target/workdir/storage/Project/2f833ff4-20c2-4bc8-95ce-ceb06080a507.xml
com.thoughtworks.xstream.converters.ConversionException: Cannot construct org.eclipse.skalli.model.core.ProjectMember as it does not have a no-args constructor : Cannot construct org.eclipse.skalli.model.core.ProjectMember as it does not have a no-args constructor|---- Debugging information ----|message : Cannot construct org.eclipse.skalli.model.core.ProjectMember as it does not have a no-args constructor|cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException|cause-message : Cannot construct org.eclipse.skalli.model.core.ProjectMember as it does not have a no-args constructor|class : org.eclipse.skalli.model.core.Project|required-type : org.eclipse.skalli.model.core.ProjectMember|path : /entity-project/extensions/entity-people/leads/org.eclipse.skalli.model.core.ProjectMember|line number : 19|-------------------------------
com.thoughtworks.xstream.converters.reflection.ObjectAccessException: Cannot construct org.eclipse.skalli.model.core.ProjectMember as it does not have a no-args constructor
On Wed, Jun 1, 2011 at 1:10 PM, Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx>
On Wed, Jun 1, 2011 at 1:05 PM, Varwig, Britta <britta.varwig@xxxxxxx>
according to the testData:
I did not recognize that we now would have 2 places for testdata.
I expect both locations should N O T contain the same Test-Data.
My suggestion would be the following:
· For o.e.s.target/workdir :
UseCases: developer would like to start a Skalli with some example-testdata.
è It would be nice if a admin + guest and some projects are available (as in my patch)
UseCase: for product build
Which test data do we need here? Isn’t that more or less custom specific and should not contain any specific data like users and projects?.
At least I would say that the admin should only be available in the jetty configuration to show how you can configure him.
I would suggest to not add him in storge/Group/ xml files.
I suggest that customer run their own osgi scripts to setup the admin (osgi> skalli admin -add myCustomSpezificAdmin)
And there one Rest-api –configurations.
What do you think?
So: I will add your testdata to o.e.s.target/workdir.
I will remove the storage dir from o.e.s.feature/rootfiles/workdir
Thanks for your hint.
On Tue, May 31, 2011 at 10:36 AM, Varwig, Britta <britta.varwig@xxxxxxx> wrote:
I had a look into the change „ Add product export to Skalli” (commit-id 2626878b1c332fe1cfbfce36378a04738ab034bb) and found out that you added an admin user.
Had you seen that there is a pending bug from me with provides additional test data: https://bugs.eclipse.org/bugs/show_bug.cgi?id=346938 ( I am not a committer now and cant checkin L
@Jochen: Would you like to add that patch as well and merge with your changes?
We have two locations now, where testdata should be set:
o.e.s.target/workdir (for development)
o.e.s.feature/rootfiles/workdir (for product build)
I think it would make sense to put the testdata in both locations?
The pom.xml for the new project org.eclipse.skalli.orbit.feature for the maven build is still missing. But I think we can add that later.
Grr... I want to have a Review system ...
I only thought about Eclipse based product export, did not check for maven. I will add that too.
skalli-dev mailing list
skalli-dev mailing list