On 12/06/2011 02:33 PM, 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 using a default English based Ubuntu Linux 11.04 installation, language
therefore shouldn't make a difference (unless all of you are using an exotic
non-English based setup, which I doubt).
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.
Same for me. I'd love to be able to pinpoint this to a specific thing particular
only to my setup and document that. I'll vote +1 then for sure as otherwise the
release seems OK to me.
But for all I know right now this could just as easily happen with lots of other
end-users. And I also have no workaround/fix for it either, yet.
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
