JBossDeveloper

So i guess you used the JEMS installer to get 4.0.5+EJB3 ?

The version we test on is the standard JBoss 4.0.5, the installer is slightly different.

If your other developer had reported it before we could have had a look for CR2.

If you confirm that it is by using the JEMS installer i can have a look now and we could find a fix or workaround for Final.

That's unfortunate that this bug happened on you.

(btw, you should be able to turn off the workflow mechanism in portal-cms.sar/portal-workflow.sar/META-INF/jboss-service.xml and have the CMS working without jBPM.

So basically all the issues you mentionned on the first post were non issues. There is maybe a bug on some version of AS but that's why CR2 exist.
And Final will also contain bugs, that's software life.

So now if you could report bugs without being insultant we would all have a better life.

It appears that the CMS workflow cannot be that easily turned off. I created a Jira feature request for you: http://jira.jboss.com/jira/browse/JBPORTAL-1399

Ok, i will give it a try tomorrow.

Actually the installation guide has a warning about it:
http://docs.jboss.com/jbportal/v2.6/reference-guide/en/html/installation.html

Warning
Make sure to download the JBoss AS Zip version. DO NOT ATTEMPT to deploy JBoss Portal on the installer version of JBoss AS! We are currently working on aligning the Application installer with JBoss Portal.

I tried the following:
Installed JBoss AS 4.0.5 with ejb3 profile using the JEMS installer 1.2.0.GA:
http://labs.jboss.com/jemsinstaller/downloads

Moved jboss-portal.sar, portal-cms.sar, portal-samples.sar in the deply directory with the datasource descriptor.

The dashboard is working correctly, everything i tried was working (Except hot deployment of the CMS). The testsuite is not runned against this particular configuration though.

Please, let me know what you did differently.

Hi Brad,

I´ve a question:

We are evaluating a few open source portals.

Google gadget integration (who really needs that?)?

JBoss Portal has sort of lost its way as well. There are more and more features in the Portal that have nothing to do with JSR-168 and everything to do with bells and whistles for marketing. It would be far more useful if they were to do something like create a portal bridge for AJAX4JSF or better document the security module implementation.

That being said, there is a lot of noise in Portal environments in general that simply gets in the way of development.

BTW what is with jsf-example.jar containing the Facelet bridge class.

Also replace the method in the class with this one so it works within and outside the portal.

protected ResponseWriter createResponseWriter(FacesContext context)
throws IOException, FacesException
{
ExternalContext extContext = context.getExternalContext();
if(extContext.getRequest() instanceof ServletRequest)
return super.createResponseWriter(context);
RenderKit renderKit = context.getRenderKit();
RenderRequest request = (RenderRequest)extContext.getRequest();
RenderResponse response = (RenderResponse)extContext.getResponse();
String contenttype = request.getResponseContentType();
if(contenttype == null)
contenttype = "text/html";
String encoding = response.getCharacterEncoding();
if(encoding == null)
encoding = "ISO-8859-1";
ResponseWriter writer = renderKit.createResponseWriter(FaceletViewHandler.NullWriter.Instance, contenttype, encoding);
contenttype = writer.getContentType();
response.setContentType(contenttype);
writer = writer.cloneWithWriter(response.getWriter());
return writer;
}

"bsmithjj" wrote:
One comment on the google gadget thingy - I have nothing against a google-gadget portlet or add-on module, but I really think that JBoss Portal would do better if it was a delivered as a basic Portal 'engine' with a lot of the bells and whistles available as easy-drop-in add ons. Unfortunately, a lot of the bells and whistles (such as a google-gadget portlet) are simply lumped into the basic portal - making the whole product complex, hard to document, and fragile at times.
Splitting the Portal into logical pieces allows each piece to evolve independently - most likely the core engine won't change too much because the fundamental building blocks are a JSR168 portlet container plus the paging and customization system.

"swestbom" wrote:
JBoss Portal has sort of lost its way as well. There are more and more features in the Portal that have nothing to do with JSR-168 and everything to do with bells and whistles for marketing. It would be far more useful if they were to do something like create a portal bridge for AJAX4JSF or better document the security module implementation.

Thomas, can you fix the JSF Facelet bridge? I gave you the fix (a few additional lines of code) and rename the jar to something meaningful instead of jsf-example.jar?

Facelets should work within and outside the portal not in just one or the other, the instance of check and referral to the parent method fixes the problem neatly.

I would vote for getting AJAX4JSF working correctly first meeting a non-existent standard second.

"swestbom" wrote:
Thomas, can you fix the JSF Facelet bridge? I gave you the fix (a few additional lines of code) and rename the jar to something meaningful instead of jsf-example.jar?

I would vote for getting AJAX4JSF working correctly first meeting a non-existent standard second.