Clearing user credentials for svn repository in subclipse

Some times, we come across a situation where we want to remove the username/password that is being used by subclipse for accessing svn repository. 

JavaHL caches the information in the same location as the command line client -- in the Subversion runtime configuration area. On Windows this is located in %APPDATA%\Subversion\auth. On Linux and OSX it is located in ~/.subversion/auth. Just find and delete the file with the cached information.

SVNKit caches information in the Eclipse keyring. By default this is a file named .keyring that is stored in the root of the Eclipse configuration folder. 

 To clear the cache, you have to delete the file. Eclipse will create a new empty keyring when you restart.

In short, we have to delete  -

1. files under  %APPDATA%\Subversion\auth and 

2. other file named .keyring under eclipse configuration folder

Reference - http://subclipse.tigris.org/wiki/PluginFAQ

How to invoke application in Websphere 7 using EJB 3.x

1.       Create simple EJB as shown below (Used eclipse to create stateless session bean  ) –

@Local

public interface EJBProcessFlowRunMgrBeanLocal

{

….

…

}

@Remote

public interface EJBProcessFlowRunMgrBeanRemote

{

….

…

}

@Stateless

public class EJBProcessFlowRunMgrBean implements

      EJBProcessFlowRunMgrBeanRemote, EJBProcessFlowRunMgrBeanLocal

{

 // Implement the methods in EJBProcessFlowRunMgrBeanRemote and  //EJBProcessFlowRunMgrBeanLocal

….

}

2.       Create an ear and deploy it in Websphere (I tested on WAS 7).

3.       Set the JNDI name in Websphere

4.       Create the EJB stubs for client

For many client-side scenarios, the WebSphere Application Server Just-In-Time (JIT) deployment feature dynamically generates the RMI-IIOP stub classes that are required for invocation of remote EJB 3.0 business interfaces. However, there are some scenarios where the JIT deploy environment is not available to dynamically generate these classes. In these scenarios, the createEJBStubs command must be used instead to generate and embed the client-side stub class files in your client application. If your client environment is one of the following, use the createEJBStubs command:

• "Bare" Java Standard Edition (SE) clients, where a Java SE Java Virtual Machine (JVM) is the client environment.
• A WebSphere Application Server container (web container, EJB container, or application client container) from a version earlier than version 7, or without the Feature Pack for EJB 3.0 applied.
• Non-WebSphere Application Server environments.

To generate stubs for each JAR EJB3 JAR file in the MyEar.ear and add them to the corresponding JAR files in MyEar.ear:

createEJBStubs MyEar.ear  

To generate stubs and put them into MyJar_withStubs.JAR, along with the original files from MyJar.JAR type the following:

createEJBStubs MyJar.JAR -newFile 

To generate stubs for each JAR EJB3 JAR file in the MyEar.ear and copy the original files to the NewEar.ear , and add the stubs to the corresponding JAR files, type the following:

  createEJBStubs MyEar.ear -newfile NewEar.ear -logfile MyLog.log -verbose  

5.       Create the standalone client ( I used Java from IBM – just copy the jdk from IBM WAS and use it in eclipse )

      Properties props = new Properties();

      props.put(Context.INITIAL_CONTEXT_FACTORY,

            "com.ibm.websphere.naming.WsnInitialContextFactory");

      // HOST_NAME – abc.com, BOOTSTRAP_ADDRESS PORT - 2809

      props.put(javax.naming.Context.PROVIDER_URL,

            "iiop://<HOST_NAME>:< BOOTSTRAP_ADDRESS PORT>");

      InitialContext ctx = new InitialContext(props);

     

     

      EJBProcessFlowRunMgrBeanRemote bean =null;

      lobj =  ctx.lookup("123456");

      if(lobj instanceof EJBProcessFlowRunMgrBeanRemote)

      {

         bean = (EJBProcessFlowRunMgrBeanRemote)lobj;

      }     

      // Invoke the Method using bean  object ;

bean.methodinvocation();

      System.out.println("EJB run successful");

  

Note –

1.  Invoking ejb from application deployed on WAS installed in VM might cause issues (if installed node is VM and hostname is something different).

2.  We get following exception if the stubs are not in classpath of the standalone java client and try to cast as shown below –

Cast (removed the instanceof in the earlier code) -    

 bean = (EJBProcessFlowRunMgrBeanRemote)lobj;

Exception -

java.lang.ClassCastException: org.omg.stub.java.rmi._Remote_Stub incompatible with adv.ejb.EJBProcessFlowRunMgrBeanRemote

      at adv.ejb.client.ProcessFlowrunMgrClient.runTest(ProcessFlowrunMgrClient.java:39)

Resolution -

Make sure the generated EJB stubs are present in the classpath.