>-----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 >>>>>>> >>>>>> >>>> >>
