Sunday, November 27, 2005

http://www.internetpolyglot.com is deployed

www.internetpolyglot.com is deployed. This site is for language learners who want to increase their vocabulary. It contains free language word lessons. Learn English, learn Spanish, learn German, learn French, learn Chinese, learn Russian, learn any other language of your choice using this site. It also contains a bunch of language related articles including acronyms, synonyms, antonyms, etc.

Monday, April 11, 2005

VBA calls Web Service but ends up on localhost

Have you tried to use a Web Service from Microsoft Excel? It shoud be fairly easy. And it certainly is once you go over some hurdles.

You simply google for "VBA web service" and get lots of links that tell you how to call web services from Excel or any VBA programs. I don't know why but all of them work only in simple environment of localhost but break when you try to point to your web service on another machine.

So, what all these articles recommend to do is the following:

  • Create a macro and assign it to a button or other action and use VBA to write the Web Service Call
  • Add a “Reference” to the VBA Function to the SOAP Type Library and to Microsoft XML, v3 or v4
  • Connect to the Web Service using the following:
Private client As SoapClient
client.MSSoapInit http://localhost:7001/webservices/ws/test/HelloWorldContract.wsdl
  • Call the methods on the web service:
hello = client.getHello()

Everything works OK until you move your web service on another machine. In this case WSDL is read fine but the call of web service's method gets timed out. And the SOAP sniffer shows no traffic from the client machine.

To save your time I will not put here entire debugging process. What I have found that even though the initialization is done using the WSDL on the remote machine, the web service call itself goes to the localhost. Here is the code that works when the web service is deployed not on localhost:



Public Sub test()
Dim client As MSSOAPLib.SoapClient
Set client = New SoapClient
Dim hello As String

Call client.mssoapinit("http://moscow:7001/webservices/ws/test/HelloWorldContract.wsdl", "HelloWorld", "HelloWorldSoap")
client.ConnectorProperty("EndPointURL") = "http://moscow:7001/webservices/ws/test/HelloWorld.jws"


hello = client.getHelloWorld()

End Sub



Now it works fine. The key line here is setting EndPointURL connector property of the client.



* Example web service is developed and deployed under Weblogic Workshop:


package ws.test;

import java.util.Date;

public class HelloWorld implements com.bea.jws.WebService
{
static final long serialVersionUID = 1L;

/**
* @common:operation
*/
public String getHelloWorld() {
System.out.println("HelloWorld.getHelloWorld is called at " + new Date());
return "Hello World!";
}
}

Thursday, March 31, 2005

From Eclipse to Weblogic Workshop

Moving your java code from Eclipse v.3 to Weblogic Workshop v.8.1

This document describes the steps necessary for moving your java code
written in Eclipse (or any other similar IDE) to Weblogic Workshop v.8.1.
There are several differences between the styles of handling java files
and this document shows how to overcome them.

In this document I assume that you have already some java code written
and placed in some folder. In our example this folder is called "javasource"
but it can have any name.


Create project, compile and run a standalone module

  • Create an application in Workshop,
    point it to the root directory of your enterprise application


  • Right-click on the application name, select "Import",
    select "Java Project" on the right side of the dialog,
    browse to the root catalog of your java source,
    uncheck "Copy into Application directory", press "Import" button.



    Now the project is imported but not compiled.
  • Right-click on javasource project, select "Properties"

    • In "Path" add all jar files that you use for project compilation.


    • On default Workshop's build process cleans up the output directory
      and recompiles only java files into the output directory.
      So if you have *.xml or *.properties files in the source directory
      they will disappear in the output directory.
      In order to fix it do the following:

      In "Build" browse to your output directory in
      "Java Project-->Output .class files to".



      Next press "Export to Ant file" button at the top in "Build Type".
      This will create exported_build.xml file in the root directory
      of your java source.
      Modify it by adding after <javelin>...</javelin> tag the following:

      <copy todir="${dest.path}" overwrite="true" flatten="false">
      <fileset dir="${src.path}">
      <exclude name="**/*build*.xml"/>
      <exclude name="**/*ant*.xml"/>
      <include name="**/*.properties"/>
      <include name="**/*.xml"/>
      </fileset>
      </copy>
      Save this file. On the project properties window in "Ant Settings" browse to this file and change
      "Build Type" to "Use Ant buld".



    • In "Debugger"

      • Direct to your output directory in "Home directory" -
        this will allow you to run standalone java applications
        (i.e. "main" methods) having this directory as root
        so your files can be found.
      • Add your output directory to the "Application classpath"
      • Again add all necessary jar files to the "Application classpath" -
        this time it is needed for the run-time environment.


    • Press "OK" on "Project Properties" window.
  • Select in Main Menu "Build-->Build Project-->javasource"
    and verify that the java project is successfully compiled into the output
    directory. Verify that your *.xml and *.properties files are also
    copied into the output directory.
  • Verify that standalone applications run in this environment:

    • Right-click on "javasource" project and select "Properties"
    • In "Create new process settings-->Main class"
      enter a name of your class that has "main" method
    • From the Main Menu select "Debug-->Start":
      watch the project rebuilding and outputs from the main method
      of your class (if you have System.outs or logger's messages in it)

Compile a Single Java File

On default Workshop cannot compile a single Java file;
it can only do builds on a project basis.
The following link of WL Workshop documentation describes
what is needed to be done in order to be able to compile a single Java file.

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/howdoi/howCompileASingleJavaFile.html?skipReload=true


Instruction Notes

  • If your .workshop.pref file gets screwed up - do not worry. Simply delete it and restart Workshop.
    Workshop will recreate the default version of the file.
  • Both following entries work fine:

    <component name="workshop.workspace.tools.CustomToolAction">

    and

    <node name="workshop.workspace.tools.CustomToolAction">

    Note, that the above document operates with "component"
    and if you recreate the pref file, it will have "node". They both work OK.
  • After you insert <node name="javac"> tag in .workshop.pref file,
    save this file and restart the Workshop you will see the following error:



    Press "Exit" here and return to .workshop.pref file.
    Change the following line

    <option name="command" value="compile.cmd "${file.path}"" />

    by removing double quotes around ${file.path}. It should look like this now:

    <option name="command" value="compile.cmd ${file.path}" />

    Save the file, restart Workshop and see that the menu item "javac"
    appears under "Tools-->External Tools"

Further Customization

In order for the single file compilation process to be more usable
in the team development environment I have done the following changes:

  • In .workshop.pref under <node name="javac">
    instead of "C:\build_scripts" I put the javasource project home folder
    "C:\NMS\2005.1\javasource".
  • Put compile.cmd in this folder.
    Now compile.cmd can be checked in in your source control system.
  • Modify compile.cmd the following way:

    • set PATH=C:\bea\jdk142_05\bin;

      If you have later version of JDK don't point
      PATH to its "bin" directory; when I tried that,
      at run-time I got an error related to versions incompatibility
    • set CLASSPATH="%CLASSPATH%;[your jars relative paths]"

      Notice that double quotes are around entire entry.

      [your jars relative paths] can be found in your *.work file:
      search for "class.path" string in it and copy the list of jar
      relative paths from its value.
    • Now the compile.cmd file can be checked in your CVS or VSS.

Let's test this now.

  • Open a java file, go to "Tools --> External Tools --> javac"
    and see that this file compiles to your output directory to the right
    place
  • Open project properties and in "Debugger" area uncheck
    "Build before debugging" - this will prevent from building the entire
    project every time you start a java standalone file
  • In the same window specify your java file in
    "Create new process settings --> Main class".
    Do not type the file extension here. Press OK button.
  • Make sure that your java file has the "main" method.
    Don't forget it has to have the following signature:

    public static void main(String[] args) {...}
  • Press the "Start" button. See your file's main method's output.

    Do not forget though that for your next project you will have
    to add another entry in your .workshop.pref file and point it
    to another directory.

    In the future it makes sense to fix the situation when you need
    to specify the classpath of all your jars in three places.
    It should be somehow centralized.

Congratulations!

You have successfully migrated from Eclipse to Workshop and can now
enjoy the full power of Workshop fast development environment.