DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Coding
  3. Java
  4. In Response to JSR-286: The Edge of Irrelevance

In Response to JSR-286: The Edge of Irrelevance

Andy Pemberton user avatar by
Andy Pemberton
·
Jan. 22, 09 · Interview
Like (0)
Save
Tweet
Share
9.94K Views

Join the DZone community and get the full member experience.

Join For Free

I have to admit, I can totally relate to Eric Spiegelberg’s article, JSR-286: The Edge of Irrelevance.
It’s a great article; in case you don’t have time to check it out, Eric’s main thesis is that:

the portal architecture lacks enough technical advantages and distinguishing features to warrant an increase in acceptance.


Over the past few years, I’ve complained about there being a “portlet spec, not a portal spec” - a thought Eric seems to echo in pointing out that most real-world projects require modifying the portal server but that in doing so, you’re tied to your vendor’s API and are no longer JSR168/286 compliant.

One of the other running themes in the article is that the portlet specs are perpetually out-dated. For example, the JSR286 spec itself (which went final release in June 2008) mentions its aim to align the portlet spec with JavaEE 1.4 (which went final release in November 2003)!

All-too-often portal is an after-thought: first came Spring MVC, then came Spring Portlet MVC; first came JSF, then came a new spec (JSR301 - the portlet bridge) to make JSF work in the portal environment. As frameworks like JBoss Seam are solving the truly challenging problems with web applications (contextual state management, back button, multiple browser windows), portal lags behind, requiring patchwork to support fundamental pieces of the new JavaEE.

Finally, I also agree with Eric that portal’s “greatest strength, the portlet, remains its greatest weakness”. On my current project, we fight with the portlet programming model every day. One could argue that if we’re having constant problems w/portal, then we’ve either got a bad design, bad developers, or we’ve incorrectly chosen to apply portal to our problem. I can hear the crowd now: “you’re doing it wrong”.

Regardless, I think our woes support the author’s point that the portlet development paradigm is “overly restrictive” and that the technology and features provided by portal don’t add enough value for the costs.

So, given the downsides, portal does have its benefits - IMHO portal’s primary strong suit is in aggregating web applications. Yet still I agree with the author that this benefit doesn’t outweigh the costs - you don’t get your money’s worth, so to speak.

So what do you all think?

Does Java EE need a new, less restrictive means for aggregating web applications?
Or do the author and I understate the benefits of portal? What other benefits do JSR168 and JSR286 provide?

From http://www.andypemberton.com/

application Eric (software) JBoss Java EE JBoss Seam Release (agency) Spring Framework Architecture Advantage (cryptography)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How To Best Use Java Records as DTOs in Spring Boot 3
  • How to Use Buildpacks to Build Java Containers
  • Detecting Network Anomalies Using Apache Spark
  • 4 Best dApp Frameworks for First-Time Ethereum Developers

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: