Sorry, David, that got beaten up by Jon for something that wasn't your
fault....
I think your approach of copying and thereby creating a new class was the
best you could do to move on. It would have caused us a lot of headaches
otherwise.
The PersistenceServiceImpl was indeed a quick shot at personalizable
portlets. It was very tricky to
do this in the first place without screwing up Portlet API. However, it was
(from my point of view) not intended to be donated as is, but due to some
hasty commitments it ended up in Jetspeed premature as it was.
I *certainly* don't store RunData beyond the lifetime of the request.
Dealing with the lifetime of objects correctly is one of the great
weaknesses of Jetspeed. So, I am very much focussed to get this right,
especially with the next release. BTW, I don't making everything a
(Jetspeed/Turbine) service is good idea either. There are way too many
singletons dangling and hanging around.
With regard to the "iFoo" convention -- well, I have always tried not to use
global variables (in C++), so
moving on to Java wasn't a big deal for me. Still objects can have different
scope in Java (class, instance, temporary, arguments) over years of
programming I came to have a convention for the different scopes. I don't
know what kind of Java you are using, Jon, but clashes of scope within the
same namespace still exist. Some people use "Foo_", some "iFoo", other
"this.Foo". So what? Until such time there is a Jetspeed/Apache coding
convention, I'll suggest everybody does what s/he thinks is required to
write readable and understandable code....
Cheers,
Thomas B.
----- Original Message -----
From: "David Sean Taylor" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Monday, January 29, 2001 20:40
Subject: RE: JetspeedPersistenceService.java
> Wow, the wrath of Jon, bummer...
>
> Let me *try* to defend myself:
>
> In creating JetspeedPersistenceService.java, I copied
> PersistenceServiceImpl.java.
> The code is basically the same, but the JetspeedPersistenceService uses a
> newer profiler.
> I didn't want to modify PersistenceServiceImpl.java, since others may
still
> want to use the old profiler. Thus I created a new service impl.
>
> Let me state that I don't use "iFoo" conventions, please reference my
other
> commits.
> I know you can argue that I *now* use "iFoo" conventions since I was too
> lazy, I rather believe I was too polite, so you do have a point there.
> I will change the variable names.
>
> I have also brought up the fact on this mailing list that invocations of
the
> Persistence Service required multiple 'new' persistence services per
> request.
> So this means that since the lifetime of the service object is only for
one
> request, its then safe to 'cache' the RunData, since the service object
will
> be gone after the request.
>
> This is counter to how I believe services should work, again I've
discussed
> this on the list.
> >From a performance and lifecycle mgt perspective, there are also
issues....
>
> In defense of the authors, I believe that the PersistenceService was
written
> as a 'temporary solution', since the underlying classes used by it i.e.
the
> PortletSet and PSMLManager are due for some major overhauls. In that
spirit,
> I left the service as is since it works for now.
>
> Im all for rewriting the Persistence Service to be a Turbine Service. But
> when I suggested that, it was argued that we are considering our own
service
> model for the 'Portal API' that isn't dependent on anything else. The
> committers to this service will be able to describe this more, but they
are
> in Europe so it probably won't be til tomorrow.
>
> Damn, now I suppose that everytime you see my name, you will think "iFoo",
> or even worse, the "iFoo Propagator".
> Where's there a corner I can hide in....
>
> -- iFoo
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Stevens
> > Sent: Monday, January 29, 2001 10:22 AM
> > To: jetspeed
> > Subject: FW: JetspeedPersistenceService.java
> >
> >
> > I just want to make sure that you guys aren't caching RunData
> > objects...that
> > is BAD BAD BAD...those objects should *never* persist longer than the
> > current request.
> >
> > Also, I *hate* it when people name their variables with "iFoo" or
> > "aFoo"...this is Java, not C. There are no global variables in Java and
it
> > is trivial to tell which one you are dealing with within a Class
> > and placing
> > naming conventions on the variables like that just make things more
> > confusing...not less...especially if the rest of the code base
> > doesn't look
> > anything like that.
> >
> > :-)
> >
> > -jon
> >
> >
> > public void store ()
> > {
> > // store page by page (and let's hope that no exception occurs
> > // -> missing transaction integrity is a major concern here!
> >
> > for (Enumeration e = getPages (); e.hasMoreElements (); )
> > {
> > Page page = (Page) e.nextElement ();
> >
> > page.store (iRunData);
> > }
> > }
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search: <http://www.mail-archive.com/[email protected]/>
> > List Help?: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
