There are some questions an Internet search just isn’t so good at answering: What do I want for dinner tonight? How can I make a career change? Who is my ideal romantic partner? Asking a search engine any of these things will most likely result in a deluge of useless data rather than an excited “aha!” discovery. While we know that the “right” answer is out there, finding it can be like hunting for the proverbial needle in a haystack.
My latest paper discussing the GroupTogether system just appeared at the 2012 ACM Symposium on User Interface Software & Technology in Cambridge, MA.
I'm excited about this work -- it really looks hard at what some of the next steps in sensing systems might be, particularly when one starts considering how users can most effectively interact with one another in the context of the rapidly proliferating…
I just search for a way to clear facebook share cache and find this good article
In case it got deleted/removed, I will quote it here.
If you’ve used Facebook’s share functionality on an external website, you have probably by now figured out that the first time Facebook accesses the shared link, it generates a cache of the preview image and the copy. Here are a few tips to break the cache.
First, I should mention that the Facebook cache is there for good reason, to better handle load from their over 500 million users. The challenge comes in when you forgot to implement the proper meta information to make your share preview look as nice as it could, and you try to add it in after it’s been cached. You’ll change or add meta information, but Facebook still shows the older, crummy version.
Alternately, you can tack a query string onto the end of the url to make it a slightly different url in Facebook’s eyes, such as
This is fine for most manual share buttons, since you’re able to specify the url, but the problem comes in when you’ve got a website that people have already been sharing, with or without a share button provided.
The first time any user shared that specific url on Facebook, even if you didn’t have a share button implemented yet, Facebook cached the data.Facebook cached the preview image(s), the title and the description copy.
This caching also means that the first time you test what your site looks like in a Facebook share, it gets cached – so if the result isn’t what you wanted, you’ve now been hoist by your own petard.
Maybe you were ready, maybe you weren’t. Maybe you updated some copy, or came up with a better preview image. Either way, it can be frustrating to know that you’ve added or updated meta information and it’s still showing the older version.
It’s also a problem when you’re using the share widget that tracks the number of likes and shares from Facebook users. Changing that url, even slightly, will wipe out those stats, since Facebook sees it as a brand new url, so those 91k shares your page received will be zeroed out if you start mucking with the share url.
I’ve heard unofficial reports that Facebook caches this information for anywhere from one day to a week. This can be inconvenient at best, and cataclysmic at worst (in the case where a typo or critical copy change came down from corporate.)
Fortunately, there is a well-hidden tool that can help speed that up.
Facebook provides a URL Linter that will let you preview what your page will look like in the share preview without condemning you to being stuck with it for a week.
As you can see, the URL linter offers a preview, and some helpful debugging information about your url.
One side-effect of the URL linter is that it clears the cached data for the url you’re previewing.
Also be aware that, as we mentioned,
http://www.example.com/index.htmare two different urls according to Facebook. And depending on your server configuration,
example.commight also be different urls, so be sure to cover all your bases.
Because it’s Facebook, I would recommend not abusing this tool, and instead using it the way it was intended. Breaking the Facebook share cache should be a last resort, and you’ll be better served by using it to plan ahead instead of fixing things, since Facebook could remove or change this functionality at any time.
Instead, use the linter on a url before you launch to preview what the share will look like. Use it to perfect the preview image and copy, and then go live. (Note that it will not work if your website is password-protected via htaccess or IP restrictions, since the outside world can’t access it, which means Facebook can’t access it.)
Use the debugging beforehand to make sure your page is optimized for Facebook sharing, even if you don’t plan on implementing a share button on the page itself. Someone, somewhere is going to share that bad boy, so you may as well be ready.
To learn more about the meta tags to use to specify which images and copy you want Facebook to use in share dialog, check out the share docs. (Bear in mind that some reports state that Facebook stops crawling a page after a certain number of characters, so the higher up on the page this meta information appears, the better.)
create a file named “portal-ext.properties”
with one line of
put the file and logo image to your ROOT\WEB-INF\classes
restart the server, Liferay’s logo should be replaced with yours now
In case you already have web application (war), just put it in deployment folder ( “deploy” folder for tomcat and “deployment” folder for jboss )
After it is deployed, Liferay will see it as a portlet. To use portlet, go to your liferay homepage > add a page. Then select manage that page, your portlet will be located in “undefined” category. Add it to your page and you are ready to go.
#1 your war in your ear has to has .war extension, even it is a folder.
#2 If you use JAX-RS for RESTful webservice, make sure you comment out
in standalone.xml (or domain)
Besides, for jersey, you have to deploy your webservice as an exploded folder in delpoyment folder ( and make sure it has .war extension )
put this jboss-deployment-structure.xml to your ear’s META-INF
<?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure> <deployment> <exclusions> <module name="org.apache.log4j" /> </exclusions> </deployment> <sub-deployment name="your_war_folder.war"> <exclusions> <module name="org.apache.log4j" /> </exclusions> </sub-deployment> </jboss-deployment-structure>
for war deployment, put it in your WEB-INF
<?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure> <deployment> <exclusions> <module name="org.apache.log4j" /> </exclusions> </deployment> </jboss-deployment-structure>
หลังจากหนีไปทำ soldflow มา