The JBoss Portal team is proud to announce the release of JBoss Portal RC1. This release marks the first since the JBoss-Novell development teams merged on the project, and is a great milestone on the road to our Final due in early June.

A complete feature list of this release can be found here.

Downloads, additional documentation, wiki, and forums can all be reached from our project homepage.

As always, the JBoss Portal team is open to suggestions and feature requests, so feel free to voice them in our forums or our Jira Roadmap.

roy.

Congrats to all involved. I'll check it out.
Steve

We've been using this and previous cuts of the portal very successfully on our Alfresco project. The portlets we're building are using JSF (MyFaces) for the UI, and it all runs very sweetly.

We were looking for a single JSR-168 compliant OSS portal to develop against, so tried out the well known ones. JBoss Portal came out best for us, in terms of being simple to deploy; light in the html it generates; not overly complex to understand; and the JBoss developers are very responsive.

Having said that, the job's not over yet - this is the first release of their new portal architecture. Hopefully, JBoss will get actively involved in pushing JSR-168 to the next level (begin interportlet communication mantra, themes, ...).

Nice work
Phh.

---
Paul Holmes-Higgin
Alfresco.org

We've been using this and ...

Thanks for sharing your experience. I was about to ask if anyone had any. There are quite a few OSS portals available currently. That is good, but makes it tough check them out. :) The only ones I have installed and played with are eXo and Liferay.

Does feature list assume JSR-168 and WSRP?

Dmitry
Coldbeans

What degree of JSR-168 (Portlet API) compliance has the JBoss Portal achieved?

Is the JBoss Portal have WSRP (Web Services for Remote Portlets) compliance or are there any plans to go in this direction?

Also, does the Content Management solution comply with JSR-170 (Java Content Repository API) or are there plans for compliance?

What degree of JSR-168 (Portlet API) compliance has the JBoss Portal achieved? Is the JBoss Portal have WSRP (Web Services for Remote Portlets) compliance or are there any plans to go in this direction?Also, does the Content Management solution comply with JSR-170 (Java Content Repository API) or are there plans for compliance?

JSR168: We are JSR-168 compliant run the Sun TCK before every release to ensure this.

WSRP: The Novell team will be building out WSRP in JBoss Portal for our 2.2 release, as per the 2.0 spec.

JSR170: We are keeping a close eye on Apache Jackrabbit and another implementation a community contributor is working on. The spec is not "final" and currently in the PFD2 stage.

STAY METAL!
Roy Russo

have you not seen how bad jackrabbit is? run magnolia to see it in all it's g(l)ory

have you not seen how bad jackrabbit is? run magnolia to see it in all it's g(l)ory

;-) We are keeping our options open, atm. To implement a non-final spec is not a road we want to travel down.

STAY METAL!
Roy Russo

have you not seen how bad jackrabbit is? run magnolia to see it in all it's g(l)ory

And what is it excactly about Magnolia that makes Jackrabbit look so bad?

Keep in mind that Magnolia only uses Jackrabbit a (default) content repository.

we really liked magnolia as a cms, nice interface, nice architecture, but jackrabbit was creating a ridiculous amount of files and directories which caused too many preformance problems with the app itself and with our backup process that we had to drop the cms.

the news of a database-backed implementation from objectweb is interesting, i need to take another look at the magnolia mailing lists to see if they have looked at implementing it.

Yeah, those thousands of files were due to the FileSystem persistence manager. Magnolia now uses (or in 2.1 version) CQFileSystem (proprietary persistence manager by Day, I think) for storage. This stores the repository in a single binary file.

The best would of course be the hibernate persistence manager, but it's not complete yet.

With Magnolia 2.1 we have changed the implementation of our datastructures (we now use jcr nodetypes which were not available when we started with Magnolia) This in itself has reduced the number of files dramatically, but still the standard Jackrabbit implementation will not scale well on Windows systems.

As an alternative, we sell a commercial "Magnolia Power Pack" that uses a completely different repository that is about 50 times faster than Jackrabbit, using only a handful of files.

Jackrabbit has a persistence layer that allows you to swap implementations of persistence; allowing you to use databses etc, but nothing is out there yet from them that is production ready.

As already noted, we currently use CQFS by Day, which unfortunately is restricted to non-commercial use.

Finally, Exo-JCR will come as an alternative, but due to its GPL licensing might mean that you will have to pay for it as well.

Other implementations will follow, the market is just getting started. We Magnolians are actively looking at what is out there, and make sure that it works with Magnolia.

http://www.magnolia.info

Regards
Boris Kraft

have you not seen how bad jackrabbit is? run magnolia to see it in all it's g(l)ory

please, under no circumstances, make the mistake of judging Jackrabbit by looking at the surface of an application in general and at an old version of magnolia in particular.

Jackrabbit covers the entire JSR-170 spec (and more) and passes 100% of the testcases of the TCK. If there are any real complaints about jackrabbit please feel free to let the developers at http://incubator.apache.org/jackrabbit/mail-lists.html
know ;)

regards,
david

What kind of WSRP support are you planning? I will first say I didn't methodically go over the documentation but I couldn't find anything related to 2.2.

Will you be just supporting consumption of WSRP portlets or will you also have the option to be a WSRP server? If the latter, will you just support the production of WSRP by exposing JSR-168 portlets? Or will there be something more?

It'd be great to be able to expose JSR-168 portlets as WSRP services so that there wouldn't be the need/requirement to deploy portlets into the primary portal server. It'd also allow for an ASP portlet model if I'd rather host the solution and have the portlets consumed remotely.

-Mike

What kind of WSRP support are you planning? I will first say I didn't methodically go over the documentation but I couldn't find anything related to 2.2. Will you be just supporting consumption of WSRP portlets or will you also have the option to be a WSRP server?

WSRP consumer and producer will be provided. we are a member of the WSRP 2.0 spec effort, and plan to provide a WSRP2.0 compliant solution.

If the latter, will you just support the production of WSRP by exposing JSR-168 portlets? Or will there be something more?It'd be great to be able to expose JSR-168 portlets as WSRP services so that there wouldn't be the need/requirement to deploy portlets into the primary portal server. It'd also allow for an ASP portlet model if I'd rather host the solution and have the portlets consumed remotely.-Mike

Not sure if I understand. You will be able to expose individual 168 portlets via WSRP, and you will be able to consume external WSRP portlets in the portal. Is this what you're looking for ?

As was stated before we are going to provide consumer and producer functionality.
WSRP producer: Will be WSRP 2.0 complaint. There will be a generic framework of pluggable portlet providers. Default implementation bundled with portal will be JSR 168 portlet provider. So there will be no "requirement on deploying portlets on a primary portlet server".

For WSRP consumer we will support ability to consume WSRP 1.0 ad 2.0 complaint portlets.

It can be possible to attach Portals some type of workflow engine? Are they thinking to integrate this type of solution to the product?
I think it´s one of the few features that are missing to make it really a complete CMS solution

One of your original portal developers left the project and is now working on JBoss jBPM integration between our projects. In the interim, we are considering adding in a very basic workflow to the CMS without jBPM.

We understand the imortance of CMS functionality in a Portal, but understand as well that they are two different products.

STAY METAL!
Roy Russo

When can we expect the release of cms with basic workflow

Not support for RSS/Atom feeds ?

RSS feeds are handled by the individual portlets, not the portal server.

STAY METAL!
Roy Russo

Can I assume that this portal only runs under JBoss AppServer?

For now, yes. Once we are able to sit on top of the JBoss micro-container, no. So, you assume correctly. ;-)

STAY METAL!
Roy Russo

Seeing from the complete feature list, it is really attractive for me. Thanks air jordan shoes nike kids shoes custom air force ones