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.
Similar Messages
-
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. -
Questions on InitialContext and replica-aware stub caching
Hi All,
We have a cluster and deployed with some stateless ejb session beans. Currently we only cached the InitialContext object in the client code, and I have several questions:
1. in the current case, if we call lookup() to get a replica-aware stub, which server will return the stub object, the same server we get the InitialContext, or it will load balanced to other servers every time we call the lookup method?
2. should we just cache the stub? is it thread safe? if it is, how does the stub handle concurrent requests from the client threads? in parallels or in sequence?
One more question, when we call new InitialContext(), it will take a long time before it can return a timeout exception if the servers are not reachable, how can we set a timeout for this case?809364 wrote:
You can set the timeout value programatically by using the
weblogic.jndi.Environment.setRequestTimeout()
Refer: http://docs.oracle.com/cd/E12839_01/apirefs.1111/e13941/weblogic/jndi/Environment.html
or
set the REQUEST_TIMEOUT in the weblogic.jndi.WLContext
Refer: http://docs.oracle.com/cd/E11035_01/wls100/javadocs/weblogic/jndi/WLContext.html
Hi, I tried setting the parameters before, but it only works for stub lookup and ejb call timeout, not for the creation of InitialContext. And any idea for my 2nd question? -
InitialContext and javax.rmi.PortableRemoteObject
I've been trying to locate a very annoying problem that I get when I try to bind remote objects in JNDI. I have now located the problem but I have no idea why this causes a problem or how to fix it. It seems that creating an InitialContext has different effects depending whether I create an instance of javax.rmi.PortableRemoteObject before.
Here's what I am doing...
1:Context ctx = new InitialContext(); //Create Initial context
2://Instantiate remote object (extends PortableRemoteObject and stubs gen with rmic with -iiop flag)
3:Hello hello = new HelloImpl();
4:ctx.rebind("hello", hello); //Bind to JNDI
5:System.out.println("Object bound!!!!!");
This code works fine. The problem occurs when I try to instantiate the remote object before creating the InitialContext for the first time (I.e. I move line 3 to the top) I then get the following exception:
2007-aug-13 09:32:26 com.sun.corba.ee.impl.util.Utility autoConnect
VARNING: "IOP00511403: (INV_OBJREF) Class rmi.HelloImpl not exported, or else is actually a JRMP stub"
org.omg.CORBA.INV_OBJREF: vmcid: SUN minor code: 1403 completed: No
at com.sun.corba.ee.impl.logging.UtilSystemException.objectNotExported(UtilSystemException.java:569)
at com.sun.corba.ee.impl.logging.UtilSystemException.objectNotExported(UtilSystemException.java:592)
at com.sun.corba.ee.impl.util.Utility.autoConnect(Utility.java:147)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAny(Util.java:323)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.write(DynamicMethodMarshallerImpl.java:256)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.writeArguments(DynamicMethodMarshallerImpl.java:407)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:157)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:119)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:197)
at com.sun.enterprise.naming._SerialContextProvider_DynamicStub.rebind(_SerialContextProvider_DynamicStub.java)
at com.sun.enterprise.naming.SerialContext.rebind(SerialContext.java:403)
at javax.naming.InitialContext.rebind(Unknown Source)
at parlayxws.usecases.ejb.px_spec_v2_1.RunEjb.main(RunEjb.java:43)
Exception in thread "main" javax.naming.CommunicationException: java.rmi.NoSuchObjectException: CORBA INV_OBJREF 1398080891 No; nested exception is:
org.omg.CORBA.INV_OBJREF: vmcid: SUN minor code: 1403 completed: No
at com.sun.enterprise.naming.SerialContext.rebind(SerialContext.java:405)
at javax.naming.InitialContext.rebind(Unknown Source)
at parlayxws.usecases.ejb.px_spec_v2_1.RunEjb.main(RunEjb.java:43)
I assume the problem is in the javax.rmi.PortableRemoteObject's (HelloImpl's) constructor since that is the only code that's beeing executed. But how could that effect the instantiation of the InitialContext? I should also say that it seems that it is only the first time that an InitialContext is created that is critical. If I create on instance of it before instantiating the first PortableRemoteObject, all subsequently created instances of InitialContext succeed in binding remote (RMI-IIOP) objects.
Can someone help me understand why this happens and how to avoid it? I don't want to have to create an InitialContext the first thing I do in the code. It seems the PortableRemoteObject constructor somehow changes the configuration in a way that makes the bindings fail... How? Why? Can I prevent it from happening?
Any input appreciated!
Kristofermy bean is running in my EJBServer, and I have it in the classpath of the RmiRegistry (which runs as part of my server). The RmiRegistry is an actual ".bat" file that starts an RMI Registry (I assume).
The client is not a bean and is run like this:
java com.titan.cabin.Client_1
All it does is create a cabin and then read it back. It works, it not only gets the context, but also creates, persists and reads that cabin bean.
Is it because java automatically finds all RmiRegistries running on the computer? This makes sense, but I read on java.sun.com that you need a stub class for your clients. And if it is true, then how does it get the context and remote/home interface of a bean on another server? -
Context ctx = new InitialContext();
URL program= (URL)ctx.lookup("url/program");
Where does the ctx.lookup search for the "url/program"?
--My guessing would be from a system file such as abc.xml. If this is correct, I have questions about it:
For IBM RAD, it may setup its system file as resource.xml, while for Oracle JDeveloper, it may set up as application.xml, etc. Now how does the ctx.lookup know where to look up the system file? (I mean, this system file can be different for each IDE manufacturer).
If my understanding is wrong, what should be the right explanation?
Thanks
ScottThe javadoc of Context and InitialContext explains quite well these things.
-
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. -
How to get the server port and id from the Initialcontext
hi
i know that i can get the server port and id where the jndi service is listening from the InitialContext ( when i create InitialContext ic = new InitialContext(); from within a EJB. ). Does this work on any application server and where (at what position is for example the port) in the Enumeration at the ic are the different things put?I would usually just get the PROVIDER_URL property from the InitialContext and use that to determine the location of the naming service:
String providerURL = (String)ic.getEnvironment().get(Context.PROVIDER_URL);You'll then need to parse that string to obtain the port and the server name. For example:
// Assume that the provider URL is of form "protocol://server:port"
int serverStartIndex = providerURL.indexOf("://" + 3);
int serverEndIndex = providerURL.indexOf(:, serverStartIndex);
String server = providerURL.substring(serverStartIndex, serverEndIndex);
String port = providerURL.substring(serverEndIndex + 1);It's a fairly universal approach but there'll doubtlessly be some special cases (for example, the provider URL could be null and the InitialContextFactory class defaults it).
You might have to adjust the server/port parsing stuff a bit as I just made that up and your URL might not conform to the pattern I described.
Hope this helps. -
InitialContext from server-side applications
Just a question to see if what I am doing is correct.
According to this link:
http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_design.html#1031811
if you are an internal client of an ejb you should use
Context ctx = new InitialContext();
instead of having to specify all the parameters like
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, url);
h.put(Context.SECURITY_PRINCIPAL, user);
h.put(Context.SECURITY_CREDENTIALS, password);
Context ctx = new InitialContext(h);
I am trying to connect to a connection pool from within an ejb. This
ejb is running in the weblogic server and the connection pool is in the
same server and is restricted to use by a special account that we
setup. If I just get the context by calling new InitialContext() and
then get the dataSource through this context, I won't have access rights
to the connection pool. So what I did was to provide everything but the
provider_url to get the context. Example:
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.SECURITY_PRINCIPAL, user);
h.put(Context.SECURITY_CREDENTIALS, password);
Context ctx = new InitialContext(h);
This way I provide everything but the URL to the weblogic server. The
reason I do this is because we have multiple weblogic servers and since
we don't want it to tied to only one server, I leave out the url and
assume that the InitialContext() will be gotten from the local server,
basically whichever server it is running on. It seems to work fine
right now. My concern is if the way I am explaining things is correct
and if what I am doing sounds logical.
Any input on this would be appreciated.If you do not specify the properties, it defaults to the user guest. This
is a simplification that is useful if you have users logging in through
servlets/JSP.
Thanks,
Michael
Michael Girdley
BEA Systems Inc
"Senthil Kumar S" <[email protected]> wrote in message
news:[email protected]...
There is no restriction that u should not populate properties to get
initialContext.
U are doing the right way.
bhavin patel wrote:
Just a question to see if what I am doing is correct.
According to this link:
http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_design.html#1031811
if you are an internal client of an ejb you should use
Context ctx = new InitialContext();
instead of having to specify all the parameters like
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, url);
h.put(Context.SECURITY_PRINCIPAL, user);
h.put(Context.SECURITY_CREDENTIALS, password);
Context ctx = new InitialContext(h);
I am trying to connect to a connection pool from within an ejb. This
ejb is running in the weblogic server and the connection pool is in the
same server and is restricted to use by a special account that we
setup. If I just get the context by calling new InitialContext() and
then get the dataSource through this context, I won't have access rights
to the connection pool. So what I did was to provide everything but the
provider_url to get the context. Example:
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.SECURITY_PRINCIPAL, user);
h.put(Context.SECURITY_CREDENTIALS, password);
Context ctx = new InitialContext(h);
This way I provide everything but the URL to the weblogic server. The
reason I do this is because we have multiple weblogic servers and since
we don't want it to tied to only one server, I leave out the url and
assume that the InitialContext() will be gotten from the local server,
basically whichever server it is running on. It seems to work fine
right now. My concern is if the way I am explaining things is correct
and if what I am doing sounds logical.
Any input on this would be appreciated. -
Under a stress test load over around 100 users we seem to be able to hang
the WLS 5.1 SP6 server after only a few minutes. A thread dump shows all
execute threads waiting on the initialContext method, where we are
attempting to contact the JNDI service on another WLS 5.1 SP6 server.
Reducing the code down to a simple JSP doing nothing more than constructing
the initialContext and then closing it shows the same problem!
JDK : Sun 1_3_0
Anybody seem this or have any idea? Also have tried using a cached context
but then the problem seems to move to the EJB lookup or business method
invoke. Most strange but rather a show stopper for the scale we are looking
for from the application.Will try to get a copy but I'm off site right now and don't have a copy to
hand. Of the execute threads all had stalled on Object.wait() with the chain
starting from either an initialContext() construction or lookup() method.
Reading around the JNDI Context I get the feeling (a) the service is
syncronised (b) should be called sparingly. In the case we are working with
the Provider_URL is another host.
Rob Woollen <[email protected]> wrote in message
news:[email protected]..
Can you post the thread dump?
-- Rob
Tony Symons wrote:
Under a stress test load over around 100 users we seem to be able to
hang
the WLS 5.1 SP6 server after only a few minutes. A thread dump shows all
execute threads waiting on the initialContext method, where we are
attempting to contact the JNDI service on another WLS 5.1 SP6 server.
Reducing the code down to a simple JSP doing nothing more thanconstructing
the initialContext and then closing it shows the same problem!
JDK : Sun 1_3_0
Anybody seem this or have any idea? Also have tried using a cachedcontext
but then the problem seems to move to the EJB lookup or business method
invoke. Most strange but rather a show stopper for the scale we arelooking
for from the application.--
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com -
InitialContext: How, exactly, does a server application create one
I'd appreciate somebody clarifying as to how exactly does a server application (specifically,
weblogic) get the default InitialContext(). One can write a new application and "drop"
it into an already running instance of weblogic server. This application should be
able to get the right InitialContext by using the IntialContext(). Is the PROVIDER_URL
set in the JVM by whatever class starts the application going, or does it use "localhost"
and default port - in which case what if there are more than one servers running
on a machine?
Thanksnew InitialContext() gets initial context factory class name from the
Context.INITIAL_CONTEXT_FACTORY System property (which is set by WebLogic to
'weblogic.jndi.WLInitialContextFactory' when it starts) and PROVIDER_URL is null,
which I guess for WebLogic implementation means local JVM.
You can take a look at the javax.naming.InitialContext JavaDoc to see where it gets
it's parameters from:
http://java.sun.com/j2se/1.4/docs/api/javax/naming/InitialContext.html
Satish Gupta <[email protected]> wrote:
I'd appreciate somebody clarifying as to how exactly does a server application (specifically,
weblogic) get the default InitialContext(). One can write a new application and "drop"
it into an already running instance of weblogic server. This application should be
able to get the right InitialContext by using the IntialContext(). Is the PROVIDER_URL
set in the JVM by whatever class starts the application going, or does it use "localhost"
and default port - in which case what if there are more than one servers running
on a machine?
Thanks--
Dimitri -
Security & Servlet engine and ejb container on different servers
When you have the servlet container and the ejb container on different physical servers,
how is the rmi connection meant to to be done while still maintaining the seucrity
propagation from servlet to ejb tier?
Assume that my user is already authenticated (forms) on the servlet tier. Do we then
create a dedicated connection (InitialContext + url/username/password properties)
to the ejb tier and store this connection in the HttpSession? (basically authenticating
a 2nd time)
OR,
can the servlet container make a generic connection to the ejb container, and pass
the users security context to the ejb tier transparantly?
-Sam
Nick Minutello <[email protected]> wrote:
> Assuming that web container security is being employed, I guess the fundamental question
> is: Is it necessary to create a "connection" (ie. an InitialConext) per user, or
> can a "global" initial context be shared (in the end, the TCP connection is shared
> anyway)?
It doesn't create a 'connection' per user - when you use JNDI authentication (specifying
principal and credentials when constructing InitialContext) it associates security info
with the current thread for the duration of the request. If you cache InitialContext and
use it later on some other thread it will not do anything.
> Does it really matter?
No ;-)
> Thanks,
> Nick
> "Dimitri I. Rakitine" <[email protected]> wrote:
>>Nick Minutello <[email protected]> wrote:
>>
>>
>>> OK, so when I create the InitialContext, I just specify the URL (to call
>>the remote
>>> EJB container). The user ID and credentials are mapped automatically.
>>
>>> I obviously also need to cache the initialContext variable in my HTTPSession
>>object?
>>
>>> What would happen if I had one InitialContext for the whole servlet engine
>>- and
>>> each thread used that. Would the thread (security) context still get passed
>>- or
>>> would the credentials for the original connection get used?
>>
>>If you use web-app security, container will associate security info with
>>the current
>>thread before invoking your servlet. If you do not use it and cache InitialContext,
>>
>>then the current user will always be 'guest' (except for the very first
>>time when
>>application calls 'new InitialContext()' with username/password.
>>
>>
>>> Thankyou.
>>> -Sam
>>
>>
>>> "Vinod Mehra" <[email protected]> wrote:
>>>>
>>>>"Sam the bad cat" <[email protected]> wrote in message
>>>>news:[email protected]...
>>>>>
>>>>>
>>>>> When you have the servlet container and the ejb container on different
>>>>physical servers,
>>>>> how is the rmi connection meant to to be done while still maintaining
>>>>the
>>>>seucrity
>>>>> propagation from servlet to ejb tier?
>>>>>
>>>>> Assume that my user is already authenticated (forms) on the servlet
>>tier.
>>>>Do we then
>>>>> create a dedicated connection (InitialContext + url/username/password
>>>>properties)
>>>>> to the ejb tier and store this connection in the HttpSession? (basically
>>>>authenticating
>>>>> a 2nd time)
>>>>>
>>>>> OR,
>>>>> can the servlet container make a generic connection to the ejb container,
>>>>and pass
>>>>> the users security context to the ejb tier transparantly?
>>>>
>>>>If the user has logged in already, ie the authenticated user is already
>>>>in
>>>>the execute
>>>>thread, the identity should be propgated to the ejb tier transparantly,
>>>>when
>>>>you create the
>>>>new initial context.
>>>>
>>>>--Vinod.
>>>>
>>>>
>>>>>
>>>>> -Sam
>>>>>
>>>>>
>>>>
>>>>
>>
>>--
>>Dimitri
>>
Dimitri
-
I have application worked in cluster. Is some possibility to propagate change in static object to all application in cluster.
You can use application context (javax.naming.InitialContext) and bind (set), rebind (set new value), lookup (get) and unbind (remove) variables (must be serializable).
You must corect configure RMI replication.
Changes ist propagated acros all nodes in cluster. (but unbind don't work correct - it work only locale (bug?)) -
I have concerning InitialContext and number of instances of this class.
We have an application that uses a singleton InitialContext to obtain references to
UserTransaction, DataSources of two databases and some ejbs.
Could the fact that the InitialContext is singleton cause some kind of error, multithreading or performance problem or similar?
Thanks JaroHi,
There should be no issues if you implement it properly.
Always remember that in Java singletons are singletons per ClassLoader, and whenever you redeploy an app, a new ClassLoader is created. So, if you build an application that is redeploy-friendly, you have to handle the lifecycle of the application and release everything that the singleton has. If you fail to do this, you will end up with some leaks.
Regards,
-lg -
I am using the Security features provided by WLS 8.1 on a Windows NT box. My resources in the container are secured in that they need the Context.PRINCIPAL and Context.CREDENTIALS set when I try to get InitialContext. I have to do a remote call to get the InitialContext cos the Authenticator is a LDAP authenticator and it involves a network hop. This takes arnd 100 ms for me to get an "AUTHENTICATED" InitialContext. If I do this everytime I need to access a resource (EJB, JDBC Connection from the pool), it's slowing down my application severely. So, I decided to cache the InitialContext and pass around the cached "AUTHENTICATED" InitialContext whenever I need to access a resource. This obviously speeds up my application cos I don't try to authenticate everytime. How does this affect my application in a clustered environment with fail-over? Say for example, the first time I cache the InitialContext, WLS handed me a context from instance A. Now, if instance A goes down, my cached InitialContext is stale. If I try to look up any resources using it, I would not be able to. Is there any way Weblogic announces the fact that it is able to give me a fresh InitialContext? I hope someone gets what I am talking about or has faced similar situation. Let me know. Any help is highly appreciated.
Thanks,
-Shree IyerIn a cluster environment when the node is down, When lookup fails with an exception , can you not reget/refresh the initialContext ?
When a node in a cluster fails, the lookup call on the initial context you obtained and cached will go to a different node so the failover should be transparent for you. Make sure the cluster has homogeneous deployments. Either case it good to have a safegaurd and retry the initialcontext when all else fails.
hth
sree -
Multi-Thread us of a InitialContext
Hello all,
I am sure everyone is aware that the retrieval of a InitialContext can be
quite expensive. 3-5 secs in my current environment. So, is it possible to
share an InitialContext among multiple threads.
Thanks ahead of time
R.D.Dion,
It does work for me. I have an application context (singleton) that keeps
all sorts of references including Home for EJB, JMS handles, etc.
Initialization is done on a statrtup.
Daniel Ilkanayev
[email protected]
Dion Almaer <[email protected]> wrote in message
news:8dvifg$a3$[email protected]..
Would this be a good idea:
A singleton class called InitialContextCache (or something).
you call: InitialContextCache.getInitialContext() which uses theenvironment
or properties in a properties file to get the vars that it needs (insteadof
having them in code).
The Singleton will cache initial contexts that come back and look forthose
first. So you could have a Hashtable that has as it's key the variousunique
values for a initialcontext, and the
initial context itself as the value.
Does this make sense? It seems like it will a) do caching of contexts, and
b) make it so you don't have to write a getInitialContext() in each bean
that puts things into a hashtable/properties object etc etc.
Dion
"Rob Woollen" <[email protected]> wrote in message
news:[email protected]..
"R.D. Cole" wrote:
Hello all,
I am sure everyone is aware that the retrieval of a InitialContext can
be
quite expensive. 3-5 secs in my current environment. So, is it
possible
to
share an InitialContext among multiple threads.Yes.
-- Rob
Thanks ahead of time
R.D.
Maybe you are looking for
-
Help making a paint program in Flash
So, all this basically does so far is create a few colored squares on the stage and let me draw in black. I'm trying to get it to let me trace() some incremental value onRelease of the different colors but I can't seem to get it to work. Can someone
-
Reg:connection b/w the j2ee to BOE
HI, please help me how to connect j2ee to business objects enterprice,kindly provide some sample code. Thanks & Regards, Mala
-
I've been trying to find one, but I can't. Regular docking stations for iPods don't work. Any advice?
-
When syncing my iphone all of the pictures on my computer are saved onto the phone as "Camera Albums" . As they are taking up too much space I want to delete them from the phone but don't see how to do this. Also, how do I prevent the pictures from
-
Is there a way to recover my pictures on Iphoto?
I went to look at my pictures on I photo and they were all gone. Is there an old backup ?