Help on Initial Context in Weblogic 10

Please see the following thread
Exception in Initial Context Weblogic 10
thx in adv.

Hy!
Your Code is right without webstart!
With webstart you must insert befor 'ctx = new InitialContext(ht)';
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
By,
Martin

Similar Messages

Can I get a weblogic Initial context without importing all weblogic classes ?

can I get a weblogic Initial context (with weblogic.jndi.WLInitialContextFactory)
without importing all weblogic classes ?

I ran my client through all its functions.
I then took the access.log file and parsed out a list of all the class
files that were downloaded and built a script to create my
weblogiclient.jar file.
Before running the client we had to:
With WL5.1 I think we had to unjar the weblogicaux.jar file into the
serverclasses directory so the client could load them all individually.
Make sure you clean up after you are done with this.
With WL 6 we did not have to do that.
The access.log file is the key to building your own client jar file.
We also require the use of the Java 1.3 plug-in by our clients (for
Applets) so we can do multiple Jar caching.
Tom
Dominique Jean-Prost wrote:
Hello tom
What do you mean by "use the Weblogic class loader" ?
Could you explain whath you exactly did to find all the classes you need ?
regards.
dom
<nospam@nospam> a écrit dans le message news: 3ABF3EC2.9010200@nospam...
You need the classes one way or another. BUT you do not have to
redistribute the whole Weblogic.jar file. Use the Weblogic class
loader then run your program. The weblogic access.log should have a
listing of all the classes you need to use and you can build your own
sub-jar. My experience is that this new jar is significantly smaller.
Ours is around 600K instead of 15MB.
Tom
Dimitri Rakitine wrote:
Yes, if, for example, you can network classload from WebLogic. Talking
to a WebLogic
server means WebLogic RMI (unless you use RMI/IIOP in which case youdont need any
WebLogic classes) which needs WebLogic-specific classes, so you clientapplication needs
to get them from somewhere - local classpath or remote WebLogic server.
David Dahan <[email protected]> wrote:
I mean without a classpath to all weblogic classes.
can I get a weblogic Initial context (with
weblogic.jndi.WLInitialContextFactory)
without importing all weblogic classes ?

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

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'>

<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

Weblogic 10 Initial context issue...?

Hi All,
Please provide a suggestion for the same.
InitialContext not getting loaded properly and the weblogic jars are also there in the cp
Re: Exception in Initial Context Weblogic 10
thx in Adv.

Hi RainaV,
This problem looks like a Weblogic library conflict in your runtime environment.
java.lang.NoSuchMethodError: weblogic.common.internal.VersionInfo.initialize(Z)V
at weblogic.kernel.Kernel.initialize(Kernel.java:88)
This means you have some possible mix of old and new Weblogic binaries loaded in your classpath. The Exception means that the compiled version of the Kernal class (loaded in your system classpath) is refering a different version of the class weblogic.common.internal.VersionInfo, with different initialize() method signature.
Please have a look at your full classpath and look any for duplicate and conflicted version of the weblogic.jar library.
Also, which version of weblogic client are you using? There is no such VersionInfo class in Weblogic 10.0.x. Please have a look at the MANIFEST file of the weblogic.jar you are using to confirm. You are likely trying to use an older client like Weblogic 9.x.
Regards
P-H
http://javaeesupportpatterns.blogspot.com/

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 Security Issue

Hi, I wonder if someone can help me with this one??
The problem we are experiencing is that we have a remote client that connects
to 2 completely independent Weblogic 6.1 instances, and it appears that, under
certain circumstances, that the initial contexts actually become "confused", so
as to create a situation both initial contexts have been initialized successfully,
and after a while it appears that a connection to server B is attempted with the
principal and credential values of server A, obviously causing account lockouts
seeing as the user account does not exist on server B.
I have established through testing that this condition can be avoided by either
setting InitialContext.SECURITY_AUTHENTICATION = "none" and by not providing InitialContext.SECURITY_PRINCIPAL
and InitialContext.SECURITY_CREDENTIALS values for both client connections, or
by setting InitialContext.SECURITY_AUTHENTICATION = "simple", supplying valid
InitialContext.SECURITY_PRINCIPAL and InitialContext.SECURITY_CREDENTIALS values
for each server, and by reinitializing the InitialContext object before each and
every remote lookup.
We have decided to implement a InitialContext.SECURITY_AUTHENTICATION = "none"
policy, allowing us not to reinitialize the InitialContext objects every single
time. Obviously, this is not the preferred way!
I would appreciate any light on this, as this is causing us huge headaches, not
to mention the fact that one of the connections become completely unusable and
therefore denies any service whatsoever from one of the servers
Thanks in advance!

Hi,
This should probably have to be handled with Cisco directly or through the company that got you the license.
To my understanding there is a possibility that the you would first install one license key and the other license might be upgrade from the previous license to the next limit of the licensed feature.
I have had several occasions where I have been provided with the wrong license and have had to contact Cisco/supplier again to get the correct licenses for my device.
While I was posting this reply I checked the Licensing document for the ASA models. It would seem to me that there is no 25 Security Content License for the ASAs. The closes are 20 SC license and 50 SC license
Check this document:
http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/intro_license.html#wp1230400
- Jouni

Initial Context prbm

hi everybody,
i am new to this forum. any body help me to solve the problem
i am trying to communicate statelessbean with console client thro' weblogic 8.1 server. but i got an error during initial context object creation time. that error is
Exception in thread "main" java.lang.NoClassDefFoundError: javax/security/auth/callback/CallbackHandler
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:131)
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 com.anand.StateLess.HelloTestClient.getContextInfo(HelloTestClient.java:61)
at com.anand.StateLess.HelloTestClient.main(HelloTestClient.java:104)
kindly give me a solution
thanx in advance
bye
regards
muruganandam

This is what I get when I started the agents, I am using weblogic8.1 . Are we missing any other jars in the classpath.
Exception in thread "main" java.lang.NoClassDefFoundError: javax/security/auth/callback/CallbackHandler
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:131)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:665)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246)
at javax.naming.InitialContext.init(InitialContext.java:222)
at javax.naming.InitialContext.<init>(InitialContext.java:198)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:83)
at com.yantra.interop.util.YIFMessageBrowser.getInitialDirContext(YIFMessageBrowser.java:212)
at com.yantra.interop.util.YIFMessageBrowser.init(YIFMessageBrowser.java:156)
at com.yantra.interop.util.YIFMessageBrowser.<init>(YIFMessageBrowser.java:85)
at com.yantra.ycp.agent.server.YCPAgentTrigger.queueHasMessages(YCPAgentTrigger.java:101)
at com.yantra.ycp.agent.server.YCPAgentTrigger.hasTrigger(YCPAgentTrigger.java:113)
at com.yantra.ycp.agent.server.YCPAgentTrigger.sendMessage(YCPAgentTrigger.java:74)
at com.yantra.ycp.agent.server.YCPAgentTrigger.main(YCPAgentTrigger.java:53)

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);

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();

Speeding Initial Context

Our applet is taking about 2minutes to get the initial context. Does anybody have any ideas for reducing this response time considerably? Any help will be much appreciated.
Enviroment:
We're running weblogic5.1 on the Solaris 2.6 box using JDK1.2.2.

I have exactly the same problem. We are experiencing a
getInitialContext() call taking between 30 and 60 seconds. The DNS is
fine - pinging the server machine responds instantaneously. I have seen
this problem reported before but have never seen a fix posted.
Here's our code:
static public Context getInitialContext(String
userName, String password, String providerURL) throws Exception
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, providerURL);
if (userName != null)
h.put(Context.SECURITY_PRINCIPAL, userName);
if (password == null)
password = "";
h.put(Context.SECURITY_CREDENTIALS, password);
return(new InitialContext(h));
Can the WebLogic people get involved please?
Thanks,
Ken Condal
Chief Technology Officer
Dovetail Systems
[email protected]
-----Original Message-----
From:      Scott Anderson [mailto:[email protected]]
Sent:     Friday, September 22, 2000 2:22 PM
Posted To:     performance
Conversation:     Speeding Initial Context
Subject:     Re: Speeding Initial Context
That sounds like it might be a DNS time-out issue. Make sure the client
can actually find the server by name.
Regards,
-scott
Gunjan wrote:
>
Our applet is taking about 2minutes to get the initial context. Doesanybody have any ideas for reducing this response time considerably?
Any help will be much appreciated.
>
Enviroment:
We're running weblogic5.1 on the Solaris 2.6 box using JDK1.2.2.

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.

JNDI initial context in listeners

I wonder why it is NOT possible in SunONE 7 to obtain an initial context in the contextDestroyed() method of a ServletContextListener or valueUnbound() method of a HttpSessionBindingListener. Maybe I can get an answer from a knowledgeable person in Sun AS7....

Hashtable props = new Hashtable();
props.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
ut(Context.PROVIDER_URL,
"t3://weblogic:7001");You need to provide the server hostname here,
.put(Context.SECURITY_PRINCIPAL, "fred");
props.put(Context.SECURITY_CREDENTIALS,
"seafood");
Context ctx = new InitialContext(props);
i am getting the error like main not found could
anyone tell me how to solve this problem.
i am using j2se5 and weblogic 8.1Could you post the exact error message? That would be helpful.

Authentication of Initial Context

When creating an initial context from a client does providing a username,password effect whether the initialContext is created (i.e it fails if enter invalid username,password) or only come into play when looking up beans and then invoking methods on them?
(Using weblogic application server it does prevent creation of initial context, but doesn't seem to with OC4J Devlopers Release)
example code ...
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
env.put(Context.PROVIDER_URL,"ormi://localhost:23791/symularity");
env.put(Context.SECURITY_PRINCIPAL, "testuser");
env.put(Context.SECURITY_CREDENTIALS,"123456");
Context initial = new InitialContext(env);

I faced the same problem. I raised it with oracle support but I could not get much help.
However, if your intention is establish your credentials, you can use RoleManager. Check documentation for com.evenmind.security.RoleManager.

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

Help on Initial Context in Weblogic 10

Similar Messages

Maybe you are looking for