Notes on working with Sharepoint 2010 Web Services

Recently, I've been working on a project that requires writing a Java client to Microsoft Sharepoint's web services. Aaron Digulla wrote an excellent introduction to navigating Sharepoint folders that I found very helpful in getting started.

It's important to note that in order to get the items in the subfolders of a given List, you must specify the Folder in QueryOptions (when invoking the GetListItems operation, that is). Otherwise, it seems you just get the top level items in the given List.

I've discovered a couple of other useful tips.

One is to use the query parameter to narrow down results returned by GetListItems. For example, I have a few cases where I only have the GUID for a particular file or folder but not the URL. So far, I haven't found another way to do this except to search the List items. Fortunately (if I at least know the List) a query makes this pretty simple. The SOAP request looks, in part, like this:

<soap:query>
<Query>
  <Where>
    <Eq>
      <FieldRef Name="UniqueId"/>
      <Value Type="Lookup">

        {552bef05-b62c-4c76-a217-35e85a1507f1}

      </Value>
    </Eq>
  </Where>
  <OrderBy>
    <FieldRef Name="Modified"/>
  </OrderBy>
</Query>           
</soap:query>

Another useful operation is GetObjectIdFromUrl from the Webs service. Given a URL, this will return some helpful properties for the URL such as the List it belongs to, its ListItemId, and whether it represents a file or a folder.

32 or 64 bit Java?

I did a little research yesterday morning on the question of the impact of using 32 v. 64 bit Java. Here's what I found.

The short answer is that for building, it doesn't really matter at all. You can think of the 64 bit JVM as just another platform for your java classes to run on. So just as you can build your Java app on your Windows laptop and deploy it to a machine running Linux, you can build on a 32 bit system using 32 bit java and deploy to a 64 bit system running 64 bit java, or vice versa. The Java bytecode is still independent of the processor architecture.

The main advantage of a 64 bit virtual machine is the ability to access much larger heap sizes. Also, the virtual machine can manage many more threads (probably good for a web server that is handling thousands or millions of requests simultaneously). While the theoretical limit for heap size on a 32 bit system is 4GB, in practice the maximum varies from 1.5G to about 3G. I believe a 32 bit JVM running on 64 bit system might be able to get closer to that 4GB limit (have to check on that). A 64 bit JVM should be virtually unlimited (as long as there is enough physical memory on the system).

Now, because a 64 bit JVM uses pointers that are double the size of the 32 bit JVM (64 v 32), it uses more memory on average. It is also somewhat slower. For these reasons, and until my project has a need to use a much larger heap size, I've recommended distributing the latest 32 bit JRE with our software and keeping our CI environment at 32 bits. For developer environments, we can use whatever suits us.

References:

1. Frequently Asked Questions About the Java HotSpot VM (64-bit Java).

http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_descript

ion

2. 64-bit versus 32-bit Virtual Machines for Java.

http://portal.acm.org/citation.cfm?id=1107407

3. Java Tuning White Paper:

http://java.sun.com/performance/reference/whitepapers/tuning.html

Unlocking an Oracle 10g user account

So how do you unlock an Oracle user account?

1. Login as the oracle dba user (this is the account that is in the dba group)

2. Connect to the database as a DBA.

$ sqlplus / as sysdba

3. It's a straightforward command to unlock.

SQL> ALTER USER username ACCOUNT UNLOCK;

And that's it.