• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
carlo sciandrone
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18302
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18302
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 2756
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18302
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 2756
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18302
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic