Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

[08:02:01 CST(-0600)] * deuce (n=deuce@ip68-110-100-205.ph.ph.cox.net) has joined ##uportal
[09:13:02 CST(-0600)] * deuce (n=deuce@ip68-110-100-205.ph.ph.cox.net) has joined ##uportal
[09:18:37 CST(-0600)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:26:31 CST(-0600)] * deuce_ (n=deuce@ip70-190-171-187.ph.ph.cox.net) has joined ##uportal
[10:56:50 CST(-0600)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[10:58:16 CST(-0600)] <deuce_> eric
[10:59:47 CST(-0600)] <EricDalquist> hey
[11:00:18 CST(-0600)] <deuce_> expert spring mvc and web flow .. by Seth Ladd
[11:00:30 CST(-0600)] <EricDalquist> just looking at that on amazon, thanks (smile)
[11:00:37 CST(-0600)] <deuce_> cool (smile)
[11:00:54 CST(-0600)] <EricDalquist> off to a meeting!
[11:00:58 CST(-0600)] <deuce_> peace
[11:31:51 CST(-0600)] * dmccallum (n=dmccallu@plmomibas02-lo10-a444.plmomi.tds.net) has joined ##uportal
[13:06:54 CST(-0600)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[13:49:47 CST(-0600)] * deuce_ (n=deuce@ip70-190-171-187.ph.ph.cox.net) has joined ##uportal
[13:52:06 CST(-0600)] * agherna (n=argherna@singularity.ci.uiuc.edu) has joined ##uportal
[13:52:50 CST(-0600)] * agherna (n=argherna@singularity.ci.uiuc.edu) has left ##uportal
[14:06:19 CST(-0600)] * peterk (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[14:10:21 CST(-0600)] <peterk> Guys, what's the status of migration to SVN and subsequent move to maven? I remember at the status meeting someone mentioned that we needed to reach agreement with JASIG folks regarding SVN.
[14:19:10 CST(-0600)] * agherna (n=argherna@singularity.ci.uiuc.edu) has joined ##uportal
[15:13:31 CST(-0600)] <dmccallum> peterk, the SVN move has sort of stalled. i sent an email to the clearinghouse list a few weeks ago with the changes i wanted to make to apache config so we could re-use our existing commercial cert, but i didn't get any feedback and haven't followed up
[15:14:13 CST(-0600)] <dmccallum> i wonder if its something we really want to bite off for RC1 or would it just be so much extra noise?
[15:15:07 CST(-0600)] <peterk> I think the main argument for it is that we we'll have the stage set for further development, which is something we really want to do to involve community as much as possible after RC1
[15:15:49 CST(-0600)] <peterk> getting it into SVN and on maven would allow gradual development from then on
[15:18:20 CST(-0600)] <dmccallum> i'm willing to help with the SVN effort. i think it'd be a good idea if Eric or somebody else with more intimate knowledge of that hosting env (and appropriate group membership) took a look at the proposed configuration. i can re-post my original note to the clearinghouse list.
[15:19:09 CST(-0600)] <dmccallum> in theory, the switch to SVN really shouldn't be too painful at all
[15:20:11 CST(-0600)] <dmccallum> peterk, i was wondering if i could get some clarification on http://www.ja-sig.org/issues/browse/UPT-99
[15:20:59 CST(-0600)] <dmccallum> specifically, is this something that we really want hibernate taking care of, or is this something more appropriate for handling in a network of registry event listeners?
[15:23:01 CST(-0600)] <peterk> I'd prefer to have this at the DAO layer. This should make transaction management and the code itself easier. Hibernate has some ability to maintain integrity, but I don't really know if we can get everything implemented this way.
[15:23:37 CST(-0600)] <peterk> And we should probably ask EricDalquist what the specific problems were
[15:25:14 CST(-0600)] <dmccallum> hmmm.... we can definitely do it in hibernate, either with interceptors or event listeners.... i guess my concern was that we have registries with (indirect) references to these objects. i didn't know how important it would be to ensure that those references are cleaned up as part of the cascaded delete of persistent objects
[15:31:39 CST(-0600)] <EricDalquist> hey guys, just got back from a meeting
[15:31:51 CST(-0600)] <peterk> as long as they're cleaned out from the hibernate cache, the registries should be fine. While the registries cache transfers, the instantiation of the actual DO requires entire hierarchy to be instantiated. So if a parent DO is not available it will fail to assemble a child DO.
[15:32:05 CST(-0600)] <peterk> but Eric has thought more about that, so we should let him chime in (smile)
[15:33:06 CST(-0600)] <EricDalquist> so the issue with hibernate doing the cascade is our transfer objects are not directly coupled (referenced by ID not to the actual object) and when the hibernate impl was done we weren't sure if we could get hibernate to understand the foriegn key relation between the objects
[15:33:25 CST(-0600)] <EricDalquist> so the idea was to do a cascading delete via events from the registries
[15:34:08 CST(-0600)] <EricDalquist> I can't remember where that left off and it was a bit of a pain with the registry-per-user model that the entity and window registries follow
[15:34:52 CST(-0600)] <EricDalquist> as for SVN I can see what I can do to help there, I'll be off tomorrow (doing a little bit from home) but if you can re-send that email dan I'll see what I can do to help push SVN through
[15:35:10 CST(-0600)] <EricDalquist> the disclaimer is I have 0 SVN (or CVS) admin experiance
[15:35:26 CST(-0600)] <dmccallum> i had been going down the road toward a hibernate approach using an interceptor registered with the SessionFactory, but then i saw the registry event mechanism, so i wanted to make sure i was really solving the correct problem (in the correct way, of course)
[15:35:42 CST(-0600)] <EricDalquist> the hibernate interceptor would probably be cleaner
[15:36:22 CST(-0600)] <EricDalquist> the registry events were poorly designed by me (should be using the spring event mechanism) and unfortunatly should probably be at least partly scrapped
[15:36:34 CST(-0600)] <EricDalquist> moving to Maven2 for the entire build process should be easier with us saying WSRP isn't going to be part of this RC
[15:37:12 CST(-0600)] <EricDalquist> since the code enhancement JPOX does was part of the stumbling block there
[15:37:43 CST(-0600)] <dmccallum> i'll resend the SVN email. i've done a little SVN admin, but we also have Brad Szabo who really knows what the hell he's doing, so I'm not too worried about making the switch and running into insurmountable problems.
[15:38:18 CST(-0600)] <peterk> the only complication is that we would like to carry over CVS history
[15:38:24 CST(-0600)] <peterk> but I think there are recipes for doing that
[15:38:27 CST(-0600)] <dmccallum> yes
[15:38:38 CST(-0600)] <EricDalquist> it sounds like the bigger thing is just getting it installed right now
[15:38:41 CST(-0600)] <dmccallum> we cooked up a proof of concept maybe a month ago and the history carried over fiine
[15:39:38 CST(-0600)] <dmccallum> i can find the SVN archive from that effort, I think, if you'd like to load it up and have a look, peter.
[15:39:38 CST(-0600)] <peterk> Eric: you probably know more about how to get official go-ahead from clearinghouse folks on this one.
[15:40:07 CST(-0600)] <peterk> heh, I believe you (smile)
[15:40:12 CST(-0600)] <dmccallum> (smile)
[15:42:31 CST(-0600)] <dmccallum> one more question on the cascading deletes.... my grasp of the architecture involved is a bit shaky here, i think, but is it appropriate to implement the interceptor such that it kicks off child object deletes by invoking registries, or should it be strictly limited to dao interaction?
[15:42:50 CST(-0600)] <EricDalquist> it needs to involve the registries
[15:43:03 CST(-0600)] <dmccallum> ok. i'll take a crack at it, then
[15:43:31 CST(-0600)] <EricDalquist> they maintain transfer object caches and are built to assume that they (or things that notify their cache) are the only things that will make persisted changes
[15:43:57 CST(-0600)] <peterk> Eric: but I think it will work passively as well
[15:44:21 CST(-0600)] <peterk> Let's say you delete "application"-level DO for a particular portlet DO
[15:44:45 CST(-0600)] <EricDalquist> oh yeah
[15:44:50 CST(-0600)] <EricDalquist> I forgot about that
[15:44:54 CST(-0600)] <peterk> in order to return portlet DO, the registry (factory) has to get reference for the application-level DO from the appropriate registry
[15:45:08 CST(-0600)] <peterk> and if has been already cleaned out, it will just fail and reset its own cache
[15:45:28 CST(-0600)] <peterk> so really the cascading deletes are just needed to keep the DB clean
[15:45:41 CST(-0600)] <EricDalquist> if during building a DO something is missing all affected caches are cleared of affected TOs and the rebuild is attempted from the DAOs, if that fails null is returned
[15:45:47 CST(-0600)] <EricDalquist> yeah
[15:46:24 CST(-0600)] <dmccallum> that was my next question.... how much do we really care about the aesthetics of orphaned DO records in the db?
[15:47:12 CST(-0600)] <EricDalquist> enough I think, it could ge pretty messy if someone is looking at the DB trying to figure things out since there could be a lot of orphaned entries
[15:47:16 CST(-0600)] <peterk> I think it's the volume that we care for. Plus there are may be some other impls reading these tables (i.e. reporting on portlets, etc.)
[15:47:45 CST(-0600)] <dmccallum> fair enough

  • No labels