-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's a shot in the dark, but what Java version were you using, Ate? My linux test (which went ok) used the following:
$ java -version java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) Marlon On 12/6/11 8:33 AM, Franklin, Matthew B. wrote: >> -----Original Message----- >> From: Ate Douma [mailto:[email protected]] >> Sent: Tuesday, December 06, 2011 8:20 AM >> To: [email protected] >> Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate >> >> On 12/06/2011 02:05 PM, Franklin, Matthew B. wrote: >>>> -----Original Message----- >>>> From: Ate Douma [mailto:[email protected]] >>>> Sent: Tuesday, December 06, 2011 8:00 AM >>>> To: [email protected] >>>> Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate >>>> >>>> On 12/06/2011 01:36 PM, Franklin, Matthew B. wrote: >>>>>> -----Original Message----- >>>>>> From: Ate Douma [mailto:[email protected]] >>>>>> Sent: Monday, December 05, 2011 7:16 PM >>>>>> To: [email protected] >>>>>> Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate >>>>>> >>>>>> On 12/05/2011 05:41 PM, Ate Douma wrote: >>>>>>> On 12/05/2011 04:39 PM, Mahadevan, Venkat wrote: >>>>>>>> I had the same issue, clearing the /tmp/rave DB files fixed it. >>>>>>> Just tried that myself but didn't make a difference. Same set of errors. >>>>>> >>>>>> I dived deeper into the problem and after a while I noticed what IMO is >>>>>> causing >>>>>> the problem. >>>>>> What I really don't understand is why nobody else seems to encounter >>>> this... >>>>>> >>>>>> What I see going wrong is that we have initialization data for persons in >>>> both >>>>>> rave-shindig *and* rave-portal... using (and reinitializing) the same >>>> 'person' >>>>>> sequence *and* the same person entity_id... >>>>>> That of course never can work if you use one and the same database >> and >>>> the >>>>>> same >>>>>> set of tables. >>>>>> >>>>>> Besides that, the person initialization done from rave-shindig >>>> initial_data.sql >>>>>> only uses a subset of the person attributes while the 'same' person >>>>>> initialization done from rave-portal initial_data.sql is using a >>>>>> different >>>>>> subset of the person attributes. They overlap partly but not wholly. >>>>> >>>>> The extra SQL artifact is my fault. I didn't remove it when I moved the >>>> Person to core. >>>>> >>>>>> >>>>>> At any rate, I think this part of the configuration is simply broken. >>>>>> When I deleted all person initialization as well move the >>>> person_association, >>>>>> groups and group_members initialization from rave-shindig >> initial_data.sql >>>> to >>>>>> the rave-portal initial_data.sql I finally got it working again. >>>>>> >>>>>> But, how could it possibly work for everyone else without such changes? >>>>> >>>>> I think I have the answer. The rave-shindig initial-data.sql file only >>>>> gets >>>> parsed and the statements executed if SELECT * FROM PERSON returns no >>>> rows or an exception that the table doesn't exist. What seems to be >>>> happening to you is that the rave-portal initial-data.sql is failing to >>>> execute >>>> properly, which in turn is executing the rave-shindig version. This is why >>>> everyone who has it working doesn't see the collision between the >>>> statements in the two SQL files. >>>> OK, I missed that check, or better said forgot about it. >>>> Make sense. However... it is failing on me, and always. And I did check it >> like >>>> 20x (while trying to find the culprit) as well against trunk. And every >>>> time I >>>> made sure to run $ rm /tmp/rave* first. So, running without any initial >>>> database. >>>> >>>> I do think the rave-shindig is loaded first though, before rave-portal >>>> (ROOT >>>> webapp always being initialized first), which them could explain this >> because >>>> rave-portal uses the check "SELECT * FROM WIDGET" to determine if the >> data >>>> initialization should be done... So, in that case it is logical both >>>> rave-shindig and rave-portal data initialization are executed. >>> >>> Maybe therein lies the issue. The portal context always starts for me >>> before >> the root (not intuitive nor potentially correct, but seems to be consistent >> in >> multiple environments). Therefore, I never see the issue, since by the time >> Shindig starts, the Person table is populated. >> OK. That might be the 'cause' then. >> >> But it still is puzzling why it always is initializing the ROOT context >> first on >> my machine. Which would make sense to me from a web server POV. >> But it clearly isn't always the case. Which makes it unreliable behavior to >> say >> the least. > > Is there anything in the language settings that could be changing the default > sort order? R comes after p, so it seems that tomcat may be trying to load > all of the applications in alphabetical order on the machines where it is > working... > >> >> I'm now unsure if I should vote +1 or -1 on this release. >> >> From a release process POV, disregarding execution, this release candidate >> seems valid to me. >> But I personally cannot use this release, nor the current trunk for that >> matter. >> So, to me this feels like a -1 on usability. > > IMO, if this were not isolated to some identifiable issue with your machine > configuration (language settings, etc) that we could post as a known issue > with the download, I would be inclined to vote -1 as well. However, if we > can figure out what the issue is and document it, then my personal vote will > be +1. > >> >> Just to be clear: regardless my vote, if you get a majority and +3 IPMC votes >> this release can be regarded successfully. > > That assumes we can get IPMC members to vote at all :) > >> >> Ate >> >>> >>> >>>> >>>>> >>>>> Not sure why you are getting the duplicate key exception on the >> sequence >>>> table unless the database is already there, but not populated. >>>>>> >>>>>> Alternatively, I can of course change the configuration by having rave- >>>> shindig >>>>>> and rave-portal point to two different databases (and then it works >> again >>>>>> too), >>>>>> but the whole point here IMO is leveraging the same database and the >>>> same >>>>>> model >>>>> >from both sides, right (RAVE-345 and sub tasks)? >>>>>> >>>>>> What am I doing different (other than simply extract and run the binary) >>>> from >>>>>> everyone else? >>>>> >>>>> Just for fun, I would double check that /tmp/rave_db.h2.db is not there >>>> when you run the demo binaries for the first time. Maybe the exception >> you >>>> posted to the list was on a second or third attempt in the same session and >> is >>>> just a mask of the real problem... >>>> That is not the case. >>>> I've tested this every time with first removing the database before >>>> starting >> up >>>> tomcat. >>>> >>>>> >>>>>> >>>>>> Ate >>>>>> >>>>>>> >>>>>>> Note that on Linux /tmp is cleared every time I reboot anyway, so I had >> a >>>>>>> "clean" /tmp to begin with. >>>>>>> >>>>>>> I still haven't had time to look more deeply into this, and will do so >>>>>>> later >>>>>>> this evening. But it would be good if everyone else (on Linux at least) >>>> could >>>>>>> check once more. >>>>>>> >>>>>>> The only thing I did was download the binary tar.gz, extract it at a >> random >>>>>>> location and executed $ bin/catalina.sh run from that location. >>>>>>> >>>>>>> Ate >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Venkat >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ate Douma [mailto:[email protected]] >>>>>>>> Sent: Monday, December 05, 2011 8:18 AM >>>>>>>> To: [email protected] >>>>>>>> Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate >>>>>>>> >>>>>>>> I still haven't had the time to review the candidate in detail, I >>>>>>>> expect >> to >>>>>>>> provide more feedback earliest late today / this evening. >>>>>>>> >>>>>>>> However, I did try to run the binary download and hit a problem right >>>>>> away: >>>>>>>> login doesn't seem to work anymore. >>>>>>>> That might be something specific to my environment, but seems odd. >>>>>>>> I will try to figure out what is causing the problem, but I did see >>>>>>>> some >>>>>>>> exceptions thrown in the console during startup: >>>>>>>> >>>>>>>> 11699 ravePersistenceUnit TRACE [main] openjpa.jdbc.SQL -<t >>>> 1730147382, >>>>>> conn >>>>>>>> 1904595916> executing stmnt 292713878 CREATE INDEX >>>>>> I_WDGTMNT_USER ON >>>>>>>> widget_comment (user_id) >>>>>>>> 11699 ravePersistenceUnit TRACE [main] openjpa.jdbc.SQL -<t >>>> 1730147382, >>>>>> conn >>>>>>>> 1904595916> [0 ms] spent >>>>>>>> ERROR: >>>>>>>> >>>>>> >>>> >> org.apache.rave.persistence.jpa.PopulatedLocalContainerEntityManagerFact >>>>>> ory - >>>>>>>> Database population has failed. It will be empty. >>>>>>>> java.lang.RuntimeException: SQL exception occurred loading data >> from >>>>>>>> initial_data.sql >>>>>>>> >>>>>>>> and: >>>>>>>> >>>>>>>> UPDATE RAVE_PORTAL_SEQUENCES SET seq_count = (seq_count + 1) >>>>>> WHERE seq_name = >>>>>>>> @portal_preference_seq; [23505-154] >>>>>>>> at >>>>>> >> org.h2.message.DbException.getJdbcSQLException(DbException.java:327) >>>>>>>> at org.h2.message.DbException.get(DbException.java:167) >>>>>>>> at org.h2.message.DbException.get(DbException.java:144) >>>>>>>> at >>>> org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:80) >>>>>>>> >>>>>>>> Anyway, it might be something trivial but right now I cannot yet give a >>>>>> vote. >>>>>>>> Not sure when Matt wants to wrap up this vote but maybe it might >> be >>>>>> good to wait >>>>>>>> a few hours up to a day more. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ate >>>>>>>> >>>>>>>> On 12/01/2011 12:30 AM, Franklin, Matthew B. wrote: >>>>>>>>> Discussion thread for vote on 0.6-incubating release candidate. >>>>>>>>> >>>>>>>>> Note, there were two staging repos created during the release >>>> process. I >>>>>> am >>>>>>>>> unsure why this happened, but I did have a network hiccup while >> the >>>>>> release >>>>>>>>> script was running, so maybe that was the issue. All of the artifacts >>>> appear >>>>>>>>> to have made it fine, but it would be good to have a second pair of >>>> eyes >>>>>>>>> check that. >>>>>>>>> >>>>>>>>> Also, I forgot to create a combined release with the updated master >>>> pom >>>>>>>>> containing the metadata that has Sean as a committer/PPMC >> member >>>>>> listed. >>>>>>>>> >>>>>>>>> For more information on the release process, checkout - >>>>>>>>> http://www.apache.org/dev/release.html >>>>>>>>> http://incubator.apache.org/guides/releasemanagement.html >>>>>>>>> >>>>>>>>> Some of the things to check before voting are: >>>>>>>>> - can you run the demo binaries >>>>>>>>> - can you build the contents of source-release.zip and svn tag >>>>>>>>> - do all of the staged jars/zips contain the required LICENSE, NOTICE >>>> and >>>>>>>>> DISCLAIMER files >>>>>>>>> - are all of the staged jars signed and the signature verifiable >>>>>>>>> - is the signing key in the project's KEYS file and on a public server >>>>>>>> >>>>>>> >>>>> >>> > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO3hsaAAoJEEfVXEODPFIDnpIH/2jgVl/22OehuiC51XGEYXLz NRR82cvLt4lEkHiZVEbbcYgfmN7YkVKVRSfawe3C1WVkOfhTIJMh2UdL5i4I+l7q WBLbpc9AelaH3DdFBQNFUA09/YyZ2Gm63Ry3Y8ulAeyxvR7oqdmItJRFSzCSb5W9 qVkmQXQXVQOoj2I2T/VNxwd9K7G9qv7xH6NsKBaxVQmf/EwBv3Mt8nlOZJkGXG43 t2B8oOVd8nli9pfsUkeBb707cNjiAGRJR6k+Zu40YjXjRpdWLDSoRk1Py7KwAFd8 mbi0lIH+L+O+mvH9oam6quYk0cnVHFlBIs3kNbpkO/EE06W9x8BS32lGD61ok+k= =0h7u -----END PGP SIGNATURE-----
