Forum Stats

  • 3,782,436 Users
  • 2,254,645 Discussions
  • 7,880,078 Comments

Discussions

Migrating existing application to the portal

mohanr-JavaNet
mohanr-JavaNet Member Posts: 144
edited Jan 4, 2009 11:06PM in WebLogic Portal
Hi,
I have had some experience with migrating an existing J2EE application to the portal. Initially we migrate one part of the application to a JSR 168 portlet. The other parts are also portlets but they are just accessing the existing J2EE non-portletized application(IFrame portlets or Web Clipping portlets). This is done because if the JSR 168 portlets need the non-portletized part of the application for testing then we can use the portal itself so that we don't have any surprises later.

Does anyone have experience with this type of migration ?

Thanks,
Mohan

Answers

  • 667822
    667822 Member Posts: 36
    Hi Mohan,

    It sounds like you understand your options. If the legacy applications are implemented in Java, there are a number of approaches like JSR-168 or even a native bridge (WLP can consume Struts, Pageflow, JSF, JSP apps natively). If the legacy apps are non-Java, there are a few options that you list - IFrame, Clipper.

    Can you provide more background as to what guidance you are looking for?

    Regards,
    Peter
  • Part of the application will be converted to portlets and the rest of it later.

    The non-portletized part is a J2EE application. So WLP can consume it natively ? What is meant by that ?


    Thanks,
    Mohan
  • 667822
    667822 Member Posts: 36
    Hi Mohan,

    If you go into Workshop, and choose "File->New->Portlet", you have several options for the technology. That list includes JSP, Struts, Page Flow, and JSF. If your J2EE application UI is implemented with one of those technologies, you can point the portlet to the starting page of the application (assumes your app UI is located within a Portal Web Project). Since WLP natively understands those technologies, it may be able to just bring in the application without modificaiton.

    Some caveats though:

    - the app is likely adding chrome, like a header, footer, menu, and navigation elements that won't render well within a portlet. That may need to be stripped off.
    - the JSP option is limited - it won't rewrite links within the JSP to be portal friendly like with the other technologies
    - the Portlet Developers guide has more information on each of the possibilities
This discussion has been closed.