I'm +1 on complete migration, but I do think it's a large amount of
work and I'm OK with doing a partial migration for 4.0.

BTW, I'm working on a proposal to refactor the JSP menu tag and adding
Struts2 support to it.

And Allen: thanks for getting the migration started! It looks great so far.

- Dave



On 4/28/07, Anil Gangolli <[EMAIL PROTECTED]> wrote:

I support making the jump to struts2 directly if that seems cleaner to you.

--a.


----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <dev@roller.apache.org>
Sent: Friday, April 27, 2007 11:02 AM
Subject: Re: struts1 -> struts2 migration


> sure, that definitely sounds like a good option.  Why don't we tentatively
> plan for that and when you guys have more info on when the Hackathon will
> take place just let me know and we can make a plan.
>
> -- Allen
>
>
> Matt Raible wrote:
>> I'd love to help, but will be out of town next week (ApacheCon), the
>> following week (vacation in Florida) and teaching a training class
>> following that.  With that being said, I believe there is a Hackathon
>> at ApacheCon and both Dave and I will be there. Maybe we could
>> collaborate? I'm not sure the time or the place, but maybe we can meet
>> on IRC and bang a few things out?
>>
>> Matt
>>
>> On 4/27/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>>> Follow up on the struts2 migration stuff ...
>>>
>>> I've spent a little more time this week working on migrating the couple
>>> of actions which I am planning to upgrade for my new 4.0 feature work,
>>> which include the theme and template editing pages.  I've also redone
>>> the way the tabbed menu works so that it's no longer a custom jsp tag
>>> and instead is just a normal tiles jsp.
>>>
>>> At this point I am strongly considering just doing the whole migration
>>> for 4.0 and getting it out of the way.  Basically, I think that running
>>> struts1 and struts2 side by side is only going to complicate things and
>>> make them more difficult and while it's extra work to get this done I
>>> think it's worth it.  The new struts2 actions are looking *soooo* much
>>> nicer than the old ones and I think this will really enable us to really
>>> treat the 4.x series as a chance to refine our UI and we just can't (and
>>> don't want to) do that with struts1.
>>>
>>> Anyone have any strong opinions on this?  I had doddling around so I
>>> think I am just going to commit to this and find a way to make it
>>> happen.  Anyone else still want to help?
>>>
>>> -- Allen
>>>
>>>
>>> Allen Gilliland wrote:
>>> > I just did my commit which contains the initial struts2 migration code
>>> > if anyone wants to look at it or play around with it.  I left all of
>>> the
>>> > old struts1 stuff in place and functioning, so nothing actually points
>>> > to the struts2 actions.  to get to them you'll have to hit the urls
>>> > manually ...
>>> >
>>> > /roller-ui/register.rol
>>> > /roller-ui/menu.rol
>>> >
>>> > those should be all you need.  you can register an account with the
>>> > new
>>> > register form and then go to the new menu page and it will link to the
>>> > other struts2 actions which are available.
>>> >
>>> > here's some highlights of the new struts2 code ...
>>> >
>>> >   * features a new struts2 and tiles2 configs, struts.xml and
>>> > tiles.xml.  both of these files are static and don't use xdoclet to
>>> > get
>>> > generated at build time.
>>> >
>>> >   * actions are now much cleaner and decoupled from the servlet spec
>>> > so
>>> > they are easier to test and reuse.
>>> >
>>> >   * i defined a base action class (UIAction) which provides a number
>>> > of
>>> > reusable methods, basically things that used to be in BasePageModel,
>>> > RollerSession, or RollerRequest.  our new actions only need to extend
>>> > that class and they get a *lot* of good stuff with basically no
>>> > effort.
>>> >
>>> >   * i defined a couple of custom struts2 interceptors to make our
>>> > lives
>>> > much easier.  the first extracts highly reusable complex attributes
>>> from
>>> > the request and sets them on the applied action, things like access to
>>> > the authenticated user object and the weblog being worked on.  the
>>> other
>>> > interceptor provides a simple way for security enforcement to be
>>> outside
>>> > of the action methods, so that we don't have to constantly be checking
>>> > if(user.hasPermission(weblog, perm)) all over the place.  there are a
>>> > few methods which you can define in your action which can tail the
>>> > security settings for whatever your action needs, like enforcing
>>> certain
>>> > weblog permissions or user roles.
>>> >
>>> >   * the jsps are much cleaner now and are using all struts2 tags.
>>> > i've
>>> > tried to eliminate as much scriptlet and other ugly stuff as possible,
>>> > but theres still a few places that need to be cleaned up.
>>> >
>>> >
>>> > overall i'm quite happy with the way things have turned out and think
>>> > that once we get more of the actions migrated to struts2 we'll find we
>>> > have a lot more options with cool things we can do on the UI and the
>>> > code will be much nicer and easier to maintain.
>>> >
>>> > feel free to check it out and offer any comments you might have.  the
>>> > code is basically in these spots in the current trunk ...
>>> >
>>> > src/org/apache/roller/ui/core/struts2/
>>> > src/org/apache/roller/ui/core/util/struts2/
>>> > web/WEB-INF/jsps/core/struts2/
>>> > web/WEB-INF/jsps/tiles/struts2/
>>> >
>>> > -- Allen
>>> >
>>> >
>>> > Allen Gilliland wrote:
>>> >> Well, my real need for starting this migration is because I am doing
>>> >> some work that will modify a couple existing actions and add some new
>>> >> ones and I didn't want to keep doing more work in Struts1 since we
>>> >> are
>>> >> planning to EOL it from Roller, so it is my overall goal to get the
>>> >> migration far enough that I can get that work done.
>>> >>
>>> >> As far as getting the initial part of the migration done as a proof
>>> >> of
>>> >> concept, my goal is to migrate the "core" actions, which includes 5
>>> >> actions for login, registration, profile update, weblog creation, and
>>> >> the main menu.  So far I have 4 of them done and I'm planning to
>>> >> finish off the last one this morning and have all that ready for
>>> >> commit today.
>>> >>
>>> >> That should lay the ground work but still leave a bunch of actions to
>>> >> migrate, including the System Admin pages (5), Planet Admin pages
>>> >> (3),
>>> >> and the Authoring pages (27).  The authoring pages can be broken up
>>> >> into smaller chunks of course.
>>> >>
>>> >> I don't have any real preference for what order we migrate things in,
>>> >> I suppose my approach would just be to migrate the most useful stuff
>>> >> first or the things that could benefit from Struts2 the most.  But
>>> >> anything that folks want to migrate is cool with me.
>>> >>
>>> >> -- Allen
>>> >>
>>> >>
>>> >> Don Brown wrote:
>>> >>> I'll be doing a BOF on migrating from Struts 1 to Struts 2 at
>>> JavaOne,
>>> >>> so I'd be keen to help out.  Any particular set of modules you are
>>> >>> thinking of migrating first?  I'd like to help where I can.
>>> >>>
>>> >>> Don
>>> >>>
>>> >>> On 4/17/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>>> >>>> Cool, the more the merrier.  I'll be sure to fire off any questions
>>> >>>> that
>>> >>>> I have since I know they'll come up.
>>> >>>>
>>> >>>> The 2 actions I've migrated so far are pretty simple, so there
>>> wasn't a
>>> >>>> whole lot that I had to work through for them.  Once I start
>>> >>>> getting
>>> >>>> into some of the more complicated actions I'm sure there will be
>>> more
>>> >>>> interesting decisions to make.
>>> >>>>
>>> >>>> Right now I am thinking of some ways to streamline the process for
>>> >>>> accessing data and doing operations which are basically required
>>> >>>> for
>>> >>>> all
>>> >>>> actions.  For example, in pretty much every action we have a test
>>> like
>>> >>>> this ...
>>> >>>>
>>> >>>> if(rollerSession.isAuthorizedToXXX(user, perms)) {
>>> >>>>    // do action work
>>> >>>> } else {
>>> >>>>    // denied
>>> >>>> }
>>> >>>>
>>> >>>> ... i want to separate out logic like that into interceptors or
>>> >>>> some
>>> >>>> other way so that the actions get that work for free and don't
>>> have to
>>> >>>> duplicate that code all over the place.  same goes for things like
>>> >>>> looking up the authenticated user and working weblog, which
>>> basically
>>> >>>> all actions require.
>>> >>>>
>>> >>>> i think i have some good ideas so far, but once i figure out which
>>> >>>> ideas
>>> >>>> i think are best i can run them by the list and see if others
>>> >>>> agree.
>>> >>>>
>>> >>>> -- Allen
>>> >>>>
>>> >>>>
>>> >>>> Matt Raible wrote:
>>> >>>> > I'd love to help with this migration, but unfortunately have
>>> too much
>>> >>>> > on my plate to do anything. Since I've already done a Struts 1 ->
>>> >>>> > Struts 2 migration on a couple projects, hopefully I can help
>>> w/ any
>>> >>>> > questions you might have. From the looks of it, you've probably
>>> >>>> > figured most things out.
>>> >>>> >
>>> >>>> > Matt
>>> >>>> >
>>> >>>> > On 4/16/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>>> >>>> >> I've spent a little time looking at this more closely and I've
>>> got a
>>> >>>> >> couple of the more basic actions migrated and so far
>>> everything is
>>> >>>> >> looking good and I don't think we'll have any problems running
>>> >>>> struts1
>>> >>>> >> and struts2 side-by-side while we migrate.
>>> >>>> >>
>>> >>>> >> I'd like to commit the work that I have so far which changes the
>>> >>>> login
>>> >>>> >> and registration pages to use struts2.  I've setup the migration
>>> >>>> process
>>> >>>> >> (so far) in such a way that all of the struts2 code is basically
>>> >>>> copied
>>> >>>> >> and modified versions of the struts1 stuff, so there is
>>> basically no
>>> >>>> >> replacement or modifications.  This way it's easy to see the two
>>> >>>> side by
>>> >>>> >> side while we work and we can easily switch between struts1 and
>>> >>>> struts2
>>> >>>> >> if that were ever necessary.
>>> >>>> >>
>>> >>>> >> So if nobody objects I'd like to commit my initial struts2
>>> support
>>> >>>> >> tomorrow.  The commit list is this ...
>>> >>>> >>
>>> >>>> >> M      metadata/xdoclet/global-forwards.xml
>>> >>>> >> M      metadata/xdoclet/servlet-mappings.xml
>>> >>>> >> M      metadata/xdoclet/filter-mappings.xml
>>> >>>> >> M      metadata/xdoclet/filters.xml
>>> >>>> >> A      src/org/apache/roller/ui/core/MigratingUIModel.java
>>> >>>> >> A      src/org/apache/roller/ui/core/struts2
>>> >>>> >> A      src/org/apache/roller/ui/core/struts2/LoginAction.java
>>> >>>> >> A      src/org/apache/roller/ui/core/struts2/RegisterForm.java
>>> >>>> >> A
>>> >>>> >> src/org/apache/roller/ui/core/struts2/UIActionSupport.java
>>> >>>> >> A
>>> >>>> >>
>>> src/org/apache/roller/ui/core/struts2/MigratingUIActionSupport.java
>>> >>>> >> A
>>> src/org/apache/roller/ui/core/struts2/RegisterFormBean.java
>>> >>>> >> M
>>> src/org/apache/roller/ui/core/struts/actions/LoginAction.java
>>> >>>> >> M
>>> >>>> src/org/apache/roller/ui/core/struts/actions/UserNewAction.java
>>> >>>> >> A      src/org/apache/roller/ui/core/util/UIUtils.java
>>> >>>> >> A      src/org/apache/roller/ui/core/UIModel.java
>>> >>>> >> M      build.xml
>>> >>>> >> A
>>> >>>> >> tools/struts-2.0.5/lib/tiles-api-2.0-20070130.184344-3.jar
>>> >>>> >> A      tools/struts-2.0.5/lib/struts2-tiles-plugin-2.0.5.jar
>>> >>>> >> A
>>> tools/struts-2.0.5/lib/tiles-core-2.0-20070130.184344-3.jar
>>> >>>> >> M      properties.xmlf
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/tiles-mainmenupage.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/menu-editor.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/menu-admin.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/tiles-tabbedpage.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/css-nosidebar.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/footer.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/empty.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/css-sidebar.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/head.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/tiles-simplepage.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/tiles-errorpage.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/search.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/banner.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/messages.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/bannerStatus.jsp
>>> >>>> >> A      web/WEB-INF/jsps/tiles/struts2/title.jsp
>>> >>>> >> A      web/WEB-INF/jsps/core/struts2
>>> >>>> >> A      web/WEB-INF/jsps/core/struts2/RegisterForm.jsp
>>> >>>> >> A      web/WEB-INF/jsps/core/struts2/Login.jsp
>>> >>>> >> A      web/WEB-INF/jsps/core/struts2/Welcome.jsp
>>> >>>> >> A      web/WEB-INF/jsps/taglibs-struts2.jsp
>>> >>>> >> M      web/WEB-INF/jsps/setupBody.jsp
>>> >>>> >> A      web/WEB-INF/tiles.xml
>>> >>>> >> M      web/WEB-INF/security.xml
>>> >>>> >> M      web/WEB-INF/classes/roller.properties
>>> >>>> >> A      web/WEB-INF/classes/struts.properties
>>> >>>> >> A      web/WEB-INF/classes/struts.xml
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> Anil Gangolli wrote:
>>> >>>> >> >
>>> >>>> >> > The last paragraph sounds like a good start.   I'm not
>>> >>>> >> > familiar
>>> >>>> with
>>> >>>> >> > Struts 2 yet so won't be of much help.
>>> >>>> >> >
>>> >>>> >> > --a.
>>> >>>> >> >
>>> >>>> >> > ----- Original Message ----- From: "Allen Gilliland"
>>> >>>> >> > <[EMAIL PROTECTED]>
>>> >>>> >> > To: <dev@roller.apache.org>
>>> >>>> >> > Sent: Friday, April 13, 2007 2:36 PM
>>> >>>> >> > Subject: struts1 -> struts2 migration
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >> we talked about this in the 4.0 planning discussions and i
>>> >>>> believe
>>> >>>> >> >> that everyone was in agreement that starting with Roller 4.0
>>> >>>> we would
>>> >>>> >> >> be moving to jdk 1.5 and introducing struts2 as the next
>>> >>>> generation
>>> >>>> >> >> framework to replace our current struts1 stuff.  since i am
>>> >>>> planning
>>> >>>> >> >> to do a reasonable amount of work which requires modifying or
>>> >>>> adding
>>> >>>> >> >> things to our authoring forms i'd really like to do them in
>>> >>>> struts2 so
>>> >>>> >> >> that my work isn't going to be wasted, so that means it's
>>> >>>> >> >> time
>>> >>>> to at
>>> >>>> >> >> least start the migration and get to a point where we start
>>> >>>> developing
>>> >>>> >> >> new pages and forms in struts2.
>>> >>>> >> >>
>>> >>>> >> >> i've started looking into this and playing around with it a
>>> >>>> little bit
>>> >>>> >> >> and if anyone else is interested in this then i would love to
>>> >>>> get some
>>> >>>> >> >> help. so far i've just done some reading on the topic and
>>> >>>> noting down
>>> >>>> >> >> a general strategy so if anyone has experience with this and
>>> >>>> wants to
>>> >>>> >> >> help, please let me know.
>>> >>>> >> >>
>>> >>>> >> >> right now i think my initial goal is to get the app
>>> >>>> >> >> configured
>>> >>>> so that
>>> >>>> >> >> struts1 and struts2 actions and forms can run side by side,
>>> >>>> and then i
>>> >>>> >> >> want to migrate a small set of the existing actions to
>>> detail the
>>> >>>> >> >> process.
>>> >>>> >> >>
>>> >>>> >> >> -- Allen
>>> >>>> >> >>
>>> >>>> >> >
>>> >>>> >>
>>> >>>> >
>>> >>>> >
>>> >>>>
>>>
>>
>>
>


Reply via email to