In Inline Editing with WLP 10.3.2 Content Templates, I concluded that if something else came up I would blog it. Well, it did, so I will.
The shared library part went nice and smooth. To note the (semi-)obvious, the wlp-template-config.xml changes noted in the post must be done in the consuming application, not the shared application, as the consuming application always over-rides.
The part I forgot about was that you must create a role for editing the content or else only Admins will be able to do the inline editing. I created an enterprise role named "homePageContentAdmin" for my first test, then granted that role update privelages on the content item. Once I did that, it worked properly.
As another sort-of-obvious note, this requires granting view privelages for anonymous or authenticated roles for other users to view the content.
Tips, thoughts, technologies and techniques used in enterprise portal solutions. Originally published at Head in the Web
Thursday, June 24, 2010
Wednesday, June 23, 2010
Catching the Un-Catchable
I know it is bad practice to catch java.lang.NoClassDefFoundError. Today, however, I did need a way to deal with it because I have this annoying habit of wanting everything else to work even when some non-critical piece is broken.
This case was a matter of a third-party security jar that would throw up rather than out when it could not find its properties file. No matter how many catches I had wrapped around the call to the method in the jar, the java.lang.NoClassDefFoundError would bubble up as a big render issue in the JSP. I am only using this jar to get the user display name, so it isn't like my application is not secure if I don't have their name to make them feel special.
After several annoying an pointless approaches, I came up with the following (ugly-but-effective) solution:
This allowed the application to continue running and not falling apart at the header just because one file was missing. It is one thing to have a bug that is minor, another when that bug becomes something that users pick up the phone about.
This case was a matter of a third-party security jar that would throw up rather than out when it could not find its properties file. No matter how many catches I had wrapped around the call to the method in the jar, the java.lang.NoClassDefFoundError would bubble up as a big render issue in the JSP. I am only using this jar to get the user display name, so it isn't like my application is not secure if I don't have their name to make them feel special.
After several annoying an pointless approaches, I came up with the following (ugly-but-effective) solution:
try//the Security class relies on this property file but pukes if not found, so we test for it here
{
FileInputStream in = new FileInputStream("security.properties");
in.close();
}
catch(Exception e)
{
System.out.println("security.properties is missing from classpath");
return personInfo;
}
...go use the third-party class that depends on the file having proven it is there
This allowed the application to continue running and not falling apart at the header just because one file was missing. It is one thing to have a bug that is minor, another when that bug becomes something that users pick up the phone about.
Friday, June 18, 2010
Inline Editing with WLP 10.3.2 Content Templates
Carrying on from WLP Content Presenter Portlet Simplified, the next goal is to get the in-line editing from the sample application running because most clients think that is a cool feature and don't understand why it isn't available by default. Right now I am almost done, and wanted to blog the progress to date, even if the most important part won't be done until Monday...
There is a really (really, really) brief instruction in the official documentation to do this here. I'm sure if you have been building content templates for years that document will be enough, just as I'm sure that if that were the case you won't be reading this (unless to make tsk-tsk noises at my ignorance). The files to import can be taken straight from there, which is:
Now, the first time I tried this, I wanted my own paths and renamed everything. It didn't work. I'm sure I can rename them now, but at this stage the important thing is to get it working, with re-branding to the custom project being secondary.
The next step is to add these to the wlp-template-config.xml. Where the manual tells you to make your own, I find it much easier to simply go to the merged view and copy in the one from the shared install. While this may make a little more work for future WLP upgrading, it is worth it to me to save the time. With the file now in my project, I get the copy from the sample application and added the nodes to my own application that reference the files imported earlier. The relevant parts of the resulting file are below:
Now, for this to work, you have to create a content type of named "htmlContent". I created this type with no parent and a primary property named "content" of data type binary.
I'm still testing to find out if the content needs to include ".html" as a suffix to the name. And, yes, you can by-pass much of this "have to" stuff if you re-write everything, but the goal here is to get it deployed and have business users editing content today :)
I thought I had it with that, as I could then set the content in an instance of the Content Presenter portlet as a piece of content of the type htmlContent and see the Edit HTML button, but nothing happened on clicking it. Dang! Running it in FireFox (the project was targeted at IE, otherwise I would have started in FireFox), I found the disconcerting message "wlp dojo is not defined".
Ok, I haven't used the Dojo tookit yet. I have been building stuff by hand for so long, I just haven't had the need to use a pre-built JS framework, even one that is as highly praised as Dojo. So I'm not sure if I went about it the best way to get this fixed, but it was the fastest. I searched through the sample directory until I found dojo.js (in Windows, it was located at [WEBLOGIC_HOME]\wlportal_10.3\samples\domains\portal\servers\portalServer\tmp\_WL_user\portalApp\4ycmg9\beaext\dojo-0.4.3-ajax ). I also found that in inlineEditExampleCMTemplate.jsp, the path it was looking for was ${pageContext.request.contextPath}/dojo-0.4.3-ajax/dojo.js. I tried importing it directly to my project from OPOE, but it must be compressed or the path is too long, so I did a copy/paste to a temp directory and imported it from there.
And, viola! It worked.
Now all that is left is to make the web project into a shared library so that I don't have to turn off validation is my "real" project. If there is anything out of the ordinary with that process I will blog about it here. Otherwise, go forth and edit.
There is a really (really, really) brief instruction in the official documentation to do this here. I'm sure if you have been building content templates for years that document will be enough, just as I'm sure that if that were the case you won't be reading this (unless to make tsk-tsk noises at my ignorance). The files to import can be taken straight from there, which is:
- Display Template (Outer Template) –
<WLPORTAL_HOME>\samples\applications\portalApp\ contentPresenterSampleWeb\samplePresenterTemplates\ inlineEditExamplePresenterTemplate.jsp
- CM Display Template (Inner Template) That Displays the Content – <WLPORTAL_HOME>
\samples\applications\portalApp\contentPresenterSampleWeb\sampleCMTemplates\inlineEditExampleCMTemplate.jsp
- JSP File that Performs Other Work – <WLPORTAL_HOME>
\samples\applications\portalApp\contentPresenterSampleWeb\sampleCMTemplates\saveNode.jsp
Now, the first time I tried this, I wanted my own paths and renamed everything. It didn't work. I'm sure I can rename them now, but at this stage the important thing is to get it working, with re-branding to the custom project being secondary.
The next step is to add these to the wlp-template-config.xml. Where the manual tells you to make your own, I find it much easier to simply go to the merged view and copy in the one from the shared install. While this may make a little more work for future WLP upgrading, it is worth it to me to save the time. With the file now in my project, I get the copy from the sample application and added the nodes to my own application that reference the files imported earlier. The relevant parts of the resulting file are below:
Under <content-name-space><name>wlp-content-presenter-single</name>:
<content-resource>
<name>htmlContent</name>
<default-template-uri>/portlets/wlp-content-publisher/templates/wlp-default/cm/wlp-default-resourceDefault.jsp</default-template-uri>
<view>
<name>Show</name>
<description>This is the detailed node view for simple HTML content in the Avitek Financial Intranet sample.</description>
<uri>/sampleCMTemplates/simpleShowView.jsp</uri>
</view>
<view>
<name>ShowEdit</name>
<description>This is the detailed node view with inline
editing for simple HTML content in the Avitek Financial
Intranet sample.
</description>
<uri>/sampleCMTemplates/inlineEditExampleCMTemplate.jsp</uri>
</view>
</content-resource>
Under <template-name-space><name>wlp-content-presenter-single</name>:
<view>
<name>Sample Single Item View with Inline Edit</name>
<description>This is the sample Content Presenter Display Template view for a single item that provides inline HTML editing.</description>
<uri>/samplePresenterTemplates/inlineEditExamplePresenterTemplate.jsp</uri>
</view>
Now, for this to work, you have to create a content type of named "htmlContent". I created this type with no parent and a primary property named "content" of data type binary.
I'm still testing to find out if the content needs to include ".html" as a suffix to the name. And, yes, you can by-pass much of this "have to" stuff if you re-write everything, but the goal here is to get it deployed and have business users editing content today :)
I thought I had it with that, as I could then set the content in an instance of the Content Presenter portlet as a piece of content of the type htmlContent and see the Edit HTML button, but nothing happened on clicking it. Dang! Running it in FireFox (the project was targeted at IE, otherwise I would have started in FireFox), I found the disconcerting message "wlp dojo is not defined".
Ok, I haven't used the Dojo tookit yet. I have been building stuff by hand for so long, I just haven't had the need to use a pre-built JS framework, even one that is as highly praised as Dojo. So I'm not sure if I went about it the best way to get this fixed, but it was the fastest. I searched through the sample directory until I found dojo.js (in Windows, it was located at [WEBLOGIC_HOME]\wlportal_10.3\samples\domains\portal\servers\portalServer\tmp\_WL_user\portalApp\4ycmg9\beaext\dojo-0.4.3-ajax ). I also found that in inlineEditExampleCMTemplate.jsp, the path it was looking for was ${pageContext.request.contextPath}/dojo-0.4.3-ajax/dojo.js. I tried importing it directly to my project from OPOE, but it must be compressed or the path is too long, so I did a copy/paste to a temp directory and imported it from there.
And, viola! It worked.
Now all that is left is to make the web project into a shared library so that I don't have to turn off validation is my "real" project. If there is anything out of the ordinary with that process I will blog about it here. Otherwise, go forth and edit.
Monday, June 14, 2010
REST Logout for WLP with JSP 2.0 EL
I used to create the log out URL like this:
Then, today I needed to have it in a Bighorn skeleton, so I came up with the following:
With the URL in hand, you can now make the logout call:
String webAppName = request.getRequestURI().substring(1);
String webAppPath = request.getRequestURL().substring(0, request.getRequestURL().indexOf(webAppName));
String restLogout = webAppPath+webAppName.substring(0, webAppName.indexOf('/'))+"/bea/wlp/api/logout?invalidate_session=true";
Then, today I needed to have it in a Bighorn skeleton, so I came up with the following:
<c:set var="webAppName" value="${fn:substring(pageContext.request.requestURI, 1, fn:length(pageContext.request.requestURI))}" scope="application" />
<c:set var="webAppPath" value="${fn:substring(pageContext.request.requestURL, 0, fn:indexOf(pageContext.request.requestURL, webAppName))}" scope="application" />
<c:set var="restLogout" value="${webAppPath}${fn:substring(webAppName, 0, fn:indexOf(webAppName, '/'))}/bea/wlp/api/logout?invalidate_session=true" scope="application" />
With the URL in hand, you can now make the logout call:
function portalLogOut(restURL)
{
var xmlhttp = null;
if (window.XMLHttpRequest)// code for IE7, Firefox, Mozilla, etc.
{
xmlhttp=new XMLHttpRequest();
}
else if (window.ActiveXObject)// code for IE5, IE6
{
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
if(xmlhttp.overrideMimeType)xmlhttp.overrideMimeType('text/xml');
if (xmlhttp!=null)
{
xmlhttp.open("POST",restURL,true);
xmlhttp.send(null);
}
}
Friday, June 11, 2010
IE OnResize Scripting
I ran into some ugliness recently setting an iFrame height dynamically where the script would run away on IE. I found the answer at http://stackoverflow.com/questions/1500312/javascript-onresize-event, posted by Pim Jager. The resulting combination of the resize and his event handling is as follows:
One note about resizing elements is that IE will resize again if your new size causes the document size to grow. That was a two hour lesson for me :)
function getDocHeight()
{
var D = document;
return Math.max(
Math.max(D.body.scrollHeight, D.documentElement.scrollHeight),
Math.max(D.body.offsetHeight, D.documentElement.offsetHeight),
Math.max(D.body.clientHeight, D.documentElement.clientHeight));
}
function setIframeHeight(frameId, offset)
{
document.getElementById(frameId).height = (getDocHeight()-offset)+'px';
}
var resizeIframeTimeOut = null;
var func = function() {setIframeHeight('boInfoViewIframe', 150);};
window.onresize = function(){
if(resizeIframeTimeOut != null) clearTimeout(resizeIframeTimeOut);
setTimeout(func, 100);
};
setIframeHeight('boInfoViewIframe', 150);
One note about resizing elements is that IE will resize again if your new size causes the document size to grow. That was a two hour lesson for me :)
Wednesday, June 9, 2010
Early Morning Security Ramblings
Posting it here for those that don't belong to LinkedIn or subscribe to Answers there:
A: As others have noted, the security of the individual applications written in these languages depends on the development approach used. The next level from their is the application servers, which really depends on the app server vendor for Java and again back to the developer and the server admin. And, of course, the servers sit inside an operating system, which adds another layer of vulnerability. This is point where the earlier poster who noted that Microsoft is more often the target comes in to play. Microsoft is more often targeted, which increases the likelihood of someone trying to break in. However, the biggest threat is admins and/or policies that prevent keeping up to date on patches. Then there is the architecture as a whole, where there are points in the network, structure of the firewalls and accessibility of data. There are still plenty of admin servers that have the default log in credentials set.
Then again, the vast majority of real digital break ins come from the hacker knowing passwords in advance, which is an issue that is platform independent :)
Q: Which Tastes Better for Security, Java or .NET?
Both this two languages are safe by security point of view with their own levels, but which one tastes better w.r.t your working experience?
A: As others have noted, the security of the individual applications written in these languages depends on the development approach used. The next level from their is the application servers, which really depends on the app server vendor for Java and again back to the developer and the server admin. And, of course, the servers sit inside an operating system, which adds another layer of vulnerability. This is point where the earlier poster who noted that Microsoft is more often the target comes in to play. Microsoft is more often targeted, which increases the likelihood of someone trying to break in. However, the biggest threat is admins and/or policies that prevent keeping up to date on patches. Then there is the architecture as a whole, where there are points in the network, structure of the firewalls and accessibility of data. There are still plenty of admin servers that have the default log in credentials set.
Then again, the vast majority of real digital break ins come from the hacker knowing passwords in advance, which is an issue that is platform independent :)
Tuesday, June 8, 2010
JDBC BEA-001129
If you don't have a LinkedIn membership, this discussion should be enough reason to sign up (for the record, I did not provide the responses to this question):
Q:
A:
Q:
I have a problem in production environment with WebLogic 9.2 mp3.We are using Multi datasource with Oracle 9i RAC two nodes. Database team have maintaince so they took out one node out of RAC. when one of the WebLogic instance associated with connection pool to that RAC node shown the following Warning message and could not start the instance.The multi datasource is configured with algorithm-type as "Load-Balancing"
<Jun 3, 2010 3:12:23 AM EDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING>
<Jun 3, 2010 3:14:10 AM EDT> <Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "DS2": Io exception: The Network Adapter could not establish the connection>
What are the recommandations to avoid this kind of problems when one of the RAC nodes down and the WebLogic server should have High Availability and scalable?
Any configuration parameters need to set for this??
A:
The way 9.2 mp3 works with RAC is that the multidatasource represents a pool of datasources so if one datasource is not available it will mark that down and use the other datasources configured in the multidatasource. WLS controls the failover, not RAC and this version does not use FAN or FCF.
I assume you have test on reserve set in the connection of all the data sources as that is required to use multdatasource. This parameter is at datasource->connection pool-> advanced
"could not start the instance" means that WLS did not come up??
If you are bringing up a WLS instance without the DB up you may want to set initial connections to 0
Wednesday, June 2, 2010
WebLogic Portal (WLP) Lost Samples in 10.3.2
Ran across a fun new quirk this morning. To make sure that source control has everything necessary for a build I maintain two workspaces and check the build in one after a check in from the other. There were two errors today. One was just weird, which is that the path of WEB-INF/src somehow became required. Annoying, but no big deal to check it in (and probably could have removed it from org.eclipse.wst.common.component and .classpath without causing an issue).
The quirky part was the second error, which was that it was unable to resolve the reference to "wlp-sample-widgets-web-lib" library. I went to the WebLogic shared libraries in preferences, and sure enough it wasn't there. Long story short, the sample widgets are not configured in a workspace unless it is added to a project in that workspace. The fix was to remove and then add the facet back in and then OEPE installed it into the workspace.
The quirky part was the second error, which was that it was unable to resolve the reference to "wlp-sample-widgets-web-lib" library. I went to the WebLogic shared libraries in preferences, and sure enough it wasn't there. Long story short, the sample widgets are not configured in a workspace unless it is added to a project in that workspace. The fix was to remove and then add the facet back in and then OEPE installed it into the workspace.
Subscribe to:
Comments (Atom)