Applet cant instantiate JNDI initial context
When I use an applet to get an initial context, error is reported as cant find
class javax.naming.InitialContext
Here is a snippet of all the code
-----------applet code -----------
<APPLET code="JNDIApplet.class" width=350 height=200>
<param name="java.naming.factory.initial" value="weblogic.jndi.WLInitialContextFactory">
<param name=java.naming.provider.url value="t3://svr_weblogic:7001/">
</APPLET>
----------------error------------------
This is the error i am getting in the init() of applet:
java.lang.ClassNotFoundException: javax.naming.InitialContext
---------------java code --------------
public void init () {
initComponents();
Context ctx = null;
try {
Hashtable env = new Hashtable();
env.put(Context.APPLET, this);
System.out.println("here before instantiation");
ctx = new InitialContext(env);
System.out.println("here after instantiation");
System.out.println("Initial context created");
textField1.setText("Initial context created");
}catch (Exception e) {
textField1.setText(e.toString());
I guess, Applet needs javax.naming package in the classpath.
thanks,
Argyn
"John M" <[email protected]> wrote in message
news:3b079a74$[email protected]..
>
When I use an applet to get an initial context, error is reported as cantfind
class javax.naming.InitialContext
Similar Messages
-
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. -
App client can't instantiate the initial context factory
hi
i wrote an application client and a stateless session bean that i deployed with the deploytool from sun to the j2ee application server. now when i start my application client i get the following message:
NoInitialContextException: Cannot instantiate class: COM.sun.enterprise.naming.SerialInitContextFactory. Root exception is java.lang.ClassNotFoundException: COM.sun.enterprise.naming.SerialInitContextFactory
at java.net.URLClassLoader$1.run
my jndi.properties looks like this:
java.naming.factory.initial=COM.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=COM.sun.enterprise.naming
and my server runs on the same computer as the client. the classpath variable is set to the j2ee.jar file ( and this file contains the selected initial factory ). i could not understand why i get this errormessage. has anyone a idea?thanks to all
now i got it working. i'm using the orion application server and to get access from a remote computer ( outside the application server ) i have to set the environment properties in the following way:
Properties prop = new Properties();
prop.put(Context.INITIAL_CONTEXT_FACTORY,"com.evermind.server.rmi.RMIInitialContextFactory");
prop.put(Context.PROVIDER_URL,"ormi://localhost/TestBean02");
prop.put(Context.SECURITY_PRINCIPAL,"admin");
prop.put(Context.SECURITY_CREDENTIALS,"123");
InitialContext initial = new InitialContext(prop);
Object objref = initial.lookup("MyBeanel");
home = (TestBeanHome)PortableRemoteObject.narrow(objref, TestBeanHome.class);
this works, the client needs only the j2ee.jar and the orion.jar in the classpath. -
Hi!
I am using a jndi initial context object to lookup my ejbs in weblogic.
There are places, where I initialize the initial context differently. I was
wondering if it's ok to do that.
For example,
Scenario A:
InitialContext context = new InitialContext();
context.lookup("some bean");
Scenario B:
HashMap prop = new HashMap();
prop.set(contextFactory, ...);
prop.set(providerUrl, ...);
InitialContext context = new InitialContext();
context.lookup("some bean");
Should I foresee any kind of problems with Scenario A. Does weblogic know
what context factory and provider url to use if I don't mention it.
Thanks in advance,
VanIf you are creating InitialContext inside the container, you
do not need to specify any properties - it is container's responsibility
to set them up.
van saravanan <[email protected]> wrote:
Hi!
I am using a jndi initial context object to lookup my ejbs in weblogic.
There are places, where I initialize the initial context differently. I was
wondering if it's ok to do that.
For example,
Scenario A:
InitialContext context = new InitialContext();
context.lookup("some bean");
Scenario B:
HashMap prop = new HashMap();
prop.set(contextFactory, ...);
prop.set(providerUrl, ...);
InitialContext context = new InitialContext();
context.lookup("some bean");
Should I foresee any kind of problems with Scenario A. Does weblogic know
what context factory and provider url to use if I don't mention it.
Thanks in advance,
Van--
Dimitri -
JNDI obj not binding to initial context--10gRel 2 issue only,works in rel3
hi all,
The issue I am writing about is an issue only in OAS 10g release 2 (10.1.2.0.2) and not in release 3. I have an issue where in I am trying to bind a data source object to the initial context. This data source object reference is created dynamically and is not specified in any XML file (say like web.xml or server.xml). The business requirement driving this is that for each user we need to create a data source dynamically and attach it to the JNDI and then this JNDI name is passed on to Crystal Reports which will use this data source to retrieve its data from the DB. The code for creating the data source dynamically is as below,
private String setDataSource(String username, String password) throws NamingException {
String prefix = "jdbc";
InitialContext ic = new InitialContext();
// Construct BasicDataSource reference
Reference ref = new Reference("javax.sql.DataSource", CustomDataSourceFactory.class.getName(), null);
ref.add(new StringRefAddr("url", xxxxxx));
ref.add(new StringRefAddr("schema",xxxxx));
ref.add(new StringRefAddr("xxxxxx", xxxxx));
ref.add(new StringRefAddr("password", xxxxx));
try {
ic.listBindings(prefix);
} catch (NameNotFoundException exp) {
ic.createSubcontext(prefix);
String datasourceName = prefix + "/" + oneNumber;
ic.rebind(datasourceName, ref);
return datasourceName;
As you can see the reference to the data source is added dynamically. Now when I try to obtain this object by looking up the context for its JNDI name I get a object not found error. This is how I look up the object through my code,
private void testDataSource(String dsName){
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
try {
InitialContext ic = new InitialContext();
javax.sql.DataSource ds = (javax.sql.DataSource) ic.lookup(dsName);
conn = ds.getConnection();
stmt = conn.createStatement();
rs = stmt.executeQuery("select sysdate from dual");
String result = rs.getString(1);
System.out.println("----YOGI----Result of query execution is AAA -----" + result);
} catch (Exception ex ){
System.out.println("----YOGI----the exception from this specific block is " + ex.getLocalizedMessage());
finally {
try {
if (null!= rs)
rs.close();
if(null !=stmt)
stmt.close();
if(null !=conn)
conn.close();
} catch (Exception ex){
System.out.println("Hopeless");
When I do this I get this exception message --> jdbc/1562 not found in MyAPP
jdbc/1562 is the data source JNDI name I generated in the first method and "MyAPP" is the name of my application. I decided to make the JNDI globally available in the context and hence I used "java:global/jdbc/1562" for my datasource name and even that did not work even though the JNDI name is not bound to the application in specific.
I am really at a loss here as this is a simple add/retrieve operation to a object bound to the context. Can someone tell what is wrong here? The same code works fine in release 3 OAS and also in tomcat and websphere. Any help will be appreciated.
Regards,
YogiOK, I seem to be getting a new exception, not sure if I did any change but ran into this exception in the logs,
11/08/24 18:45:08 ----YOGI----the exception from this specific block is javax.naming.Reference cannot be cast to javax.sql.DataSource*
From what I read on the web, this is prevalent in glassfish and jboss. The reason could be that missing j2ee.jar in classpath or duplicate jdbc jars. I added j2ee.jar to my application library in oc4j dint resolve the issue. I removed jdbc jar from the OAS lib folder and restarted, it dint help.
Any other clues, anyone? -
Error in JMS receiver adapter: "Error creating initial context with environment"
Hello,
I have some trouble with a JMS receiver adapter (access to JMS-provider with JNDI).
The message in adapter monitoring is:
A channel error occurred. Detailed error (if any) :
com.sap.aii.adapter.jms.api.connector.ConnectorException: Fatal Error looking up connection factoryJMSQueueConnectionFactory, for profile: ConnectionProfile of channel: CC_JMS_RCV_XLIMI00001on node: 503473150 having object id: 5b424f2f79b6350ca636ab35d528cfdd:
ConnectorException: Error creating initial context with environment: java.naming.provider.url=wcsefdev.example.com:9064; java.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory; for profile: ConnectionProfile of channel:
CC_JMS_RCV_XLIMI00001on node: 503473150 having object id: 5b424f2f79b6350ca636ab35d528cfdd: javax.naming.NoInitialContextException:
Cannot instantiate class: com.ibm.websphere.naming.WsnInitialContextFactory<br> at com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl.createConnectionFactory
(JndiConnectorImpl.java:152)<br> ....
Message processing failed. Cause:
com.sap.aii.adapter.jms.core.fsm.DFA$InvalidTransitionException: No transition found from state: ERROR, on event: process_commence for DFA: CC_JMS_RCV_XLIMI00001:5b424f2f79b6350ca636ab35d528cfdd
The third party assured me that the specified JNDI parameters are right and everything is configured on their site, so it should work...
Might there be a problem with the JMS drivers?
Regards,
MarcusHi Marcus,
Have a look at below thread
Connecting to PI 7.11 JMS Queue from other PI 7.11 Server -
Error in getting Initial Context
Hello,
I am facing the following exception while trying to get the Initial Context. Following
is the snippet of code that I use for getting the Context -
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");p.
put(Context.PROVIDER_URL, url);
if (user != null) {
p.put(Context.SECURITY_PRINCIPAL, user);
if (password == null)
password = "";
p.put(Context.SECURITY_CREDENTIALS, password);
return new InitialContext(p);
The following is the exception that I encounter -
javax.naming.AuthenticationException. Root exception is java.lang.SecurityException:
attempting to add an object which is not an instance of java.security.Principal
to a Subject's Principal Set
Am i missing anything. Thanks for your time.
See the attached file for the details of the exception
Thanks,
Ashutosh
[trace.txt]Hi Tim,
If you are running within a browser, you will not have access to anything
outside the sandbox which includes making RMI calls. Try signing the applet.
You can find more information on signing applets on the sun java website.
Regards
Arjuna
"Tim" <[email protected]> wrote in message
news:3c5ab818$[email protected]..
>
I get the following eror when I try to get the Initial Context in anapplet:
>
java.lang.ExceptionInInitializerError: java.security.Acc
ess denied (java.util.PropertyPermission * read,write)
atjava.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:272)
atjava.security.AccessController.checkPermission(AccessController.java:
399)
Does anyone have any idea what would cause this? The code works finerunning
from an application. From what I understand there might be a problem withmy
policy file. However, it seems to look ok. Any ideas? -
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:16Hi,
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 -
Hi,
I've gotten the following exceptions reported to us by our production clients when trying to connect to our Weblogic 4.5.1 server (sp8).
CPClient with url: t3s://www.cpmarket.com:7002 Getting guest initial
context
[Root exception is java.io.IOException: Bootstrap unable to get a t3s
connection to
www.cpmarket.com/159.43.253.15]javax.naming.CommunicationException at
weblogic.jndi.toolkit.ExceptionTranslator.toNamingException(ExceptionTransla
tor.java:32) at
weblogic.jndi.WLInitialContextFactory.toNamingException(WLInitialContextFact
ory.java:513) at
weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFact
ory.java, Compiled Code) at
weblogic.jndi.Environment.getContext(Environment.java:128) at
weblogic.jndi.Environment.getInitialContext(Environment.java:111) at
com.xxxxxxx.CPClient.getGuestInitialContext(CPClient.jav
a:184) at
com.xxxxxxx.CPClient.<init>(CPClient.java:47)
Does anyone know where this could be coming from?
Thanks,
Gary Mui
[email protected]
[att1.html]Hi Tim,
If you are running within a browser, you will not have access to anything
outside the sandbox which includes making RMI calls. Try signing the applet.
You can find more information on signing applets on the sun java website.
Regards
Arjuna
"Tim" <[email protected]> wrote in message
news:3c5ab818$[email protected]..
>
I get the following eror when I try to get the Initial Context in anapplet:
>
java.lang.ExceptionInInitializerError: java.security.Acc
ess denied (java.util.PropertyPermission * read,write)
atjava.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:272)
atjava.security.AccessController.checkPermission(AccessController.java:
399)
Does anyone have any idea what would cause this? The code works finerunning
from an application. From what I understand there might be a problem withmy
policy file. However, it seems to look ok. Any ideas? -
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. -
Reusing the Initial Context Object
Hi all
Environment: Weblogic 452
JNDI implementation of Weblogic 452 is based on Javasoft JNDI 1.1 and
SPI specifications.(refer: Developer docs for 452).Javadoc of
InitialContext for JNDI 1.1 says (refer -
http://java.sun.com/products/jndi/javadoc/index.html)
An InitialContext instance is not synchronized against concurrent access
by multiple threads. Multiple threads each manipulating their own
InitialContext
instances need not synchronize. Threads that need to access a single
InitialContext instance concurrently should synchronize amongst
themselves
and provide the necessary locking
1. Does reusing the InitialContext object accross threads for lookup and
then execution of remote methods cause any problems? or should we
synchronize access?
How weblogic 452 handles this.
2. Let say i do this
a. get InitialContext
b. do lookup
c. get remote reference
d. close context
e. execute methods on the remote reference got in step c.
does doing d ie..closing context cause problems in step e or later
on....
3. What happens if we dont close the intial context...
Does WLS 452 intelligently garbage collect them and release any
resources held internally by the initial context object?
How much is the overhead?
Is Initial Context heavy ie.. holds resources like sockets/etc...?
thanks in advanceI do not have an exact answer for most of your questions. From my
experience and from research, I would suggest that the following is safe:
Within an HTTP request, instantiate an InitialContext and using it for the
duration of the request only (i.e. same auth info, same thread). I believe
the same holds true for home interfaces. That is within the "web
container", though. The choice of "caching" the context in the "ejb
container" is a even easier for threads (ejb guarantee -- only one thread
with access to your ejb at a time), but harder due to lack of clear spec on
auth issues.
Cameron Purdy, LiveWater
"S Rajesh" <[email protected]> wrote in message
news:[email protected]...
Hi all
Environment: Weblogic 452
JNDI implementation of Weblogic 452 is based on Javasoft JNDI 1.1 and
SPI specifications.(refer: Developer docs for 452).Javadoc of
InitialContext for JNDI 1.1 says (refer -
http://java.sun.com/products/jndi/javadoc/index.html)
An InitialContext instance is not synchronized against concurrent access
by multiple threads. Multiple threads each manipulating their own
InitialContext
instances need not synchronize. Threads that need to access a single
InitialContext instance concurrently should synchronize amongst
themselves
and provide the necessary locking
1. Does reusing the InitialContext object accross threads for lookup and
then execution of remote methods cause any problems? or should we
synchronize access?
How weblogic 452 handles this.
2. Let say i do this
a. get InitialContext
b. do lookup
c. get remote reference
d. close context
e. execute methods on the remote reference got in step c.
does doing d ie..closing context cause problems in step e or later
on....
3. What happens if we dont close the intial context...
Does WLS 452 intelligently garbage collect them and release any
resources held internally by the initial context object?
How much is the overhead?
Is Initial Context heavy ie.. holds resources like sockets/etc...?
thanks in advance -
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 ? -
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 -
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
EdWhy 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 -
Error creating initial context with environment
Hi,
Currently we are working on a scenarios, where we need to integrate XI and webmethods using JMS.
It was working fine. But recently they have restarted the webmethods server. After that we re getting an error message like,
In Adapter Monitoring:
Channel error occurred; detailed error description: com.sap.aii.adapter.jms.api.connector.ConnectorException: Error creating initial context with environment: {java.naming.provider.url=server:port, java.naming.factory.initial=com.sap.engine.services.jndi.InitialContextFactoryImpl, java.naming.security.principal=XYZ, java.naming.security.credentials=ABC}for profile: ConnectionProfile of channel: CC_RCV_JMS_INon node: 3010950 having object id: ABCXYZ: NamingException: Error getting the server-side naming service functionality during getInitialContext operation.
at com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl.createInitialContext(JndiConnectorImpl.java:66)
In RWB
MP: Exception caught with cause com.sap.aii.af.ra.ms.api.RecoverableException: No transition found from state: STARTING, on event: process_commence for DFA: C_RCV_JMS_IN:e4413a5265a436459e271d5e0dd4859b
Can one please tell me what the problem is?
Thanks in advance.
Regards,
Prasad Babu.Hi,
Check this link looks like same problem
Re: file to JMS(for MQ series)
Thanks
Vikranth
Maybe you are looking for
-
upgrade says firefox is open when it isn't, preventing me from overwriting/replacing older version/icon
-
Download error -228 when using new Vizio router
Download error -228 using new Vizio router when trying to update plugins. It says I need to install them but when I hit install i get the error -228.
-
V_V2 Rescheduling Sequence Issue
V_V2 Rescheduling is not working properly for sort order sometimes. I set sort order by default - Document category > Delivery Priority > Date (Sort item by date of creation) > Document Number and Document item. And excute V_V2 as daily batch job. An
-
Virtual Machine installs on wrong server
I have install OVM OVS: Server1 -- Oracle VM Manager Server2 -- Oracle Virtual Server -- Server Pool Master, Utility Server Server3 -- Oracle Virtual Server -- Virtual Machine Server When I create my Virtual Machine (using Oracle VM Manager), it crea
-
How can I change the colours for read/unread emails on a Samsung S6?
The only difference between the colours for read and unread emails on a Samsung S6 is a very pale grey versus white background. Is it possible to change these colours, or font colours, so that the difference between the read and unread emails is mor