>-----Original Message----- >From: Franklin, Matthew B. [mailto:[email protected]] >Sent: Thursday, April 07, 2011 10:23 AM >To: [email protected] >Subject: Re: Bootstrapping RAVE code > >I haven't used OpenJPA, but would be willing to for a reference >persistence implementation.
+1 for OpenJPA. Internally there's a good chance we'll swap it out for EclipseLink JPA since that's what we're running on now, but as Ate pointed out already -- as long as we stick to "vanilla" JPA that should (in theory, and hopefully in practice) be relatively easy to do. >When we were laying out the feature list, we all agreed that we need to >build an object model that supports flexible persistence mechanisms and >allow Rave users to inject their own implementations over ours, if they >so >choose. To that end, I would rather try to identify a less circular >model >than OSEC. +1 for the shallower object model too. Matt and I have talked about this a bit internally so I know what he's getting at already -- and maybe it's clear already to everyone else already too -- but just in case it isn't (since I'm not sure it would be to me without my additional context) I'll add a little more background to this. I think this basically comes down to the fact that JPA supports lazily loaded relationships -- so you can have objects which have lots of relationships hanging off of them and only pay the cost of fetching those related entities when you actually need them. I think that's pretty much standard operating procedure when using JPA (and is really nice to have) but it seems like it makes it almost impossible to replace the backend persistence strategy with something that doesn't support this type of lazy loading. For example if someone were to try to replace the JPA based repositories in OSEC with JDBC based repositories -- to assemble and return a Page object you'd also have to fetch all the Regions on that page, and for each Region you'd have to fetch the RegionGadget's in that Region, and for each RegionGadget you'd have to... etc... And you'd have to do all that work up front even if the caller didn't really need all of those objects (or you'd have to manually add support to the domain objects to do it lazily). Not that I think anyone wants to use JDBC in place of JPA but I think the same problem likely applies with some types of NoSQL stores which I think people may want to use. So I'd be curious to see how a flatter object model (still JPA based for the reference implementation) might work out. >I also think we can probably identify other simplification areas. Much >of >the model of OSEC ties back to a container object, which was in support >of >running multiple distinct containers within the same application. A >container in this sense is a distinct entry point (think more along the >lines of multi-tenant), providing logical separation of all data. I am >not sure whether this is a pattern we would like to continue in Rave, >but >am open to all discussions. To add to this -- Shindig also has the concept of supporting multiple containers on its end too -- although I don't know how well that actually works in practice. I've noted issues with the Shindig configuration process taking one value that should be per container and using it across the board for all containers it's supporting (which in and of itself is just a bug, but it makes me wonder if this is something that was just there from the beginning or something they really use). We don't actually use this internally and it's caused confusion with some others who have looked at our code in the past so I'd be +1 for eliminating it. >-Matt > >On 4/7/11 10:14 AM, "Raminderjeet Singh" <[email protected]> >wrote: > >>I suggested DFD's for everyone to understand the current models and >find >>a gap if any or someone need it in different way. Models can be changed >>quickly to fulfill requirements . I also believe in looking into the >>code. As soon as we decide on build system and Mitre move the Models, I >>can help with writing the unit tests for models. >> >>Another question i have is to use OpenJPA or Hibernate JPA adaptors to >>connect to backend. I am using Hibernate adaptor and its working well >but >>i remember we discussing license problems with that in Apache. >> >>Thanks >>Raminder >> >>On Apr 7, 2011, at 8:03 AM, Franklin, Matthew B. wrote: >> >>> >>> >>> On 4/7/11 4:34 AM, "Ate Douma" <[email protected]> wrote: >>> >>>> On 04/07/2011 12:52 AM, Franklin, Matthew B. wrote: >>>>> When looking at OSEC, I would start with the object model >>>>> >>>>>(http://svn.apache.org/repos/asf/incubator/rave/donations/mitre- >osec/sr >>>>>c/ >>>>> org/mitre/portal/model/). The Page is the top level object and >>>>> represents the layout of gadgets that the user sees. >>>>> >>>> Sounds good to me. Starting with the core (basic) Object model just >>>>make >>>> sense. >>>> >>>> A remark upfront concerning Page being the top level (layout) >object: >>>>I'm >>>> fine >>>> we start out with a simple layout model first. >>>> However in my experience with portal layout in general we'll >probably >>>> need a >>>> more fine-grained nested/fragment based layout model later on to >>>>support >>>> "groups" or "sets" of layout elements which can be pulled in or >>>>included >>>> within >>>> a higher fragment level. The new OpenSocial 2.0 proposal for Spaces >>>>also >>>> already >>>> hints at this. >>> >>> In OSEC a Page has a list of regions that contain the gadgets, with >each >>> region containing a set of gadget mappings. It is a little more >>>fragmented >>> than just a Page with gadgets. >>> >>>> >>>> At Apache Jetspeed we've been using hierarchical fragment based >layout >>>> (PSML, >>>> Portal Structured Markup Language) for years, with the root fragment >>>> representing a Page. We even had to add nested fragment references, >>>> includes and >>>> fragment inheritance models to support all the layout requirements >we >>>> faced for >>>> customers. >>>> I'm certainly not suggesting we should use the PSML model for Rave >but >>>>it >>>> might >>>> be good not to "tie" layout elements and configuration too strongly >to >>>> only a >>>> single Page concept. >>> >>> To be clear, I am very open to a different object model or way of >>> representing the layouts of Widgets in pages. I am highly in favor >of >>> simple, flexible models. >>> >>>> >>>> Ate >>>> >>>>> -Matt >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Marlon Pierce [mailto:[email protected]] >>>>> Sent: Wednesday, April 06, 2011 12:53 PM Eastern Standard Time >>>>> To: [email protected] >>>>> Subject: Re: Bootstrapping RAVE code >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Sounds good to me. What is the next step? Can you send pointers to >>>>>the >>>>> OSEC code that illustrate your current approach? >>>>> >>>>> >>>>> Marlon >>>>> >>>>> >>>>> >>>>>>> In terms of infrastructure drivers, I think this is probably one >of >>>>>>> the >>>>>>> places to start. There are a lot of implicit features included >in >>>>>>> this >>>>>>> item some (not by any means all) of which are: >>>>>> >>>>>>> * The pages themselves >>>>>>> * Types of Pages >>>>>>> * Persistance >>>>>>> * Layouts >>>>>>> * Page Rendering >>>>>>> * Core javascript >>>>>>> * The widgets& container support >>>>>>> * Shindig authorization >>>>>>> * Backend data synchronization with Shindig >>>>>>> * Security >>>>>>> * Inline vs iFrame widgets >>>>>>> * Container API implementation >>>>>> >>>>>>> So out of this, I suggest the first feature we implement is the >>>>>>>basic >>>>>>> display of a page and discuss what the infrastructure required to >do >>>>>>> that >>>>>>> is. Specifically, a light-weight object model, rendering engine, >>>>>>>page >>>>>>> types etc. >>>>>> >>>>>> >>>>>> >>>>>> Marlon >>>>>> >>>>>> >>>>>> On 4/5/11 11:19 AM, Franklin, Matthew B. wrote: >>>>>>>>> Thanks Marlon. I was planning on kicking up the discussion >today >>>>>>>>> also >>>>>>>>> :) >>>>>>>>> >>>>>>>>> Personally, I don't think that starting with a throwaway is >quite >>>>>>>>> the >>>>>>>>> right route. I agree that we are stalled on the next steps, >and >>>>>>>>> that it >>>>>>>>> always helps to have code to comment on; but, we already have 2 >>>>>>>>> (soon 3) >>>>>>>>> codebases that we can use as drivers for our discussion. >>>>>>>>> >>>>>>>>> In my mind, the big question is what does the "10,000m" >>>>>>>>>architecture >>>>>>>>> (sorry to use a cliché) look like. Not specifics as to how >each >>>>>>>>> detailed >>>>>>>>> component will work, but what are the general organization >>>>>>>>> principles we >>>>>>>>> need to follow. For instance, you mentioned creating a >skeleton >>>>>>>>> that >>>>>>>>> includes Shindig. In our experience, the more loosely coupled >the >>>>>>>>> application is to Shindig the better. These discussions are >more >>>>>>>>> about >>>>>>>>> ensuring consistency and providing developers some heuristic to >>>>>>>>> follow >>>>>>>>> as >>>>>>>>> we break out and implement individual features. >>>>>>>>> >>>>>>>>> I definitely don't mean to imply that we need to architect or >>>>>>>>> design the >>>>>>>>> whole thing up front. That is an equally bad, if not worse, >>>>>>>>> approach >>>>>>>>> than >>>>>>>>> throw away in my opinion. >>>>>>>>> >>>>>>>>> That being said, when it comes to putting together the project >>>>>>>>> skeleton, >>>>>>>>> Tony, Jesse or I would be more than happy to take a first run. >>>>>>>>> >>>>>>>>> So back to where do we start? I think the first thing we do is >>>>>>>>>take >>>>>>>>> the >>>>>>>>> feature list from the wiki and discuss how we want to implement >>>>>>>>>the >>>>>>>>> highest priority one, using the existing codebases as reference >>>>>>>>>for >>>>>>>>> the >>>>>>>>> discussion. >>>>>>>>> >>>>>>>>> -Matt >>>>>>>>> >>>>>>>>> On 4/5/11 10:47 AM, "Marlon Pierce"<[email protected]> >>>>>>>>>wrote: >>>>>>>>> >>>>>>>>> Based on previous emails, I think we had consensus on the >>>>>>>>>following >>>>>>>>> points: we will start a new code base, and we'll base it on >>>>>>>>> SpringMVC >>>>>>>>> framework. Unfortunately that's as far as we've gotten. >>>>>>>>> >>>>>>>>> I'd like to suggest the following: let's create a skeleton >project >>>>>>>>> with >>>>>>>>> Spring + Shindig and start fleshing it out. This will be a >>>>>>>>> throw-away >>>>>>>>> so >>>>>>>>> we will want to tag it appropriately. This should hopefully >>>>>>>>> initiate >>>>>>>>> more detailed design discussions over email, etc. I think this >>>>>>>>> will be >>>>>>>>> easier if we have some code to comment on. I realize that >there >>>>>>>>>is >>>>>>>>> the >>>>>>>>> danger that the "throw away" version doesn't actually get >thrown >>>>>>>>> away, >>>>>>>>> but I think we can accept this risk. >>>>>>>>> >>>>>>>>> Raminder, Gerald, and I are Spring novices, so we need a >volunteer >>>>>>>>> from >>>>>>>>> Mitre or Surfnet to design the skeleton. I promise we'll add >to >>>>>>>>>the >>>>>>>>> framework as soon as it is created. >>>>>>>>> >>>>>>>>> >>>>>>>>> What does everyone think? I'm open to other plans and just >want >>>>>>>>>to >>>>>>>>> see >>>>>>>>> things start moving. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Marlon >>>>>>>>> >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin) >>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>>>> >>>>> iQEcBAEBAgAGBQJNnJpWAAoJEEfVXEODPFIDvrEH+gOHMoxm7aBszTRwKOD16YtO >>>>> ssAMPGvb8OVFk33/mqJmUq1+6i3pi8koFrL93hbnEiwdx9ZnO3o/6+1lY0Ak0uFZ >>>>> +Pz5b7RGz2NMCgwxDGQ0jPHXXq1ehAJAyphWrIh7bkwOwuIR7fVygnQyw1JYrGb1 >>>>> hiZ+H6xray3XHysWV61VXCjKNLMY0bpA/YzA0JM7gWSPv30xUPAVw66XkmTQGcf0 >>>>> 4kuPsV2ieLwhe7JR7Bhddox8Pvw1eQqgXP3i5AlUi/YMUchb3NCi+2am8sMFPjR7 >>>>> zs3cMLfYLjYcnPPIjmMz/ljywNnGPbfA4gkDHPzECUPGWGJcFZ8EXLdQw8zywac= >>>>> =SN1E >>>>> -----END PGP SIGNATURE----- >>>> >>>> >>> >> >
