Initial context and PROVIDER_URL default

I´d like a short way to put into the initial context the correct provider.
Default value of PROVIDER_URL is "t3://localhost:7001", but this is tied to a specific port (I run two instances of Weblogic in a development environment).
How can I detect on wich port is running my instance of weblogic server in order to put the provider value in an independent way.
Thanks,

I am fairly new to JBoss as well, so I may be of limited help here. Although JBoss can use a jndi.properties file (as you are using) I have not experimented with this appraoch as of yet ...I supply a Hashtable filled with the appropriate properties.
i.e.
    java.util.Hashtable props = new java.util.Hashtable();
     props.put(
      Context.INITIAL_CONTEXT_FACTORY,
    props.put(
      Context.PROVIDER_URL,
    props.put(
      Context.URL_PKG_PREFIXES,
    Context ctx = null;
    try {
       ctx = new InitialContext(props);
    } catch (NamingException ne) {
      System.out.println("Failed to create JNDI context from EJB server.");
      System.out.println(ne.toString(true));
    }However, I am starting to think this might not be the problem. I was reading the JBoss newsgroup yesterday and there are some jars from the JBoss "client" folder that need to be included in the classpath when running your client, but I sent the doc I created home (I could verify for you later if we can'y figure it out here from memory). You need two for sure, one being $JBOSS_HOME/client/log4j.jar and the other being (something like) $JBOSS_HOME/client/clientall-jboss.jar
If you experiment with what you find in the client folder in the JBoss install dir, you will likely find the jars you need in the classpath by process of elimination.
Hope this helps, sorry all my references are at home at the moment.
GumB.

Similar Messages

  • Security stack and caching initial context

    We are using weblogic60 sp2, when we using Optimizeit tool to profile weblogic
    server and we found build up initial context is very expensive, can we cache the
    initial context? Is it thread safe? I know there is a issue related with security
    stack, to work around this, could we just do this, cache the initial context,
    and before call any remote method, we just push a valid user to the stakc of current
    thread, could this scheme work?
    Thanks

    We are using weblogic60 sp2, when we using Optimizeit tool to profile weblogic
    server and we found build up initial context is very expensive, can we cache the
    initial context? Is it thread safe? I know there is a issue related with security
    stack, to work around this, could we just do this, cache the initial context,
    and before call any remote method, we just push a valid user to the stakc of current
    thread, could this scheme work?
    Thanks

  • Initial Context Lookup

    hi
    i have written a jms message sender and receiver.
    i am using j2ee server to provide the jms service.
    no how do i get the initial context.
    i am not able to get the initial context and it is giving
    NoInitialContextException
    could anyone help me out.
    thanks and regards,
    rajesh.

    Hi, When you create InitialContext, context's environment should be in the system properties or you can pass it to the constructor. Those properties vary J2EE server to server.
    For example, if you are using Weblogic it goes like this
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.PROVIDER_URL, "t3://localhost:7001");
    Context intialContext = new InitialContext(env);

  • How to configure initial-context-factory and provider_url on Websphere MQ

    I have a few questions about WebSphere MQ. Currently, my application is able work well with other JMS provider. But I would like to move to use WebSphere instead.
    Can anyone suggest me how to configure the application connecting WebSphere?
    �     I�m using the Initial java naming factory as bellows: com.sun.jndi.fscontext.RefFSContextFactoryIs it the correct class?
    �     About the java-naming-factory-url, How do I know what object that I should use? I found this example in JMSAdmin.config � iiop://localhost:7555� What�s iiop ?
    �     What jar file that I should add in my classpath?

    Hi,
    You have a few options...
    1. Use WebSphere Application Server as the JNDI provider
    2. Don't use JNDI
    3. Use the File System Context as the JNDI provider
    Exploring these options in a bit more detail...
    1. Use WebSphere Application Server as the JNDI provider
    Assuming you have WAS, the best way of obtaining your queue is to define the Queue and Queue Connection Factory objects in WAS using the admin console, then obtain them from the Initial Context as per the following article
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rnam_example_prop2.html
    If you prefer not to do JNDI lookups in your code a great alternative is to use Spring (www.springframework.org). If you haven't come across spring before it's well worth a look. One of it's many features is a bean factory for creating your objects. There is lots of support for retrieving JMS objects from JNDI, so in the main all you have to do is write some XML similar to the following...
    <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
           <property name="environment">
                  <props>
                         <prop key="java.naming.factory.initial">${jndi.initialContextFactory}</prop>
                         <prop key="java.naming.provider.url">${jndi.providerUrl}</prop>
                  </props>
           </property>
    </bean>
    <bean id="queueConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
           <property name="jndiTemplate" ref="jndiTemplate"/>
           <property name="jndiName" value="${jndi.queueConnectionFactory}"/>
    </bean>
    <bean id="queueName" class="org.springframework.jndi.JndiObjectFactoryBean">
           <property name="jndiTemplate" ref="jndiTemplate"/>
           <property name="jndiName" value="${jndi.queueName}"/>
    </bean>There's a bit more to it than this, but not much. I've been meaning to write a tutorial on this for a while so if you're interested let me know.
    2. Don't use JNDI
    This approach involves using the creating the native MQ Queue Connection Factory and Queue classes. You can hard code this, but it's much better to abstract it from your application. Again you can use Spring. The definition would look something like the following...
    <bean id="MQJMS_TP_CLIENT_MQ_TCPIP"
    class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean">
           <property name="staticField">
                  <value>com.ibm.mq.jms.JMSC.MQJMS_TP_CLIENT_MQ_TCPIP</value>
           </property>
    </bean>
    <bean id="queueConnectionFactory" class="com.ibm.mq.jms.MQQueueConnectionFactory">
           <property name="transportType" ref="MQJMS_TP_CLIENT_MQ_TCPIP" />
           <property name="queueManager" value="${mq.queueManager}" />
           <property name="hostName" value="${mq.host}" />
           <property name="port" value="${mq.port}" />
           <property name="channel" value="${mq.channel}" />
    </bean>
    <bean id="publishInvoiceQ" class="com.ibm.mq.jms.MQQueue">
           <constructor-arg value="${mq.queueName}" />
    </bean>
    3. Use the File System Context
    The file system context is just like a JNDI context, but instead of using a url like iiop://host:port you have to specify a file system url. Because FSContext is just another JNDI context you can still use the spring configuration from option 1, but just change the relevant parameters.
    In order to define you queues and queue connection factory using the File System Context, you need to download a swing application called JMS Admin. Get it here
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24004691&loc=en_US&cs=utf-8&lang=en
    With regards your specific questions...
    IIOP is just another communication protocol. If you want more details I'm sure typing "what is iiop" into google will provide plenty of hits.
    I'll do my best to answer the remain two tomorrow - I wrote an application a few months ago which used the File System Context, but don't have the details to hand.

  • Creating initial context from a java client

    I have tried to create intial context from a java client.....
    but that gives me the following exception:
    My code:TestClient.java
    import java.util.*;
    import javax.naming.*;
    public class TestClient
    public static void main(String nilesh[]) throws NamingException
    Hashtable hash = new Hashtable();
    hash.put("Context.INITIAL_CONEXT_FACTORY","com.evermind.server.rmi.RMIInitialContextFactory");
    hash.put("Context.PROVIDER_URL","ormi://localhost:23791/symularity");
    hash.put("Context.SECURITY_PRINCIPAL","admin");
    hash.put("Context.SECURITY_CREDENTIALS","admin");
    Context ctx = new InitialContext(hash);
    System.out.println("Context: "+ctx);
    The output is:
    ERROR! Shared library ioser12 could not be found.
    Exception in thread "main" javax.naming.NamingException: Error accessing repository: Cannot con
    nect to ORB
    at com.sun.enterprise.naming.EJBCtx.<init>(EJBCtx.java:51)
    at com.sun.enterprise.naming.EJBInitialContextFactory.getInitialContext(EJBInitialConte
    xtFactory.java:62)
    at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
    at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
    at javax.naming.InitialContext.init(Unknown Source)
    at javax.naming.InitialContext.<init>(Unknown Source)
    at TestClient.main(TestClient.java:14)
    is anybody able to solve my problem....
    Thanks in advance..
    NileshG

    Nilesh,
    First of all make sure that the shared library error you are getting is fixed by including the library in your classpath. Secondly, where are you running the client from? The connection factory that you use varies depending on where you are connecting from:
    1. ApplicationClientContextFactory is used when looking up remote objects from standalone application clients. This uses refs and mappings in application-client.xml.
    2. RMInitialContextFactory is used when looking up remote objects between different containers.
    3. ApplicationInitalContextFactory is used when looking up remote objects in same application. This is the default initial context factory and this uses refs/mappings in web.xml and ejb-jar.xml.
    Rob Cole
    Oracle Hello Rob cole..
    thank u for ur reply...but actualy i dont know what is application-client.xml and where i can find that file in my j2ee folder...can u give me detail explanation about that...actually i have not created any application or not deployed also without deploying any application i have created that TestClient.java class so how it will relate with application-client.xml....so i have changed the lookup code with ApplicaitonClientContextFactory...but still the same error is coming......can u give me the full explanation or solution of my problem...
    Thanks & Regards
    NileshG...

  • How to get Initial context of Local Interface in weblogic 8.1

    I have developed a local entity bean but i wouldnt able to initial context of that bean
    CAN ANYBODY HELP ME
    bean deployment descriptor
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
    <!--
    ** This file was automatically generated by EJBGen 2.16
    ** Build: 20031001-1049
    -->
    <ejb-jar>
    <enterprise-beans>
    <entity>
    <ejb-name>CabinBean</ejb-name>
    <home>my.CabinRemoteHome</home>
    <remote>my.CabinRemote</remote>
    <ejb-class>my.CabinBean</ejb-class>
    <persistence-type>Container</persistence-type>
    <prim-key-class>java.lang.Integer</prim-key-class>
    <reentrant>True</reentrant>
    <cmp-version>2.x</cmp-version>
    <abstract-schema-name>CabinBean</abstract-schema-name>
    <cmp-field>
    <field-name>bedCount</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>deckLevel</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>id</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>name</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>shipId</field-name>
    </cmp-field>
    <primkey-field>id</primkey-field>
    <security-identity>
    <use-caller-identity/>
    </security-identity>
    </entity>
    <entity>
    <ejb-name>CabinLocal</ejb-name>
    <local-home>my.CabinLocalHome</local-home>
    <local>my.CabinLocalLocal</local>
    <ejb-class>my.CabinLocal</ejb-class>
    <persistence-type>Container</persistence-type>
    <prim-key-class>java.lang.Integer</prim-key-class>
    <reentrant>True</reentrant>
    <cmp-version>2.x</cmp-version>
    <abstract-schema-name>CabinLocal</abstract-schema-name>
    <cmp-field>
    <field-name>bedCount</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>deckLevel</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>id</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>name</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>shipId</field-name>
    </cmp-field>
    <primkey-field>id</primkey-field>
    <ejb-local-ref>
    <ejb-ref-name>LocalCabin</ejb-ref-name>
    <ejb-ref-type>Entity</ejb-ref-type>
    <local-home>CabinLocalHome</local-home>
    <local>CabinLocal</local>
    <ejb-link>LocalCabin</ejb-link>
    </ejb-local-ref>
    <security-identity>
    <use-caller-identity/>
    </security-identity>
    </entity>
    </enterprise-beans>
    <assembly-descriptor>
    <container-transaction>
    <method>
    <ejb-name>CabinLocal</ejb-name>
    <method-name>*</method-name>
    </method>
    <trans-attribute>Required</trans-attribute>
    </container-transaction>
    <container-transaction>
    <method>
    <ejb-name>CabinBean</ejb-name>
    <method-name>*</method-name>
    </method>
    <trans-attribute>Required</trans-attribute>
    </container-transaction>
    </assembly-descriptor>
    <ejb-client-jar>EjbClient</ejb-client-jar>
    </ejb-jar>
    ************************************** Client Code****************
    package com;
    import my.CabinBean;
    import my.CabinRemoteHome;
    import my.CabinRemote;
    import javax.naming.InitialContext;
    import javax.naming.Context;
    import javax.naming.NamingException;
    import java.rmi.RemoteException;
    import java.util.Properties;
    import javax.rmi.PortableRemoteObject;
    import weblogic.jndi.Environment;
    public class Test
        public static void main(String args[])
            try{
                 Context context = getInitialContext();
                          Object cab = context.lookup("CabinLocalHome");
                ///**********-- Exception is thrown at this point -******************
                System.out.println("============ done====");
                Context ct = getInitialContext();
                Object ref = ct.lookup("CabinHomeRemote");
                CabinRemoteHome home = (CabinRemoteHome)PortableRemoteObject.narrow(ref,CabinRemoteHome.class);
                //CabinRemote cab = home.create(new Integer(1));
                //cab.setName("Master Suite");
                //cab.setDeckLevel(new Integer(1));
                //cab.setShipId(new Integer(1));
                //cab.setBedCount(new Integer(1));
                Integer pk = new Integer(1);
                CabinRemote cab1 = home.findByPrimaryKey(pk);
                System.out.println("--->>>>>>>> "+cab1.getName());
                System.out.println("--->>>>>>>>  "+cab1.getShipId());
                System.out.println("--->>>>>>>>"+cab1.getBedCount());
                System.out.println("--->>>>>>>>"+cab1.getDeckLevel());
                System.out.println("---");  
          }catch(java.rmi.RemoteException e){e.printStackTrace();}
           catch(javax.naming.NamingException e){e.printStackTrace();}
           //catch(javax.ejb.CreateException e){e.printStackTrace();}
           catch(javax.ejb.FinderException e){e.printStackTrace();}
        public static Context getInitialContext() throws javax.naming.NamingException
           Properties p = new Properties();
           p.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
           p.put(Context.PROVIDER_URL,"t3://localhost:7001");
           return new javax.naming.InitialContext(p);
    } ************************************** Error ***********************
    javax.naming.LinkException: [Root exception is javax.naming.LinkException:  [Root exception is javax.naming.NameNotFoundException: remaining name: /app/ejb/myejb.jar#CabinLocal/local-home]; Link Remaining Name: 'null']; Link Remaining Name: 'java:app/ejb/myejb.jar#CabinLocal/local-home'
         at weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:108)
         at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:284)
         at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:244)
         at weblogic.jndi.internal.ServerNamingNode_813_WLStub.lookup(Unknown Source)
         at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:369)
         at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:357)
         at javax.naming.InitialContext.lookup(InitialContext.java:347)
         at com.Test.main(Test.java:27)
    Caused by: javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException: remaining name: /app/ejb/myejb.jar#CabinLocal/local-home]; Link Remaining Name: 'null'
         at weblogic.jndi.internal.WLNamingManager.getObjectInstance(WLNamingManager.java:98)
         at weblogic.jndi.internal.ServerNamingNode.resolveObject(ServerNamingNode.java:292)
         at weblogic.jndi.internal.BasicNamingNode.resolveObject(BasicNamingNode.java:771)
         at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:191)
         at weblogic.jndi.internal.RootNamingNode_WLSkel.invoke(Unknown Source)
         at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
         at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:108)
         at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
         at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
         at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
    Caused by: javax.naming.NameNotFoundException: remaining name: /app/ejb/myejb.jar#CabinLocal/local-home
         at weblogic.j2eeclient.SimpleContext.resolve(SimpleContext.java:35)
         at weblogic.j2eeclient.SimpleContext.resolve(SimpleContext.java:39)
         at weblogic.j2eeclient.SimpleContext.lookup(SimpleContext.java:57)
         at weblogic.j2eeclient.SimpleContext.lookup(SimpleContext.java:62)
         at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(ReadOnlyContextWrapper.java:45)
         at weblogic.jndi.internal.AbstractURLContext.lookup(AbstractURLContext.java:130)
         at javax.naming.InitialContext.lookup(InitialContext.java:347)
         at weblogic.jndi.internal.WLNamingManager.getObjectInstance(WLNamingManager.java:96)

    Hi,
    from what I gather, u have two jars
    1. EJBClient - this will have remote and home interfaces and will be used by the client
    2. myEJB - this iwll have all the classes - remote & home interfaces, the bean class and all the other classes required by the bean.
    Now, the question is, who is acting as the client of your EJB ? There are 3 possibilities
    1. A servlet
    2. Another EJB
    3. a simple java program.
    In the first 2 cases, you can go for Local Interfaces (more so in the second case than the first). The reason being that the the client and server will be in the same JVM. Thus, in the first case, if the Web container and the ejb container are in the same app server, EJBs can be local.
    However, in the third case, it is unlikey that you will have the client runnng and the same jvm as the server, because the server is using the jvm provided by weblogic.
    Thus, you cannot use local interfaces in this 3rd case. I have a feeling that this is what you are doing. If so, change the local interfaces to remote.
    See if this helps. Else, I will mail you some sample code. But I am afraid, sample code wont be of much help bcoz this seems to be a design problem.
    regards

  • Caching initial contexts

    I have read the posts about caching initial context lookups and have
    implemented the solution and seen some benefits.
    I am dealing with a third party application that I cannot change.
    When I put my InitialContextFactory in the architecture I also logged
    how many getInitialContext() calls were being made - I was absolutely
    shocked - often 4+ per user transaction. I suspect that the code gets
    one, does a call and dereferences all over the place.
    90% of InitialContexts had the same environment passed to the getIC()
    call so it struck me that what I should do is create a pool of IC, and
    in my factory just serve one from the pool.
    So, the question is, what is the best way of detecting when the IC has
    been dereferenced so I know I can serve it again from my pool?
    I presume this is a generic pool problem when you can't guarantee that
    your client's will be good citizens and call a close() method or
    similar.
    I've posted here as it is performance related; also, is there any
    reason why what I am doing is not a good idea?
    Can the client do something with the IC which means it is not suitable
    for use by another client? If so, can I detect this so I may discard?
    As always, many thanks in advance.
    Presuming I can get it to work I will post the code so that we can all
    share ;-)
    Cheers
    Ed

    Why don't you instrument your factory then to give out your own
    implementation of InitialContext that will in fact only wrap a "loaner"
    InitialContext every time a method is invoked on it and before returning
    the value to the caller will put the real InitialContext back to the
    pool to be reused by another one.
    Then your clients can do whatever they want with those ICs and still
    would not cause so big performance hits.
    It's just an idea that just came to mind and I haven't tested it so it
    might have flaws but it looks viable.
    --dejan
    Ed Barrett wrote:
    The application is a third-party product that cannot be changed.
    By introducing the factory you gave below (thanks!) we put the application
    back under the load test and saw minimal improvements (like 1% response
    time).
    I then instrumented the factory with a system.out on finalize and noticed
    that a factory instance is created for each call to getInitialContext() - is
    this the way that WLS/J2EE works? I would have hoped that factories were
    shared or something. What we did see is that for one user request a number
    (sometimes 5!) ICs were being created ;-( Obviously the lookup cache is a
    class instance and shared across the lot.
    So then I started to think about pre-creating ICs and haveing a pool for the
    default ones (environment specifies URL and no security details or the
    like). Trouble is how to implement such when you cannot change the client
    code to call a factory return method (such as returnToPool()).
    Any ideas would be appreciated
    "Dimitri I. Rakitine" <[email protected]> wrote in message
    news:[email protected]...
    I've ran into this problem while porting 5.1 application (JNDI lookups
    were
    super-cheap) to 6.1 (where they are not so cheap due to
    serialization/deserialization)
    and did this test to see if this indeed was the problem. As you saw I
    didn't bother to
    cache InitialContext's - I just cached JNDI lookups and that resulted in
    very significant
    performance improvements.
    Which application are you testing it with?
    Graham <[email protected]> wrote:
    Dimitri,
    We did this but did not see that much improvement over the default way -
    we
    are using 6.1 sp2.
    We put some messages in our factory and found that the client code often
    created over 4 ICs for one user click - aaggghhhh!! As I say we cannot
    change their code but if we could take the time to create an IC away
    from
    the online response we feel we would save some time.
    We also observed a new instance of the IC factory being created every
    time a
    new IC was created - is this what you would expect?
    I think this is what NamingManager.getInitialContext() is supposed to do.
    Cheers
    Ed
    "Dimitri I. Rakitine" <[email protected]> wrote in message
    news:[email protected]...
    Caching InitialContext's will probably not quite solve the problem,
    because lookup()'s are expensive (in 6.x), so, caching lookup results
    will result in performance improvements.
    If you cannot change the 3'rd party code and all it does is:
    ... DataSource ds = (DataSource)new InitialContext().lookup(".....");
    or similar, you can add caching by implementing your own InitialContext
    factory,
    for example: (extremely simplistic)
    Startup class :
    System.setProperty("java.naming.factory.initial",
    "myjndi.InitialContextFactory");
    where
    myjndi.InitialContextFactory is :
    public class InitialContextFactory implements
    javax.naming.spi.InitialContextFactory {
    public Context getInitialContext(Hashtable env) throws
    NamingException
    Context ctx = new
    weblogic.jndi.WLInitialContextFactory().getInitialContext(env);
    return
    (Context)Proxy.newProxyInstance(ctx.getClass().getClassLoader(),
    new Class[]
    { Context.class },
    new
    ContextHandler(ctx));
    and myjndi.ContextHandler is:
    public class ContextHandler implements InvocationHandler {
    Context ctx;
    static Hashtable cache = new Hashtable();
    public ContextHandler(Context ctx) {
    this.ctx = ctx;
    public Object invoke(Object proxy, Method method, Object[] args)
    throws Throwable {
    try {
    Object retVal;
    if("lookup".equals(method.getName()) && args[0] instanceof
    String) {
    retVal = cache.get(args[0]);
    if(retVal == null) {
    retVal = method.invoke(ctx, args);
    cache.put(args[0], retVal);
    } else {
    retVal = method.invoke(ctx, args);
    return retVal;
    } catch(InvocationTargetException oops) {
    throw oops.getTargetException();
    Ed <[email protected]> wrote:
    Adarsh,
    We agree it is a brilliant idea - now just to work out how to do it.
    As you cannot always guarantee to be able to change the client code
    you cannot use normal pooling techniques:
    getObjectFromPool()
    // do work
    returnObjectToPool()
    So, the client code needs an InitialContext. We can put in our own
    Factory and intercept the getInitialContext() calls. This method
    must
    return class javax.naming.Context - therefore the only way I can see
    to spot when the class is dereferenced is to extend the class and add
    a finalize() method that notifies the factory.
    The trouble I believe is that the class cannot be "rescued" in the
    finalize() method (i.e. "I'm dying - take me back" ;-). If it simply
    told the factory to add another one to its pool this would mean that
    the new IC create "hit" would be in garbage collection (i.e. the
    users
    will pay somewhere along the line) - is this correct?
    Anyone any ideas on a solution? I have discovered out code create
    HUNDREDS of contexts in an hour and discards them very quickly. Be
    nice to be able to cache them!
    Cheers
    Ed
    "Adarsh Dattani" <[email protected]> wrote in message
    news:<[email protected]>...
    Ed,
    This a brilliant idea. We are planning something similar too. We
    first
    want to create a pool of LDAP connections as apps make extensive
    calls
    to
    LDAP. Did you check-out the object pooling api at Jakarta Commons.
    It
    deserves a close look.
    http://jakarta.apache.org/commons/pool/index.html
    Thanks,
    Adarsh
    "Ed" <[email protected]> wrote in message
    news:[email protected]...
    I have read the posts about caching initial context lookups and
    have
    implemented the solution and seen some benefits.
    I am dealing with a third party application that I cannot change.
    When I put my InitialContextFactory in the architecture I also
    logged
    how many getInitialContext() calls were being made - I was
    absolutely
    shocked - often 4+ per user transaction. I suspect that the code
    gets
    one, does a call and dereferences all over the place.
    90% of InitialContexts had the same environment passed to the
    getIC()
    call so it struck me that what I should do is create a pool of IC,
    and
    in my factory just serve one from the pool.
    So, the question is, what is the best way of detecting when the IC
    has
    been dereferenced so I know I can serve it again from my pool?
    I presume this is a generic pool problem when you can't guarantee
    that
    your client's will be good citizens and call a close() method or
    similar.
    I've posted here as it is performance related; also, is there any
    reason why what I am doing is not a good idea?
    Can the client do something with the IC which means it is not
    suitable
    for use by another client? If so, can I detect this so I may
    discard?
    As always, many thanks in advance.
    Presuming I can get it to work I will post the code so that we can
    all
    share ;-)
    Cheers
    Ed
    Dimitri
    Dimitri

  • How OSB pass Initial Context parameters to EJB

    For security reasons I have to pass a ticket (through initial context) to legacy system from OSB for calling EJB, below is a code
    Hashtable env = new Hashtable(2);
    env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.PROVIDER_URL, connectionUrl);
    env.put(javax.naming.Context.SECURITY_PRINCIPAL, ticket);
    env.put(javax.naming.Context.SECURITY_CREDENTIALS, "");
    InitialContext ctx = new InitialContext(env);
    Object homeRef = ctx.lookup("com.cih.services.contact.interfaces.IContactServiceRemote");
    IContactServiceRemoteHome home = (IContactServiceRemoteHome) javax.rmi.PortableRemoteObject
    .narrow(homeRef, IContactServiceRemoteHome.class);
    IContactServiceRemote ejb = home.create();
    Please let me know how we can pass Initial context parameter from Business service or proxy service to legacy system.
    Thanks

    Hi Russ
    Yes, I've done this too. Basic SQL though will not allow the updating of a table inside a function, so we have to get clever. The trick is to use the PRAGMA AUTONOMOUS TRANSACTION command. Here's an example:
    FUNCTION UPDATE_MYTABLE(P_VALUE IN NUMBER)
    RETURN VARCHAR2 IS
    PRAGMA AUTONOMOUS_TRANSACTION;
    BEGIN
    UPDATE SCHEMA_OWNER.MY_TABLE SET MY_VALUE = P_VALUE;
    COMMIT;
    RETURN('Done');
    END UPDATE_TABLE;
    When the update has been completed the Discoverer worksheet will respond with 'Done'.
    Everyone: don't forget to grant EXECUTE on this function to all of the necessary users, including the EUL owner, and also don't forget to import the function using the Admin edition so that it is available for the users. You will also need to make sure that all necessary users have been granted the UPDATE privilege on the table.
    I hope this helps
    Regards
    Michael

  • Initial Context Problem

    I have developed local entity bean in weblogic 8.1
    but i wouldnt able to get the Initial Context of the Bean.
    It throws javax.naming.NoInitialContextException
    But in jndi tree it shows the bean..
    the problem is only for Local Bean
    Remote Beans are working fine

    G,
    One thing I would make sure of is that you are not deploying oc4j.jar file as part of you ear. Check the 'exploded' ear file under WEB-INF/lib to ensure that you do not have an oc4j.jar file under it.
    It usually happens that in your Jdev Project, if you had included the oc4j.jar library solely to compile, but when you generated the deployment profile it would by default include all the libraries that are part of the project. You can correct this by right clicking the deployment profile and editing its properties to exclude the libraries that you don't want to deploy.

  • ClassNotFoundException for initial-context-factory using foreign JMS p.

    Hi,
    I am currently working on migrating an application from weblogic 9 to weblogic 10 and I bumped into this issue while MDB connecting to JMS.
    [Loaded cz.jaksky.riskscenario.beans.RiskScenarioServiceLocalHome from file:/C:/SVN/app-WLS10-FRESH/app-deploy/servers/myserver/tmp/_WL_user/performance/nyubkw/point-interfaces.jar]
    <17-Sep-2012 11:01:27 o'clock CEST> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: PerformanceAsyncRequestBean is unable to connect to the JMS destination: wls.AsyncQueue. The Error was:
    javax.naming.NoInitialContextException: Cannot instantiate class: cz.jaksky.common.jms.JMSInitialContextFactory [Root exception is java.lang.ClassNotFoundException: cz.jaksky.common.jms.JMSInitialContextFactory]
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:657)
    at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
    at javax.naming.InitialContext.init(InitialContext.java:223)
    at javax.naming.InitialContext.<init>(InitialContext.java:197)
    at weblogic.deployment.jms.ForeignOpaqueReference.getReferent(ForeignOpaqueReference.java:182)
    at weblogic.jndi.internal.WLNamingManager.getObjectInstance(WLNamingManager.java:96)
    at weblogic.jndi.internal.ServerNamingNode.resolveObject(ServerNamingNode.java:377)
    at weblogic.jndi.internal.BasicNamingNode.resolveObject(BasicNamingNode.java:856)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:209)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
    at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:411)
    at javax.naming.InitialContext.lookup(InitialContext.java:392)
    at weblogic.jms.common.CDS$2.run(CDS.java:486)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.jms.common.CrossDomainSecurityManager.runAs(CrossDomainSecurityManager.java:131)
    at weblogic.jms.common.CDS.lookupDestination(CDS.java:480)
    at weblogic.jms.common.CDS.lookupDDAndCalloutListener(CDS.java:345)
    at weblogic.jms.common.CDS.access$100(CDS.java:41)
    at weblogic.jms.common.CDS$DDListenerRegistrationTimerListener.timerExpired(CDS.java:193)
    at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)
    Caused by: java.lang.ClassNotFoundException: cz.jaksky.common.jms.JMSInitialContextFactory
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:247)
    at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:46)
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:654)
    ... 23 more
    I am using foreign JMS provider with provided mapping. Config follows:
    ejb-jar.xml:
    <enterprise-beans>
              <message-driven>
                   <ejb-name>PortfolioRetrieverAsyncRequestBean</ejb-name>
                   <ejb-class>cz.jaksky.common.async.AsynchronousRequestMessageBean</ejb-class>
                   <transaction-type>Bean</transaction-type>
                   <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
                   <message-driven-destination>
                        <destination-type>javax.jms.Queue</destination-type>
                        <subscription-durability>Durable</subscription-durability>
                   </message-driven-destination>
                   <message-selector>
                        <![CDATA[ Service IN ('PortfolioRetriever')
                      AND MessageType = 'request'
                      AND BigBox = FALSE
                    ]]>
                   </message-selector>
              </message-driven>
         </enterprise-beans>
    weblogic-ejb-jar.xml:
    <weblogic-enterprise-bean>
              <ejb-name>PortfolioRetrieverAsyncRequestBean</ejb-name>
              <message-driven-descriptor>
                   <pool>
                        <max-beans-in-free-pool>64</max-beans-in-free-pool>
                        <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
                   </pool>
                   <destination-jndi-name>wls.AsyncQueue</destination-jndi-name>
                   <initial-context-factory>weblogic.jndi.WLInitialContextFactory</initial-context-factory>
                   <connection-factory-jndi-name>ServiceLocatorAsyncQueueFactory</connection-factory-jndi-name>
              </message-driven-descriptor>
              <dispatch-policy>PortfolioAsyncQueueWorkManager</dispatch-policy>
         </weblogic-enterprise-bean>
    jmsconfig-jms.xml
    <foreign-server name="TibjmsAsyncServer">
    <default-targeting-enabled>true</default-targeting-enabled>
    <foreign-destination name="AsyncQueue.LOCAL.prgdwm355410.7001">
    <local-jndi-name>wls.AsyncQueue</local-jndi-name>
    <remote-jndi-name>AsyncQueue.LOCAL.prgdwm355410.7001</remote-jndi-name>
    </foreign-destination>
    <foreign-connection-factory name="FTQueueConnectionFactory">
    <local-jndi-name>ServiceLocatorAsyncQueueFactory</local-jndi-name>
    <remote-jndi-name>FTQueueConnectionFactory</remote-jndi-name>
    </foreign-connection-factory>
    <initial-context-factory>cz.jaksky.common.jms.JMSInitialContextFactory</initial-context-factory>
    <connection-url>tcp://JUSD-FTPOIA.jaksky.com:22542,tcp://JUSD-FTPOB.jaksky.com:22543</connection-url>
    </foreign-server>
    Module containing this MDB is packed as an ear file with following structure:
    APP-INF/lib/modules.jar - contains AsynchronousRequestMessageBean class
    APP-INF/lib/interface.jar - contains JMSInitialContextFactory (class used for initial-context-factory)
    portfolio-async.jar
    META-INF/ejb-jar.xml content pasted above
    META-INF/webogic-ejb-jar.xml content pasted above
    Weblogic system classpath doesn't contain any application sepcific libraries.
    This set up was working for weblogic 9 without any problem. I am just wondering what the problem is whether I am faceing class loading issue or JMS configuration issue and how to resolve it.
    Edited by: user13047709 on 18-Sep-2012 07:15
    Edited by: user13047709 on 18-Sep-2012 07:16

    Hi,
    When working with a non-WebLogic JNDI provider (or a non-WebLogic JMS provider), the non-WebLogic client classes must be made available to the classloader of the calling application in WebLogic Server. This is usually accomplished by adding them to the system classpath.
    In your case, WebLogic is looking for a proprietary/foreign JNDI Context Factory class named "cz.jaksky.common.jms.JMSInitialContextFactory", which means you need to make sure that a jar/dir that contains the non-WebLogic class "JMSInitialContextFactory.class" is in the classpath.
    The configuration for this should be similar in WL9 and WL10. It could be that your classpath is already setup to reference the foreign class, but it refers to a directory/jar that you haven't setup yet on your WL10 host.
    HTH,
    Tom

  • Initial Context Properties

    Hi,
    I'm using RAD 6 and the embedded messaging server. I'm trying to configure the initial context. Can anyone tell me wht it needs to be configured as.
    try {
                env.put(Context.INITIAL_CONTEXT_FACTORY,"*******");
                env.put(Context.PROVIDER_URL, "****");*/
                ctx = new InitialContext();
                System.out.println("Set CONN FACTORY");
                queueConnectionFactory = (QueueConnectionFactory)PortableRemoteObject.narrow(ctx.lookup(connectionFactoryName),QueueConnectionFactory.class);
                System.out.println("SET CONNECTION");
                queueConnection = queueConnectionFactory.createQueueConnection();
                System.out.println("SET SESSION");
                queueSession = (QueueSession) queueConnection.createSession(false, QueueSession.AUTO_ACKNOWLEDGE);
                System.out.println("SET QUEUE");
                queue = (Queue)PortableRemoteObject.narrow(ctx.lookup(queueName), Queue.class);
                 queueSender = queueSession.createSender(queue);I'm getting the following error,
    javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
    And i aslo need it to work with MQ Series version 6.0, let me know the env properties for that also.
    regards,
    karthik

    env.put(Context.INITIAL_CONTEXT_FACTORY,"*******");
    env.put(Context.PROVIDER_URL, "****");*/
    ctx = new InitialContext();
    Modify the last line as:
    ctx = new InitialContext(env);That's what the error message is telling you. :-)

  • Getting initial context using a cluster address

    I am having trouble getting initial context using a cluster address. My cluster
    has two WL 8.1 servers at localhost:8001 and localhost:9001. I set the hashtable
    to get the initial context as follows:
    env.put(InitialContext.PROVIDER_URL, "t3://localhost:8001,t3://localhost:9001");
    This gives me the following exception:
    Could not create JNDI InitialContext: javax.naming.ConfigurationException
    [Root exception is java.net.MalformedURLException: port expected: t3://cammnbhati:8001,t3://cammnbhati:9001]
    Any idea whey this is not working? If I set only one of the addresses then there
    is no error. For example, the following works just fine:
    env.put(InitialContext.PROVIDER_URL, "t3://localhost:8001");
    Thanks.

    try t3://localhost:8001,localhost:9001 as url
    hth
    sree
    "Naresh Bhatia" <[email protected]> wrote in message
    news:4009cfdf$[email protected]..
    >
    I am having trouble getting initial context using a cluster address. Mycluster
    has two WL 8.1 servers at localhost:8001 and localhost:9001. I set thehashtable
    to get the initial context as follows:
    env.put(InitialContext.PROVIDER_URL,"t3://localhost:8001,t3://localhost:9001");
    >
    This gives me the following exception:
    Could not create JNDI InitialContext:javax.naming.ConfigurationException
    [Root exception is java.net.MalformedURLException: port expected:
    t3://cammnbhati:8001,t3://cammnbhati:9001
    Any idea whey this is not working? If I set only one of the addresses thenthere
    is no error. For example, the following works just fine:
    env.put(InitialContext.PROVIDER_URL, "t3://localhost:8001");
    Thanks.

  • InitialContext and PROVIDER_URL

    I'm creating an InitialContext in a server-side object, relying on the WebLogic Server
    to use the local naming service. This works as expected. However, once created,
    I would like to determine the URL and initial context factory for the local naming
    service. When the following code is executed:
    InitialContext myCtx = new InitialContext();
    ht = myCtx.getEnvironment();
    myContext = (String)ht.get(Context.INITIAL_CONTEXT_FACTORY);
    myServer = (String)ht.get(Context.PROVIDER_URL);
    if(myServer == null)
    myServer = (String)ht.get(weblogic.jndi.WLContext.PROVIDER_RJVM);
    ..the initial context factory is returned as expected from the environment hashtable,
    but both PROVIDER_URL and PROVIDER_RJVM are null. Is there any way to determine
    what the correct URL for the local naming service is? (Assuming that there is no
    guarantee that it is at localhost:7001)
    Thanks in advance,
    Mike

    I figured this out myself . A bug (6089084) was reported and closed as Not-A-Bug. Sun App server has a workaround on it. Instead of using InitialContext() with programmatically specified properties, specify the ejb-name/jndi-name binding in ejb descriptor file (with jndiname format : 'corbaname:iiop:<host>:<iiop port>#<Bean's JNDI name>'), create an InitialContext without any added properties, and use 'java:comp/env/<ejb-name>' for lookup.

  • Urgent : Unable to create VALID Initial Context

    Hello All,
    I am trying to learn JNDI and am using file system service provider which is provided by the sun
    I have created the setup directories, but it would not work if I set up those directories on the drive other than C.
    The following lines work for C drive :
    Hashtable env = new Hashtable(11);
    env.put(Context.INITIAL_CONTEXT_FACTORY,
    "com.sun.jndi.fscontext.RefFSContextFactory");
    env.put(Context.PROVIDER_URL,
    "file:/tmp/tutorial");
    try {
    // Create the initial context
    Context ctx = new InitialContext(env);
    // Get listing of context
    NamingEnumeration list = ctx.list("awt");
    // Go through each item in list
    while (list.hasMore()) {
    NameClassPair nc = (NameClassPair)list.next);
    System.out.println(nc);
    // Close the context when we're done
    ctx.close();
    } catch (NamingException e) {
    System.out.println("List failed: " + e);
    As you all might have guessed this is code from straight from JNDI tutorial. But How do I specify some directory on drives other than C.
    Please help : I tried the follwing
    env.put (Context.PROVIDER_URL,
    NAME);
    In place of NAME above I tried the following
    "file:///I:\tmp\tutorial"
    "I:\tmp\tutorial"
    and other silly combinations
    ****** awt is a directory under "I:\tmp\tutorial"

    I wish It would have been pretty ?
    But damn it, it doesn't work
    I gave something like this
    env.put(Context.PROVIDER_URL, "file:///I:/tmp/tutorial");
    and the error come like this
    Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/jndi/toolkit/chars/CharacterDecoder
    at com.sun.jndi.fscontext.RefFSContextFactory.createContext(RefFSContextFactory.java:42)
    at com.sun.jndi.fscontext.RefFSContextFactory.createContextAux(RefFSContextFactory.java:47)
    at com.sun.jndi.fscontext.FSContextFactory.getInitialContext(FSContextFactory.java:49)
    at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
    at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
    at javax.naming.InitialContext.init(Unknown Source)
    at javax.naming.InitialContext.<init>(Unknown Source)
    at List.main(List.java:53)
    If you have any idea whats happening, I would really appreciate

  • Concurrent access to initial context?

    Using WebLogic Server 6.0
    I wrote a simple stand alone Java client (see code below) that
    performs the following steps:
    1. Gets the Initial Context for the WLS JNDI
    2. Closes the initial context
    3. Goes into an indefinite loops (to keep the client alive)
    I start up one client and it performs steps 1, 2, and 3 and is
    sitting at step3.
    Then I start up another client. It hangs at step 1 until I kill
    the first client.
    It cannot obtain the initial context while the first client is
    running.
    I do not understand this behavior! Is this behavior correct?
    If so, could somebody
    explain why it works this way. The initial context is used to
    lookup our EJBs. If two
    clients cannot access the Initial Context at the same time, won't
    this be a major
    bottle neck when using EJBs?
    Please help!
    Here's is the code for the client....
    public static void main(String args[])
         try
         Context ctx = null;
         System.out.println("Before get context.");
         Hashtable env = new Hashtable();
         env.put(Context.INITIAL_CONTEXT_FACTORY,
              "weblogic.jndi.WLInitialContextFactory");
         env.put(Context.PROVIDER_URL,
              "t3://localhost:7001");
         ctx = new InitialContext(env);
         System.out.println("Initial context created.");
         ctx.close();
         System.out.println("Closed context.");
         // Hang
         while(true){}
         catch (Exception e)
         e.printStackTrace();

    Yes - it was the CPU problem. If I use Thread.sleep(...) it works fine.
    I had a feeling it was a mistake on my part. Thanks for the help.
    Robert Patrick <[email protected]> wrote:
    There is definitely something else going on here. Try adding a
    Thread.sleep(1000) inside your while loop to prevent the process from
    spinning and eating up all the CPU...
    MK Parini wrote:
    Using WebLogic Server 6.0
    I wrote a simple stand alone Java client (see code below) that
    performs the following steps:
    1. Gets the Initial Context for the WLS JNDI
    2. Closes the initial context
    3. Goes into an indefinite loops (to keep the client alive)
    I start up one client and it performs steps 1, 2, and 3 and is
    sitting at step3.
    Then I start up another client. It hangs at step 1 until I kill
    the first client.
    It cannot obtain the initial context while the first client is
    running.
    I do not understand this behavior! Is this behavior correct?
    If so, could somebody
    explain why it works this way. The initial context is used to
    lookup our EJBs. If two
    clients cannot access the Initial Context at the same time, won't
    this be a major
    bottle neck when using EJBs?
    Please help!
    Here's is the code for the client....
    public static void main(String args[])
    try
    Context ctx = null;
    System.out.println("Before get context.");
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY,
    "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.PROVIDER_URL,
    "t3://localhost:7001");
    ctx = new InitialContext(env);
    System.out.println("Initial context created.");
    ctx.close();
    System.out.println("Closed context.");
    // Hang
    while(true){}
    catch (Exception e)
    e.printStackTrace();

Maybe you are looking for