Posts Tagged ‘decompilers’

Using Collaboration Server with Internet Explorer 11

Friday, April 3rd, 2015

Webcenter Collaboration 10gR4 was released in May 2013. Internet Explorer 11 was officially released in October/November of that year. Why is this a problem? Because, since Oracle has killed the entire product line, users are left high and dry with compatibility issues, getting a degraded version of Collab Explorer that’s missing key features like Bulk Upload:
collab-ie-11

Why is this? Because the abomination known as Internet Explorer threw developers yet another curveball in IE11: they changed the user agent string to one that doesn’t contain the characters “MSIE”. Sure, Oracle can be faulted for not following best practices on browser detection, but we’ve thrown enough angst Oracle’s way in this blog; it’s Microsoft’s turn today. I mean, they’ve used MSIE in their user agent strings for literally TWENTY YEARS; of course they should change it now to:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko

The solution is yet another Collab Hack requiring you to decompile code. Specifically, in collab-core.jar, we need to update com.plumtree.util.http.BrowserUtil.java. There are two places in the code that need to be updated; you’ll note I didn’t even attempt to implement a generic solution, but am specifically looking for this IE11 user agent string. That, of course, is not completely future-proofed, but since WCI is basically dead, and IE is getting killed off, I’m not too worried. The updated code will look something like this:

    private static float parseVersion(HttpServletRequest request, String searchPattern)
    {
        String userAgent;
        userAgent = request.getHeader("User-Agent");

	if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
		return 11.0F;
	......

… and:

    public static String GetBrowser(HttpServletRequest request)
    {
        if(InStr(request.getHeader("User-Agent"), "MSIE"))
            return "IE";
        else {
	        if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
				return "IE";
			else
	            return "NS";
		}
    }

(more…)

Hidden reset flag for WebCenter Interaction Analytics

Tuesday, March 25th, 2014

Recently I worked on a migration from some WebCenter Interaction servers to a virtual environment (you’re still using physical servers? How 2013…).

After the migration, there were some documents that weren’t showing up in WebCenter Analytics reports. As you probably know, Analytics events are stored in the ASFACT tables using objectIDs, and information about those events are captured in the ASDIM (dimension) tables to record information about those objectIDs (it’s done this way so that, even if you delete the object in the portal, you don’t lose the record of its access). But during some extensive testing, logging, and code decompiling, I discovered some interesting things that may be useful to you:

  • You can dramatically increase the logging that the Analytics sync job writes by changing the log settings to DEBUG in %PT_HOME%\ptanalytics\10.3.0\settings\config\sync-log4j.properties. This will give you details all the way down to the exact queries being run against the database.
  • The number of objects synched to the dimension tables, along with the results of the synch jobs, are stored in the ASSYS_JOBLOGS table – and that table is never cleared:
    wci-analytics-jobs
  • The Analytics Sync jobs that run nightly to update those dimension tables don’t actually look at all objects in the portal database; they look only look for objects that have been updated since the last time the job has run. This time comes from that ASSYS_JOBLOGS table.
  • There’s a hidden flag in the source code for the job called “-reset” that clears this job log table for that particular job entry, causing all objects for that job type to be re-scanned:
    wci-analytics-reset

Bottom line: if some of your Analytics reports don’t seem to contain all of the objects you’re expecting, it’s possible that events have been recorded but the dimensions simply don’t exist for them. If that’s the case, you can resolve this by adding -reset to the external operation in the WCI portal. Just remember to remove the flag after the job runs so that you’re not constantly clearing the logs every night and generating unnecessary load. (more…)

Cool Tools 22: Telerik JustDecompile

Saturday, May 5th, 2012

Years ago we featured some .NET Decompilers, which sparked a discussion about the cost of these tools (OK, it was just commenter Omid stating the Java equivalents were largely free).

Well, it’s time for a refresh on the .NET decompiler landscape – a new (to me at least) tool that I’ve used to successfully decompile and resolve issues with the Plumtree portal is Telerik’s JustDecompile. It’s as simple to use as the other tools we’ve featured and it’s free!

Cool Tools 18: HxD Hex Editor

Thursday, May 19th, 2011

Continuing our journey on increasing ALI Studio’s character limit, we’ve now identified the code that needs to change – it’s in com.plumtree. studio.model. data.access.TableDAO.java.

The problem is, Studio is ancient, so while we can easily update the following code:

  protected int mUserColumnWidth = 1000;
  protected int mUserColumnWidthChars = 1000;

… we can’t just recompile the file using the latest JDK without expecting problems.

So, we need to figure out what Java version was originally used to compile this file. To do this, we need today’s Cool Tool: HxD Hex Editor. Why? Because all Java .class files have the same set of bytes at the beginning identifying them as Java files, along with the JDK version used to compile.

HxD allows us to view the actual bytes, and and it does it well. Opening the TableDAO.class file in HxD, we see:

Bytes 6 and 7 are “00 2E”, which represent JDK 1.2.

Once we’ve made our changes and have the correct JDK downloaded, we rebuild the file, making sure to include the proper .jars in the CLASSPATH:

set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\log4j-1.2.8.jar
set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\jakartaRegexp1dot2.jar

C:\jdk1.2.2\bin\javac -classpath %CLASSPATH% com\plumtree\ studio\model\ data\access\ TableDAO.java

Take the TableDAO.class file, jam it back into your studio.war file, and you’re good to go – assuming you haven’t increased that value over 4,000 characters! There’s still one more glitch in this journey

Increase Plumtree Studio Character Limit

Monday, May 16th, 2011

We don’t write much about Aqualogic Interaction Studio ’round these here parts anymore. That’s because Studio has long since been end-of-life’d (by BEA, even before the Oracle acquisition!). But, that doesn’t mean it isn’t alive and gasping its last breath in many of your portal sites. Sure, it’s an over-the-hill product but it does serve a functional need: the ability to easily create forms, polls, and other data entry forms.

So, it’s with reluctant enthusiasm that I start the first of a three-part series on “How to increase the 1,000 character limit in Plumtree Studio”. Even if you don’t actually use Studio, hopefully you’ll find the journey interesting and informative for your other portal diagnostic needs. I’ll walk you through the process of identifying the code here, recompiling and reintegrating in Part dos, then some SQL Server diagnostics in Part tres.

The problem, as recently presented by a client, was that Studio has a 1,000 character limit on text fields. If an end user tries to type more than 1,000 characters, they get this lovely message:

But, we needed to increase that value. While it would be really nice if there was just some configuration file somewhere, sadly, the 1,000 character limit is hard-coded. So we first need to find the file that’s producing this alert. (more…)

Cool Tools 16: JD-GUI Java Decompiler

Sunday, April 3rd, 2011

There was a spirited discussion in the comments for our .NET decompiler post (hey, 2 comments is close to the record for this blog!), and this is long overdue, but in the past year, I’ve become a fanatic user of Emmanuel Dupuy’s JD-GUI Java Decompiler.  It’s free, it works, and it has the ability to decompile entire Java .jar files at once, saving all the source in a folder structure that matches the original source/package names.

The package export capability is excellent when you’d like to see what has changed between portal releases; you just decompile the WCI code before and after, and use Beyond Compare to highlight the differences between builds.

JD-GUI has been my tool of choice for many posts on this blog, and if you’re into getting down and dirty with your WebCenter Interaction Java code, I highly recommend this bad boy:

JD-GUI is a free download here, but I suggest throwing these guys a couple bucks for the donationware.  C’mon, 20 bucks, anyone?  (before you ask, yes, I contributed to the cause..)

 

Cool Tools 5: .NET Decompilers

Wednesday, April 21st, 2010

Any self-respecting programmer has a suite of decompilers in their arsenal.  Hey, the WebCenter Interaction portal is great, but it’s not without its fair share of bugs, and often Oracle Support isn’t going to give you a lot of, well, support – so sometimes you need to take matters into your own hands.  Today’s Cool Tools are two of the best .NET decompilers I’ve used; I’ll have a post for Java decompilers soon.

I’m kind of split on this one and go back and forth between Dis# Decompiler and Red Gate’s .NET Reflector.  I do a lot of decompiling, and both have proven relatively useful. As professional tools, they’re not cheap ($399 and $195 for the professional versions, respectively), but can save hours of time, and both have free trial versions.  Red Gate’s Reflector even has free version available.

Personally, I sway a little more to Dis# Decompiler for one reason:  You can have it decompile ALL class files in a .DLL at once.  This is highly useful if you’re looking at bad portal code and are trying to search for a particular string somewhere in the portal libraries, but don’t know which class it might be in; you can decompile everything to disk and search with a text tool.  Red Gate, on the other hand, offers Visual Studio integration – which I haven’t tried yet – that promises to allow you to step through compiled code like you would with your own source.

So there you have it – two decent tools to check out when it comes time to figuring out why something’s broken.  Let me know if you’ve got a preference, or feel free to recommend something else!

Dis# Decompiler

Red Gate’s .NET Reflector