Hide Forgot
Date of First Response: 2009-11-10 06:10:44 Workaround Description: copy jboss-as/tools/resources/jbpm-console-development.war to jboss-as/server/default/deploy/jbpm.esb/jbpm-console.war project_key: SOA Start JBDS 2.1, configure it to see SOA-P 4.3 ER2 default config, create jBPM project, try to deploy the default jBPM process definition. It's trying to deploy to /jbpm-console/upload. However, if you look in the jbpm.esb/jbpm-console.war, you'll notice that the servlet URL appears to be /jbpm-console/app/upload. However if you change the URL, the "Test Connection" will now work, but the deployment button will still fail with no good error message. The web.xml file indicates that /jbpm-console/app/upload is trying to use servlet org.jbpm.web.ProcessUploadServlet. By default, this is marked to "0" for deploy on startup. However changing that to '1' doesn't seem to fix it either.
If I save the save the jBPM process as a .par, I can deploy it via the http://localhost:8080/jbpm-console web application UI - just can't deploy from JBDS.
you don't say which server profile you are using, nor whether you are using standalone or embedded SOA Can you please provide this information. however I suspect you are trying to use a secured war, try copying jbpm-console-development.war from jboss-soa-p.5.0.0/jboss-as/tools/resources to deploy/jbpm-console.war
I was using SOA-P 5.0 ER2 "default" configuration. I was using the full SOA distribution, not the standalone version. I don't think there is an embedded version of the SOA-P product. When I copied jboss-as/tools/resources/jbpm-console-development.war to jboss-as/server/default/deploy/jbpm.esb/jbpm-console.war, it worked. I don't think I've had to do that in the past when using the "default" configuration.
The full version of the product (also called embedded) now has a secured "default" profile as well as a secured "production" profile. We had to make a similar change within the ESB quickstarts.
Ahh, sorry. I forgot we called it embedded, thought it was just SOA Platform and SOA Standalone. If we do have to secure the "default" profile, can we at least make the error message in JBDS console useful? I think the error message said "consult the logs" but there did not appear to be anything in the console log. I'm not sure if the "consult the logs" error message is originating in JBDS or being sent to JBDS from SOA-P. In any case, I would guess quite a few people who have used SOA Platform in the past (and even new users that don't read all the docs) will run into this and spend a fair amount of time trying to figure out what is going on.
I have also encountered this same bug. Because default is now secured and it is officially the default again... The message produced by "ant deploy" in the quickstarts is misleading, it refers to the production config. I have to review the Getting Started & Readme.txts files to see if it clearly states what to update in the default\conf directory and quickstarts\conf directory. I agree that the error message from JBDS is misleading. I think we have two options: - Find a simple way to "unsecure" the default/deploy/jbpm.esb/jbpm-console.war OR - Ask the JBDS team to update the jBPM Plug-in so it can handle a login (admin, admin).
There has been a lot of discussion about this already. Refer to SOA-270 and its related issues. The two options are indeed as Burr suggests.
Link: Added: This issue is related to SOA-1339
Link: Added: This issue is related to SOA-270
Workaround Description: Added: copy jboss-as/tools/resources/jbpm-console-development.war to jboss-as/server/default/deploy/jbpm.esb/jbpm-console.war
So it turns out that actually a combination of the two options that Burr suggests are needed. I have created and implemented GPD-381 for the plugin to be able to handle a login. This works when the servlet that needs to handle deployment is protected by basic http authentication. Now in SOA-P the realm where the servlet lives is protected by form authentication. Maybe it is because of my ignorance but I did not find any way to deal with this way of authentication in a programmatic manner. If anybody knows a way how to do this please let me know. If this would not be possible (and maybe even if it is possible), I think the best way is to protect the deployment servlet (and only this one) with basic authentication.
In the web module deployment descriptor (web.xml) at most one login-config element may occur, which limits the entire application to a single authentication method. The upload servlet cannot be switched to BASIC auth alone unless the whole console switches to BASIC auth as well. I see two choices here: 1. Figure out how to do FORM auth programatically - Basically this means POSTing a form with the j_username and j_password fields. 2. Create a separate webapp just for the upload servlet - Unfortunately, different webapps cannot share the context path. The upload servlet path would change to "/gpd-deployer/upload" to avoid a clash with the console context path "/jbpm-console"
Project issue: JBPM-2678
Link: Added: This issue depends JBPM-2678
Marking as resolved since JBPM-2678 is done.
Link: Added: This issue related JBIDE-5611
SOA-P 5 will stay at jsf-console 3.3.1.GA and will not take jsf-console 3.2.8 as originally agreed. A patch for 3.3.1 is needed.
Attaching patch for jsf-console 3.3.1.GA. Also committed to http://anonsvn.jboss.org/repos/jbpm/projects/jsf-console/branches/jsf-console-3.3.1.SP/
Attachment: Added: soa-1586.diff
Link: Added: This issue related SOA-1569
Workaround steps for use with JBDS 3.0: [ldimaggi@ldimaggi jboss-as]$ pwd /opt/local/50_ER7_Jan14/jboss-soa-p.5.0.0/jboss-as [ldimaggi@ldimaggi jboss-as]$ cp -pR server/default/ server/development [ldimaggi@ldimaggi jboss-as]$ cp tools/resources/jbpm-console-development.war server/development/deploy/jbpm.esb/jbpm-console.war
I've changed the deployer servlet to catch the JpdlException and not print a stack trace when deploying malformed processes, just send an error status code and the problem description to the client. I tested GPD again and it still detects correct and invalid deployments properly, so no change is required on the Eclipse side.
Attachment: Removed: soa-1586.diff
New gpd-deployer servlet integrated in revision 4854 of: build.xml builders/jbpm-console/post-patch/patch_jbpm_console_ui.xml builders/jbpm-console/post-patch/patch_gpd_deployer_ui.xml builders/jbpm-console/pre-patch builders/jbpm-console/resource/web-production builders/jbpm-console/resource/gpd-console builders/jbpm-console/resource/gpd-console/jboss-web.xml builders/jbpm-console/resource/gpd-console/web.xml builders/jbpm-console/resource/web-development builders/jbpm-console/build.xml dependencies.properties revision 4855 of dependencies.properties and revision 4857 of: builders/jbpm-console/resource/jbpm-console builders/jbpm-console/resource/jbpm-console/web.xml Commit message: SOA-1586 Modify jbpm-console integration to handle extra gpd-deployer war file. Remove separate development and production jbpm-console war files.
Link: Added: This issue depends JBESB-3145
ESB base-build.xml has been updated to check for the existence of the gpd-deployer.war.
Need to verify this with JBDS 3.0 CR2.
Link: Added: This issue is a dependency of SOA-1932
Actually verified in 5.0 testing - closing now.