Hello,
I have a custom workspace user interface that was created in ES 8.2 and used the workspace SDK of 8.2. Will this workspace deploy in ES2? I tried throwing the ES 8.2 workspace into the ES2 deploy folder (like I would have for 8.2) but it does not work. Am I deploying this correctly or do I have to upgrade it to ES2 in order to work?
Thanks in advance.
Solved! Go to Solution.
Views
Replies
Total Likes
You need to use the same workspace ear that contains your custom workspace from LC 8.2 and deploy this on ES2.
This works because the server apis are backwards compatible, but you can't just move the swf forward because it is made to work with the html wrapper and supporting javascript from the same version that the swf was built on.
If you just replaced the stock workspace.swf with you custom version in the adobe-workspace-client.ear, then you will first have to remove the ES2 version of this ear from your ES2 appserver deployment, and then deploy the older version of the ear.
If your custom workspace is in a completely separate ear, then you may be able to deploy in in parallel with the ES2 adobe-workspace-client.ear. I say may, because it depends on the webapp name in this ear. If it is set to "workspace" (ie. the same as the installed webapp name), then they can't coexist so you will have to undeploy the ES2 adobe-workspace-client.ear, otherwise no problem with both of them running.
One last thing (i hope). If your webapp name is not "workspace", then you will have to register it by adding it to the AllowedUrls list. Do this by going to the adminui, export the UM config file (under Settings, User Manager, Advanced Config), add your webapp url to the AllowedUrls list, save the file, and import it back in. Not sure if a restart is required. ES2 requires all LC urls to be known to prevent any misbehaving redirects.
Hope that helps.
Jon
Views
Replies
Total Likes
You need to use the same workspace ear that contains your custom workspace from LC 8.2 and deploy this on ES2.
This works because the server apis are backwards compatible, but you can't just move the swf forward because it is made to work with the html wrapper and supporting javascript from the same version that the swf was built on.
If you just replaced the stock workspace.swf with you custom version in the adobe-workspace-client.ear, then you will first have to remove the ES2 version of this ear from your ES2 appserver deployment, and then deploy the older version of the ear.
If your custom workspace is in a completely separate ear, then you may be able to deploy in in parallel with the ES2 adobe-workspace-client.ear. I say may, because it depends on the webapp name in this ear. If it is set to "workspace" (ie. the same as the installed webapp name), then they can't coexist so you will have to undeploy the ES2 adobe-workspace-client.ear, otherwise no problem with both of them running.
One last thing (i hope). If your webapp name is not "workspace", then you will have to register it by adding it to the AllowedUrls list. Do this by going to the adminui, export the UM config file (under Settings, User Manager, Advanced Config), add your webapp url to the AllowedUrls list, save the file, and import it back in. Not sure if a restart is required. ES2 requires all LC urls to be known to prevent any misbehaving redirects.
Hope that helps.
Jon
Views
Replies
Total Likes
This worked. I was using the same ear file from 8.2, but I needed to add the URL to the AllowedUrls list in the config file. It does require a restart for the changes in the config file to take effect.
Thanks,
Joel
Views
Replies
Total Likes
Hello. I am not able to deploy any extra ear files to jboss. I am using flex builder 3 with the es2 sdk. the code has not been modified and compiled without errors to the export dir. "mycustomapplication.ear". Also i added the url to "allowedurls" section of the config.xml file
<entry key="ws-ls" value="/workspace/Main.html"/>
<!-- I added the following line to the config.xml file -->
<entry key="ws-ls" value="/mycustomapplication/Main.html"/>
Is there anything i can try?
JBoss logs reveal the follwing:
--- MBeans waiting for other MBeans ---
ObjectName: jboss.web.deployment:war=mycustomapplication.war,id=-818295244
State: FAILED
Reason: org.jboss.deployment.DeploymentException: URL file:/E:/Adobe/Adobe LiveCycle ES2/jboss/server/lc_turnkey/tmp/deploy/tmp6372851381847842274mycustomapplication.ear-contents/mycustomapplication-exp.war/ deployment failed
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=mycustomapplication.war,id=-818295244
State: FAILED
Reason: org.jboss.deployment.DeploymentException: URL file:/E:/Adobe/Adobe LiveCycle ES2/jboss/server/lc_turnkey/tmp/deploy/tmp6372851381847842274mycustomapplication.ear-contents/mycustomapplication-exp.war/ deployment failed
Thanks!
Views
Replies
Total Likes
The previous problem in this thread was about getting a customized workspace from a previous LC version work in ES2 so your problem is a bit different since you seem to be trying to use the ES2 customized workspace.
I think you have two problems, although your aren't getting to the second one yet:
1) for the ear deployment error, there should be more info in the log before what you included giving more details. I found a similar error in a bug logged against the custom workspace ear generation for ES2 and i don't think a patch is available yet - you will need to log an incident (the cause of the error is missing jars that should be in a lib folder under WEB-INF, and there are some other locale folder issues). This bug was found internally during the creation of the revised ES2 Workspace Customization documentation that will be made available around the same time as the first service pack for ES2 is released (April timeframe).
2) I think the key value in the AllowedUrls change you added needs to be unique. You left it as the same value as the default workspace key value ("ws-ls"). Not sure about this but if you get past the first problem by getting a patch from Support and still have problems, you may want to change this too.
Be advised: when you get a patch or service pack, the originally installed SDK folder is *NOT* updated. The new SDK zip can be found in the Patch folder.
Jon
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies