Hello everyone. This is my first post to this mailing list so please bear with me as I come up to speed on the topics and try to contribute in a valuable way.
I think a quick intro is in order so you can understand who I am and what my value to the group might be. I started on a development project early this year (www.uavnas.aero). I'm using Jetspeed as the portal infrastructure for the project's collaborative needs. I'm not a Velocity expert and haven't had time to come up-to-speed on that so all my portlet development has been JSP based. I am interested in developing an open-source project I call ACE (A Collaborative Environment) and the current project will bootstrap that effort. It will be a set of portlets and tools enabling online collaboration and knowledge management. I have been involved in collaboration/KM since '98 and worked for a portal vendor (Mongoose Technologies) from '00 to the beginning of this year. I was involved in product architecture, core development and collaborative products. Are there any Bios or information on other people on this list? Regarding the use of OJB versus Hibernate, I did a high-level evaluation in February of about 2 dozen OR-mapping products and decided to spike OJB and Hibernate to make a final decision. At the time both tools met my basic needs so it came down to some nit-picking. Here are 2 links comparing several OR-mapping tools, including OJB and Hibernate. http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison http://www.rollerweblogger.org/page/roller/20021013 I ended up deciding on Hibernate for a few reasons: - Hibernate supported attribute-oriented development using xdoclet. I can't stand dealing half a dozen files you have to keep in sync (think EJBs). With OJB it ended up being only 2 files (source + config), I could do everything with Hibernate in the 1 source file and an ant task. BIG, BIG +1 Hibernate - Although this is subjective, I felt more comfortable with the API for Hibernate. There are some recent blogs which relate frustrations with the relationship between the JDO and OJB APIs. Although the goal of JDO is basically right, I'm not a fan of the API myself. This is all about ease of use. +1 Hibernate - Hibernate supported more code generation and schema generation options (database -> code, code -> database, meta -> code + database) +1 Hibernate - I just couldn't get OJB to work. I spent about 2 days trying, and I ran out of time as I went from figuring out one stack trace to figuring out the next one. I'm sure it was just me, but... -1 OJB - OJB is an apache project. Hibernate is not. +1 OJB I've been happy with my decision to use Hibernate. It also seems to have a more active development community these days (as far as I can tell). +1 Use Abstraction Layer (Hibernate, OJB, ...) 0 Hibernate -1 OJB On another thread I saw some conversation regarding JAAS. I have used JAAS in the past and would strongly encourage its adoption if you intend to attract enterprise-level use of Jetspeed. A simple default configuration could be provided to support the existing login model (Jetspeed user table). +1 JAAS Sorry for the long post. Brian Johnson Salus Ventures, Inc. [EMAIL PROTECTED] (digest-mode) -----Original Message----- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 8:07 AM To: 'Jetspeed Users List' Subject: RE: JetSpeed 2: Turbine or Struts? How would you feel if we used OJB? It also works very well with POJOs, uses a XML mapping repository and is a Jakarta project. I have used it in many projects and its performance and pluggable nature really appeal to me. Eric, I have never used Hibernate, have you used OJB? If you have used OJB, could you give me comparison of the two projects? Both may be transparent enough to allows to provide a pluggable object persistence mechanism. +1 to OJB as an O/R tool for Jetspeed 2 *===================================* * Scott T Weaver������������������� * * Jakarta Jetspeed Portal Project�� * * [EMAIL PROTECTED] * *===================================* � > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 28, 2003 7:03 PM > To: [EMAIL PROTECTED] > Subject: RE: JetSpeed 2: Turbine or Struts? > > I'll just throw in my +1 to hibernate.. Being as it takes POJO objects > and > via a xml mapping service maps them to database tables, it makes it much > easier to deal with TURBINE_USER. But, for a corporate user, you could > just > map to MY_CORPORATE_USER, or just extend the user class and do your own > mapping. > > I am using a Avalon based Hibernate service with T2.3 very successfully. > The > performance is great as well. I committed into T2.3 CVS a howto on > Hibernate and Turbine. > > Eric Pugh > > -----Original Message----- > From: David Sean Taylor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 28, 2003 6:46 PM > To: Jetspeed Users List > Subject: Re: JetSpeed 2: Turbine or Struts? > > > > On Wednesday, May 28, 2003, at 02:49 PM, Jeff Linwood wrote: > > > Is the security model expected to change between 1.4 and 2.0? > > > > Jeff > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > Well I for one like most of the security model in Jetspeed. > So I'd like to keep it in > > One thing I'd like to get rid of is direct coupling to a pre-defined > schema, i.e. TURBINE_USER, but then again, > we have to consider the needs of other users, who like a portal that > works out of the box with a simple database behind. > I know from my experience, the corporate users need separation of > authentication, single-sign-on, ldap support. > But I don't want to forget the open source users who use Jetspeed to > run smaller sites with minimal configuration > > The portlet API gives us mappable user attributes per portal > application,which will be very useful > I think we should provide a default portal application out of the box > using predefined schemas > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > +01 707 773-4646 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
