Experience with portlets

[Zia 7]

I wanted to question what it is for experience with portlets. It seems in part before as though they are often used, but still lost in the multitude of technologies. So I would like to ask a few times opinions (eg portlets have no relevance in practice, portlets is a good idea, but have no relevance in practice, I used Portlet before, What are portlets?? Can I wse regular portlets, portlet occasionally, etc.??). Please explain in details..!!

[Adley]

Even if this thread is a bit older, I still wanted my "mustard" add. JSR 168 portlet applications can be effectively combined with other frameworks. Thus, portlets based on JSF as well. With JSR 286 will then be possible for portlets can receive and send events to speak include standardized with other portlets. In addition there will be Portletfilter or ServletFilter to modify port requests and responses can. Some frameworks already implemented the public draft of JSR 286th.

[pancham]

I think the issue has recently matured properly. Yet some time ago as the JSF integration does not have works really well (for the Liferay Portal and offices MyFaces, Hello World has worked ok but unfortunately it was then already almost). I personally really liked the JBoss Portal. Of course this works best in the JBoss JEMS Middleware But Liferay offers many features and even runs with a Tomcat. This had the advantage for us that you, the portal also with a not so well equipped server something you can run.

[PARRISH]

I can think portals offer a good framework (SSO, authorizations, etc.) and takes a lot of work from one so that you really focus on the business application. Approximately every grid infrastructure offers at least one Grid portal or gateway. These are web applications which tender its user’s fundamental functionality for job acquiescence and management. Some elucidations offer even very multifarious applications in support of using a Grid infrastructure. Most of these Grid Portals are implemented in Java assembly use of one or more of the obtainable frameworks.

[RichiRich]

An archetypal deployment circumstances is definitely to have an Apache HTTPD in front of a tomcat web application container. The authentication header in such cases is frequently performed at the HTTPD user and the information promoted to the tomcat via the HTTP. Tomcat recognizes this authentication information only, if the connector has the trait according tomcatAuthentication = false. Such a situation works very glowing, if only uncomplicated frameworks are used and the tomcat is not entrenched into a full Java EE container which needs to achieve post-authentication steps such as loading user role related information in order to be prepared for authorization pronouncements.

[Solitario]

But now even in principle (related to the J2EE specification, not the solutions proposed here) that's pretty idiotic. Almost every security model assigns users to groups (NT domains, * nix systems, LDAP, etc.). J2EE is the model to the Realms and Roles from them and then prevents the appropriate use due to a more or less reasonable limitation in the specification.

J2EE Specification is full of vague points and shortcomings. For example, you have no way of the generated PK by a newly created Entity bean to read. (But it was like in a web application). Stateless / Stateful Session Beans are distinguishable only by descriptor enrage, etc.