[Opensource] Upgrading from 4.02 to 5.02 (some notes)

[Michael Rimov]

Vicent,

First of all, thank you very much for the thorough report.  I think it 
provides great insight into the situation!

At 02:44 PM 6/13/2003 -0400, you wrote:
>         - The most annoying issue I had to deal with is that
>           DBFields seem to have become case sensitive. Every addKey,
>           addIndex, getField, searchAndRetrieve call need to be
>           examined and the ones I missed cause errors that are detected
>           only at runtime. I'm still finding crashes of obscure calls to
>                       searchAndRetriveList("ObscureId")
>           that should be
>                       searchAndRetrieveList("ObscureID")

For best practices, we've been recommending that you define the field names 
in DBObject classes as public static final String variables, and then 
reference it elsewhere in the code.  This is especially useful if you port 
to another database that has a trouble with the field name.  You can change 
the constant and the change propagates.

So:

public class MyDBObj extends SecuredDBObject {
         public static final String FLD_OBSCURE_ID = "ObscureID";
.....
}

MyDBObj.searchAndRetrieveList(MyDBObj.FLD_OBSCURE_ID);

Although not all of the Expresso code reflects this best practice yet, 
we're slowly working through it to change it all.




>           If I had my time back I would have created static strings for all
>           the field names and used those exclusively.

[Which, of course, is what I just said. :) But I wanted to get this tip 
better explained ]


>         - The field separator for an ordering changed from comma
>           separated to pipe separated. This is only detected at
>           runtime.

I think this was actually a side affect of a bug.  I believe the original 
code was always meant to be pipe separated, but the DBObject NEVER 
validated the search string, so your comma delimited fields would 
work.  Now, to protect against SQL Injection attacks, we strictly validate 
the format of the search string.  It's possible that the change happened 
before I became lead developer, but I remember the first time I dug into 
the code it was pipe delimited....  Thanks for letting us know about this 
change.



>         - Controllers don't instantiate if you don't define an initial
>           state.

Yes.  I had some problems where folks didn't specify a state and you were 
getting random states for the initial state.  I'm sorry that this one's a 
bit tough to track down at times, and I'll make a note in the docs.


>         - States now need to explicitly call setStyle("myView").
>           In 4.02 they would go to a view named the same as the state.

This shouldn't be the case.  If you define the view to use in the 
struts-config.xml instance for your app, Expresso respects that without 
explicitly setting setStyle().  Could it be that your app is older than 4.0 
and you're still using old 'view' terminology??  I'm interested in your 
view of this.



>         - Transitions behave differently enough that I had to write a
>           custom class to replace it. Because of the way I dispatch to
>           transitions, I need the same request to stick around. (Also,
>           subclassing doesn't work here).

If you really know your transitions and know there won't be bugs created by 
dispatching Transitions across multiple controllers, you can call 
Transition.setParams(request.getParameters());  to dump all the controller 
parameters into the transition.





>Other Comments:
>         * private vs. protected.
>
>             There have been three or four cases where I needed custom
>             behaviour from an Expresso class. In every instance, I was
>             thwarted from extending the class by a private attribute
>             or method that I needed to access. I didn't want to
>             change the Expresso source so I was left to the (?bad?)
>             solution of copying the source to a new class and editing
>             it (Example: Customizing "send" in EMailSender).
>
>             Question: In an open source environment, where one expects
>             developers to extend classes, shouldn't it be the
>             exception to use 'private'?

Actually, one 'best practices' that I saw that I think made excellent sense 
was "member variables private.... protected or public getters()"  Saves 
weird side affects when you refactor the base class.  One significant 
example would have been that I made 'DBObject.myPool()' start null and only 
instantiate when needed.  Accessing it through the getter made this have no 
side affects.

So the truth is yes and no.  If you want to extend things and want to add a 
protected get() method to the base class, feel free to submit a patch to 
the class in particular.




>* Performance
>
>             I must say that my performance vastly improved with
>             Expresso5.04. From what I can tell, this is mainly a result

Also, there were several other bottlenecks including string comparisons in 
DBField, etc.  I ran Expresso 5.0 through a profiler several times to 
reduce some of the overhead that was going on.  I'm glad the poolable 
FastStringBuffer has been of good use!


>             My biggest cost per page is now JSP processing. Each JSP
>             page include seems to be quite expensive and this is
>             outside of Expresso' control. I may try moving from Tomcat
>             4.06 to 4.1.x and see if this helps. Does anyone know if
>                 this is worth the effort?

I've profiled with Tomcat 4.1.24, and I haven't noticed any SIGNIFICANT 
performance increase in the jsp pages, although the page includes may have 
helped.  Right now I see Controllers/Jsps taking about 50/50 of the CPU 
time to service a request.



>             Question: Is there any documentation as to working
>             configurations (e.g. JDK 1.4 with Tomcat 4.1.24)?

5.0.4 had updated docs with Tomcat... when talking Tomcat 4.1, we used JDK 
1.4 in the docs.

>             Other than JavaDocs and intallation information, I have to
>             say that the documentation hasn't been that helpful. I would
>             not have been able to get started except for Peter Pilgrim's
>             article and looking through the source. The developers
>             guide has improved but more in breadth than depth. Examples
>                 of best practices (examples with annotations/guidance) are
>                 what I seem to need.

The good news is that I've been tutoring somebody in Expresso on the side, 
and I'm "encouraging" him to write down what I'm teaching them into a guide 
format.  It should help learning curve significantly.


>             There are new features that would be useful but I have no
>                 easy way to start using them. Do I want to use the new tags
>                 (struts, JSTL) that seem to be around? Without examples
>                 customized to Expresso, I don't really know how to
>             use them. The mailing list is great but sometimes it is hard
>             to know the right question to ask.

I hear you.  JSTL was included for the sake of those that want to start 
creating an Expresso-EL taglib package.  You won't see it in use until 
Expresso 5.2 [Because it requires Servlet API 2.3, and not everybody is 
quite switched over yet.]  I have in EDG an example of using pure struts 
tags with Expresso controller responses, and I plan on expanding it to show 
using JSTL or the struts-extended tags.

>Some particulars about why I think my usage is different than most
>expresso users:
>
>         - I don't make use of any of Expresso's controller/security
>           framework. It doesn't match my model.

Out of curiosity... I was thinking of "eventually" [probably by Expresso 
6.0] getting rid of the SecuredDBObjects/DBController, and setting up the 
concept of setting "Security Managers" for them instead.  Then by default 
we include an "DefaultSecurityManager" which would have standard Expresso 
behavior, and a "NullSecurityManager" which would be the old equivalent of 
DBObject, Controller.  Then folks could plug in their own security needs 
through extending the security manager.  Would something like this [again, 
I'm talking long term here] affect your ability to use Expresso?  I'm not 
big into isolating current users :).


>         Note: This is not supposed be criticism/commentary. Just a
>         statement of my situation.

Definitely appreciated!  Feedback like that helps me to figure out the 
usage patterns of Expresso and how to make it better.  Keep them coming folks!

                                                         -Mike