wood burning stoves 2.0*
The moose likes JSF and the fly likes Question about having in the same web application both struts 1.1 and jsf 2.0 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » JSF
Bookmark "Question about having in the same web application both struts 1.1 and jsf 2.0" Watch "Question about having in the same web application both struts 1.1 and jsf 2.0" New topic
Author

Question about having in the same web application both struts 1.1 and jsf 2.0

carlo sciandrone
Greenhorn

Joined: Feb 26, 2012
Posts: 5
Hi is it technically possibile to have in the same web app both struts 1.1 and jsf 2.0?
That is because we have a legacy web app written in struts 1.1 and we would preserve the work done until now, and writing the new features with JSF 2.0.
We have tried defining the 2 servlets in the web xml each one responding to a different path and it seems to work fine.
Our goal is to migrate everything to the new configuration but it would be easier if we could start step by step.
Do you have any advice or contraindications ?
Thanks a lot
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
Whether this is worth doing or not depends on what features you have in your application and how well separated they are from each other.
You may need to do quite a bit more testing to ascertain that the two frameworks don't freak out when objects they think that they own are modified by the other without their knowledge.
If it's worth it then you should really consider using CDI in the application.
It keeps your beans free of any web framework specific code because you use CDI annotations to define their scope.
Also consider writing a WebFramework interface that you CDI inject into the rest of your code and only allow webframework specific code to go into implementations (Adapters) of that interface.



Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16095
    
  21

It is quite possible.

Neither JSF nor Struts are greedy. They don't demand total ownership of all incoming URLs, and in fact one of my biggest frustrations is that too many people try to force JSF to construct non-HTML output such as PDF, XML or MS-Office documents when the job is simpler and cleaner using bog-standard servlets or JSPs.

JSF and Struts can communicate using the stock J2EE objects. Session-scope JSF beans are exactly the same thing as session-scope J2EE (Struts) beans, and likewise for request scope and application scope. JSF doesn't have "page scope", which is, in any event too transient to communicate with anything other than the current page. Of course, in JSF, request scope doesn't work all that well, either.

In fact, the only difference between JSF managed beans and their non-JSF counterparts is that when a Managed Bean is referenced in JSF, JSF will construct and initialize it on-demand, but non-JSF code has to do the work itself.


Customer surveys are for companies who didn't pay proper attention to begin with.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
Tim Holloway wrote: JSF doesn't have "page scope", which is, in any event too transient to communicate with anything other than the current page...

There is now a ViewScope with JSF 2. But more importantly, with CDI those beans no longer have to be coded as JSF beans at all. The beans can now contain no JSF code at all.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16095
    
  21

I didn't mention View Scope because, like Page Scope, it cannot be passed between JSF and non-JSF. Technically, View Scope is a self-purging Session scope, and thus above Request scope, instead of below it, as Page scope is. But, like I said, since you can't pass stuff around in it, it's not really relevant to the problem at hand.

I think you meant that CDI allows to to avoid JSF-specific annotations rather than JSF-specific code. In any event, I always recommend writing code as portable as possible, regardless of how (or if) annotating was done. Although in the case of JSF datamodel and selectitem classes, CDI or otherwise, I make an exception, since you don't get full functionality if you present collections directly to JSF without wrapping them in a JSF model class.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2383
    
  28

One thing you might want to look at is compatibility of dependencies.

We had a similar situation where we were trying to keep legacy code in Struts and new code in Spring MVC. One of our concerns was that Struts and Spring both depend on the same libraries (for example apache commons). However, since we were using an older version of Struts, it was dependent on the older versions of Apache commons. The concern was that moving to latest version of Apache Commons might break Struts. We tested it and the concern was unfounded, because Apache Commons is backward compatible. It was still a good idea to test compatibility before we went into full scale development of new code. You don;t want to find something like this after you have implemented 20 new pages.

We did run into an issue where 2 version of standard tag libraries were being packaged into the war because of struts. The problem was easily fixable. It was helpful to find it early on.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16095
    
  21

Ah yes. "DLL Hell", so to speak.

You can get this anytime you mix complex technologies. I can't tell how many happy hours I've spent reconciling dependency versions.

Mainly because there were a lot of hours, but they weren't happy.

Both Sun and Apache spend more time than most on ensuring backwards compatibility - unlike a certain other large platform that I abandoned when entire APIs went obsolete overnight. But accidents happen.

That's one of the advantages of building with Maven. Precise versioning requirements so that once you find a happy combination, you can depend on it. Until you can afford to spend the time to do it all over again.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
Tim Holloway wrote:..I think you meant that CDI allows to to avoid JSF-specific annotations rather than JSF-specific code. ...

You actually get rid of all the JSF specific code from the beans because you use IOC to decouple the code that uses JSF classes from the rest of your application.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2383
    
  28

Tim Holloway wrote:

Both Sun and Apache spend more time than most on ensuring backwards compatibility - unlike a certain other large platform that I abandoned when entire APIs went obsolete overnight. But accidents happen.

That's one of the advantages of building with Maven. Precise versioning requirements so that once you find a happy combination, you can depend on it. Until you can afford to spend the time to do it all over again.


Yes, Apache is very good with backward compatibility. And Sun built a very good deprecation mechanism into Java, which makes backward compatibility so much easier.

Maven helps a lot too, but you have to follow best practices. For us, Grouping dependencies of critical libraries into it's own module made it easy to control which version gets picked up.

Also, the JMX console provided by JBoss helps a lot too. When you have things that don't work, right, you can go in there and find exactly which jar the class is getting loaded from. Funny thing about classloading issues are that are sometime un-debuggable. IDEs like eclipse change the way how classes are loaded, and it may just happenned that trying to debug the problem makes the problem go away.

IMO, the problem of "DLL Hell" has really become a non-issue for Java developers because of several things
a) support in the language for deprecation
b) A disciplined development community that respects backward compatibility
c) Build tools like maven that automatically resolve conflicts and provide tools to control conflicts during build time
d) Introspection tools that allow you analyze problems during run time.

Back in the day, when I used to write code for Visual C++, none of this existed. It was true hell.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16095
    
  21

Don't write it off too soon.

I spent half the day yesterday reconciling versions and if Google ever billed me for all the searches I'd had to do to find what version of slf4j went with what version of spring-data etc., etc., etc...

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question about having in the same web application both struts 1.1 and jsf 2.0