Caching InitialContext
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 Iyer
In 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
Similar Messages
-
I seem to be unable to find a best practice for caching InitialContext objects.
I'm doing some profile on my current project to pinpoint hotspots for optimizations
and the creation of IC seems to be one of those areas.
Is it recommended to use a singleton approach to InitialContext?
How about an object pool?
Or an instance per object for internal reuse?
Will an IC object ever be invalidated (will I need to recreate the object under
certain circumstances?)
Any feedback is appreciated.
Thanks,
DougWhy not DataSources ?
"Doug Larson" <[email protected]> wrote in message
news:[email protected]..
>
I am caching the results (except the DataSources...), but I'd like toreuse the
InitialContext across calls so I dont need to call new InitialContext()for each
lookup.
Any advise?
"Dimitri I. Rakitine" <[email protected]> wrote:
Since the lookups are expensive (in 6.x and 7.0), I think that you'll
be
better off caching lookup results.
"Doug Larson" <[email protected]> wrote in message
news:[email protected]..
I seem to be unable to find a best practice for caching InitialContextobjects.
I'm doing some profile on my current project to pinpoint hotspots foroptimizations
and the creation of IC seems to be one of those areas.
Is it recommended to use a singleton approach to InitialContext?
How about an object pool?
Or an instance per object for internal reuse?
Will an IC object ever be invalidated (will I need to recreate theobject
under
certain circumstances?)
Any feedback is appreciated.
Thanks,
Doug--
Dimitri
Dimitri -
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 -
Who can give me a clear picture on getCalllerPrincipal in EJB
We keep on encountering some problems which are related with security issues. So
I hope can get a clear picture on how it is handled inside WebLogic.
Currently what we did is we create a common login function. Inside this function,
we declare a local InitialContext variable and initiate the variable by passing
in userid and password. After this program finished, the InitialContext object
will be removed by java garbage collection.
Our login function (JSP or Servlet) will trigger this common function to login
a particular user. Then the function will create other InitialContext object without
passing in any parameter. This InitialContext object will be cached in a class’
static variable. The rest of function will use this object to look EJBs. For getting
the best performance, we also cache the remote home interface for stateless Session
EJB and catch home interface for Entity EJB.
In one of our EJB function, we want to get current login user id. We use sessionContext.getCallerPrincipal()
to get current login user id from WebLogic Realm. This is working fine in our
in-house environment. But when we deploy our product into other project environment,
it doesn’t work. The error scenario is
User A login first, everything working fine. After that user A logout and User
B login using the same browser. Then the getCallerPrincipal always return UserA.
We try a lot of different way, but still cannot resolve this problem.
Is it because we cached InitialContext or EJB interface? I hope some body can
give me a clear picture on how the Web tier and EJB tier is linked by WebLogic;
Why EJB can share the same user principal with JSP or Servlet and never confuse
between other Web session.Yes, it's because you cache the InitialContext. You need to refresh the context with
the current user's principal+credentials on each HTTP request.
regards,
-Ade
"James Zhang" <[email protected]> wrote in message news:3d36975b$[email protected]..
>
We keep on encountering some problems which are related with security issues. So
I hope can get a clear picture on how it is handled inside WebLogic.
Currently what we did is we create a common login function. Inside this function,
we declare a local InitialContext variable and initiate the variable by passing
in userid and password. After this program finished, the InitialContext object
will be removed by java garbage collection.
Our login function (JSP or Servlet) will trigger this common function to login
a particular user. Then the function will create other InitialContext object without
passing in any parameter. This InitialContext object will be cached in a class'
static variable. The rest of function will use this object to look EJBs. For getting
the best performance, we also cache the remote home interface for stateless Session
EJB and catch home interface for Entity EJB.
In one of our EJB function, we want to get current login user id. We use sessionContext.getCallerPrincipal()
to get current login user id from WebLogic Realm. This is working fine in our
in-house environment. But when we deploy our product into other project environment,
it doesn't work. The error scenario is
User A login first, everything working fine. After that user A logout and User
B login using the same browser. Then the getCallerPrincipal always return UserA.
We try a lot of different way, but still cannot resolve this problem.
Is it because we cached InitialContext or EJB interface? I hope some body can
give me a clear picture on how the Web tier and EJB tier is linked by WebLogic;
Why EJB can share the same user principal with JSP or Servlet and never confuse
between other Web session. -
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
-
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? -
Due to the time it takes to get a remote InitialContext in client code, I was considering ways to cache the InitialContext in a static variable. The problem is that according to Java Context is not thread safe. Should I even bother trying to cache the InitialContext. Does NamingManager or some other facility take care of this for me?
Thanks,
BertYes, correct. In our frameworks, we have a configurable cache whose options
are (in the web tier) to cache the context on the request, session (i.e.
user) and application (i.e. global) level, as well as the obviously-bad "no
caching" setting. Request is good for non-thread-safe implementations,
session is good for the scenario you painted, and application is good for WL
if you are using default new InitCtx().
Peace,
Cameron Purdy
Tangosol Inc.
<< Tangosol Server: How Weblogic applications are customized >>
<< Download now from http://www.tangosol.com/download.jsp >>
"Paul taylor" <[email protected]> wrote in message
news:3b5ec5b8$[email protected]..
Yes,but if you create the context with a user & password (i.e a form of
principal) and that user is used within the bean you can run into problems
because if it is a stateless bean another use can pick up the same
reference.
"Cameron Purdy" <[email protected]> wrote in message
news:[email protected]..
Yes, you can cache it. WL's implementation is thread-safe etc.
Peace,
Cameron Purdy
Tangosol Inc.
<< Tangosol Server: How Weblogic applications are customized >>
<< Download now from http://www.tangosol.com/download.jsp >>
"Alexander Bunkenburg" <[email protected]> wrote in message
news:3b5d44d0$[email protected]..
new InitialContext() inside EJBs takes some time,
and occurs inside every method.
Can we save that time by caching the InitialContext object?
We could cache it once per instance of EJB,
or even once per application.
Is that advisable, or are there any problems with that? -
InitialContext caching previous lookups?
Weblogic 6.1 SP3
Currently, all of our beans lookup the homes of other beans they need in the ejbCreate
method. Our session beans lookup entity beans in their ejbCreate methods. Some
of these session beans use the same entity beans and I think it is inefficient
to have different session beans lookup the same entity beans multiple times.
I designed a simple Service Locator singleton in my server. Basically, in the
Session Bean's ejbCreate, the home is taken from the Service Locator's cache.
If the Service Locator doesn't have the home in cache, it creates it. Therefore,
if I have 10 session beans looking up the same entity bean, the bean will only
be looked up once instead of 10 times.
I did some timing tests and found that the optimization really didn't improve
the performance at all.
Therefore, I'm wondering if Weblogic is doing any caching of previously looked
up homes in their implementation of the InitialContext. Does anyone know if Weblogic
is doing this?
Thanks.
DanWhy not DataSources ?
"Doug Larson" <[email protected]> wrote in message
news:[email protected]..
>
I am caching the results (except the DataSources...), but I'd like toreuse the
InitialContext across calls so I dont need to call new InitialContext()for each
lookup.
Any advise?
"Dimitri I. Rakitine" <[email protected]> wrote:
Since the lookups are expensive (in 6.x and 7.0), I think that you'll
be
better off caching lookup results.
"Doug Larson" <[email protected]> wrote in message
news:[email protected]..
I seem to be unable to find a best practice for caching InitialContextobjects.
I'm doing some profile on my current project to pinpoint hotspots foroptimizations
and the creation of IC seems to be one of those areas.
Is it recommended to use a singleton approach to InitialContext?
How about an object pool?
Or an instance per object for internal reuse?
Will an IC object ever be invalidated (will I need to recreate theobject
under
certain circumstances?)
Any feedback is appreciated.
Thanks,
Doug--
Dimitri
Dimitri -
Ramifications of caching results of InitialContext(().lookup?
One of the thing we discovered during our early efforts to port a 5.1 app to
7.0 was that in 7.0 the JNDI lookups were simply taking FOREVER. It was
really horrible.
So, the question is, what are the ramifications of caching the results of
this:
Context ctx = new InitialContext();
SessionBeanHome = (SessionBeanHome) ctx.lookup("SessionBean")
We're guessing that this will fail horrible in a clustered environment, but
what about a stand alone environment?
Thanx!
Will Hartung
([email protected])Can you provide some statistics, how much time it used to take and how much
is it taking now etc.
In 70, We know that the first InitialContext() call will take some time, as
it needs to initialize kernel and generate the hot-codegened initial context
stub. But once you have this call done, next initialContext call should be
pretty fast.
If you want to avoid the hot-codegen cost of stub, use this work around.
From the browser, try
http://server:port/bea_wls_internal/classes/weblogic/jndi/internal/RootNamin
gNode_WLStub.class
Save this class in your client package. This may give some performance
benefit.
This needs that, your classpath servlet should be turned on. See docs for
more info on this.
But I don't recommend this. This may become an issue later and may generate
version incompatibilities, if you upgrade server and forgot to re-pack the
client etc. I am not sure though.
Hope this helps.
Cheers,
..maruthi
"Will Hartung" <[email protected]> wrote in message
news:3d6a8d58$[email protected]..
One of the thing we discovered during our early efforts to port a 5.1 appto
7.0 was that in 7.0 the JNDI lookups were simply taking FOREVER. It was
really horrible.
So, the question is, what are the ramifications of caching the results of
this:
Context ctx = new InitialContext();
SessionBeanHome = (SessionBeanHome) ctx.lookup("SessionBean")
We're guessing that this will fail horrible in a clustered environment,but
what about a stand alone environment?
Thanx!
Will Hartung
([email protected]) -
InitialContext caching to improve performance
Hi All
I was going tthrough the EJB best practices doc in http://www-106.ibm.com/developerworks/java/library/j-ejb0924.html
by Brett. He suggests caching the InitalContext object instances to boost performance.
However if I fo to the javadoc for Context - they clearly say that this :
"A Context instance is not guaranteed to be synchronized against concurrent access
by multiple threads. Threads that need to access a single Context instance concurrently
should synchronize amongst themselves and provide the necessary locking."
I am confused as to how caching will work if this is true!. OR is it that if the
only use of Context is to lookup objects and not to bind objects - then only I
can use caching? My application uses the Context objects to lookup other objects
(EJB/JMS) on the JNDI tree and not to bind objects - can I use the caching?
thanks
AnamitraCorrection - somehow I shifted from caching results of lookups
to transaction propagation. Surely, you can cache results of
UserTransaction lookups.
Slava
"Slava Imeshev" <[email protected]> wrote in message
news:[email protected]...
Hi Rob,
"Rob Woollen" <[email protected]> wrote in message
news:[email protected]...
No, you can cache UserTransaction. The problem is mostly in the naming.
UserTransaction should probably be called UserTransactionManager or
something like that. It represents the user's interface to the
transaction manager but not the actual transaction.It could be right for remote client TXs, I agree. Looks like I spend too
much
time on the server side recently :) Obviously, if the user tx is handledby
client
it can be "cached".
Though, it's not clear how much could be gained from "caching"
TXs in multi-threading environment considering all the expenses
and complexities connected with it.
In fact, all J2EE is about easing life of a developer by letting one
not to care about this multi-threading stuff. So I do join to Dimitri :)
Slava
I agree with Dimitri's advice in another response. Think pretty hard
about why you're using bean-managed transactions. There's very few good
reasons to do so.
-- Rob
Slava Imeshev wrote:
Hi Anamitra,
User transactions for stateless session beans must
start and end within one method. For message driven
beans user TXs must start and end within onMessage
method. Stateful session beans can begin user TX in
one client method call and finish it in another.
Effectively it means that you can't cache UserTransaction
in multiple threads.
Regards,
Slava Imeshev
"Anamitra" <[email protected]> wrote in message
news:[email protected]...
Can I cache the handle to the UserTransaction also? like I do this
once:
UserTransaction utx =(UserTransaction)cntx.lookup("javax.transaction.UserTransaction");
then use this "utx" handle to do start and end transactions in
multiple
>>>
threads?
Anamitra
"Dimitri I. Rakitine" <[email protected]> wrote:
Yes. Even better idea will be to cache results of JNDI lookups -
homes
etc.
Anamitra <[email protected]> wrote:
Hi All
I was going tthrough the EJB best practices doc in
http://www-106.ibm.com/developerworks/java/library/j-ejb0924.html
by Brett. He suggests caching the InitalContext object instances toboost performance.
However if I fo to the javadoc for Context - they clearly say thatthis :
"A Context instance is not guaranteed to be synchronized against
concurrent
access
by multiple threads. Threads that need to access a single Context
instance
concurrently
should synchronize amongst themselves and provide the necessary
locking."
I am confused as to how caching will work if this is true!. OR is itthat if the
only use of Context is to lookup objects and not to bind objects -then only I
can use caching? My application uses the Context objects to lookupother objects
(EJB/JMS) on the JNDI tree and not to bind objects - can I use thecaching?
thanks
Anamitra--
Dimitri -
hi ,
I am trying to clear wsdl cache from java , some errors are coming,
Please any one help me
this is my code
package bpeltest;
import com.oracle.bpel.client.BPELProcessId;
import java.util.Properties;
import com.oracle.bpel.client.IBPELDomainHandle;
import com.oracle.bpel.client.Locator;
import com.oracle.bpel.client.ServerException;
public class UnDeployBPELProcess {
public static void main(String[] args) throws ServerException {
UnDeployBPELProcess unDeployBPELProcess = new UnDeployBPELProcess();
//Properties with BPEL server connection information
Properties props = new Properties();
props.put("orabpel.platform", "ias_10g");
props.put("java.naming.factory.initial", "com.evermind.server.rmi.RMIInitialContextFactory");
props.put("java.naming.provider.url", "opmn:ormi://EC3-VEDARRA:6005:home");
props.put("java.naming.security.principal", "oc4jadmin");
props.put("java.naming.security.credentials", "oracle1");
props.put("dedicated.connection","true");
//Get a locator in default domain
Locator locator = new Locator("default","oracle1",props);
//Get a handle to the domain
IBPELDomainHandle iBPELDomainHandle = locator.lookupDomain();
iBPELDomainHandle.undeployProcess(new BPELProcessId("default","MyUndeployedBPELProcess"));
System.out.println("iBPELDomainHandle" + iBPELDomainHandle);
iBPELDomainHandle.clearWSDLCache();
compilation errors:
C:\jdevstudio10131\jdk\bin\javaw.exe -client -classpath C:\jdevstudio10131\jdev\mywork\javatest\BPELTest\classes;C:\product\10.1.3.1\OracleAS_1\bpel\lib\orabpel.jar;C:\product\10.1.3.1\OracleAS_1\bpel\lib\orabpel-common.jar;C:\product\10.1.3.1\OracleAS_1\j2ee\home\lib\oc4j-internal.jar;C:\product\10.1.3.1\OracleAS_1\opmn\lib\optic.jar;C:\jdevstudio10131\j2ee\home\lib\ejb.jar -Dhttp.proxyHost=157.204.22.4 -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=*.2o7.net|32.85.*|chipsndip|157.204.*|localhost|127.0.0.1|*.wlgore.com|EC3-VEDARRA|tigger -Dhttps.proxyHost=157.204.22.4 -Dhttps.proxyPort=8080 -Dhttps.nonProxyHosts=*.2o7.net|32.85.*|chipsndip|157.204.*|localhost|127.0.0.1|*.wlgore.com|EC3-VEDARRA|tigger bpeltest.UnDeployBPELProcess
Exception in thread "main" java.lang.Exception: Failed to create "ejb/collaxa/system/FinderBean" bean; exception reported is: "javax.naming.NameNotFoundException: ejb/collaxa/system/FinderBean not found
at com.evermind.server.rmi.RMIClientContext.lookup(RMIClientContext.java:52)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.oracle.bpel.client.util.BeanRegistry.lookupFinderBean(BeanRegistry.java:337)
at com.oracle.bpel.client.Locator.getFinder(Locator.java:920)
at com.oracle.bpel.client.Locator.lookupDomain(Locator.java:228)
at bpeltest.UnDeployBPELProcess.main(UnDeployBPELProcess.java:29)
at com.oracle.bpel.client.util.ExceptionUtils.handleServerException(ExceptionUtils.java:82)
at com.oracle.bpel.client.Locator.getFinder(Locator.java:926)
at com.oracle.bpel.client.Locator.lookupDomain(Locator.java:228)
at bpeltest.UnDeployBPELProcess.main(UnDeployBPELProcess.java:29)
Caused by: java.lang.Exception: Failed to create "ejb/collaxa/system/FinderBean" bean; exception reported is: "javax.naming.NameNotFoundException: ejb/collaxa/system/FinderBean not found
at com.evermind.server.rmi.RMIClientContext.lookup(RMIClientContext.java:52)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.oracle.bpel.client.util.BeanRegistry.lookupFinderBean(BeanRegistry.java:337)
at com.oracle.bpel.client.Locator.getFinder(Locator.java:920)
at com.oracle.bpel.client.Locator.lookupDomain(Locator.java:228)
at bpeltest.UnDeployBPELProcess.main(UnDeployBPELProcess.java:29)
at com.oracle.bpel.client.util.BeanRegistry.lookupFinderBean(BeanRegistry.java:351)
at com.oracle.bpel.client.Locator.getFinder(Locator.java:920)
... 2 more
Process exited with exit code 1.
and one more
where we find thiis value
"java.naming.factory.initial"= "com.evermind.server.rmi.RMIInitialContextFactory"
Regards
janardhanI think there is error with this line in code
props.put("java.naming.provider.url", "opmn:ormi://EC3-VEDARRA:6005:home");
Please see the post for details
http://oraclebpelindepth.blogspot.com/2008/08/bpel-context-properties-for-client-api.html
The value should be
props.put("java.naming.provider.url", "opmn:ormi://EC3-VEDARRA:6005:home/orabpel");
Every Little Helps
Kalidass Mookkaiah
http://oraclebpelindepth.blogspot.com/ -
Error in Toplink 10.1.3 cache coordination using Websphere JMS
I' am trying to setup Cache Coordination for Toplink 10.1.3 in Websphere 7 using Websphere's implementation of JMS. However I' am getting a NamingException
when I try to lookup the Topic and TopicFactory from the JNDI tree. Admin Security is enabled in the server but not application security. I' am able to lookup
the queues using InitialContext. Upgrading to Toplink 11 is not an option right now for us. Please help in finding out if anything is missing in my Toplink configuration.
<?xml version="1.0" encoding="UTF-8"?>
<toplink-sessions
version="10g Release 3 (10.1.3.0.0)"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<session xsi:type="server-session">
<name>default</name>
<remote-command>
<commands>
<cache-sync>true</cache-sync>
</commands>
<transport xsi:type="jms-topic-transport">
<topic-connection-factory-name>jms/jobtrax.TCF</topic-connection-factory-name>
<topic-name>jms/jobtrax.ToplinkTopic</topic-name>
<jndi-naming-service>
<url>corbaloc:rir:/NameServiceServerRoot</url>
<initial-context-factory-name>com.ibm.websphere.naming.WsnInitialContextFactory</initial-context-factory-name>
</jndi-naming-service>
</transport>
</remote-command>
<!--<event-listener-classes>
<event-listener-class>com.pstechnology.eaf.persistence.toplink.PostBeginTransactionListener</event-listener-class>
</event-listener-classes>
-->
<logging xsi:type="toplink-log">
<log-level>fine</log-level>
<logging-options>
<log-exception-stacktrace>true</log-exception-stacktrace>
<print-thread>true</print-thread>
<print-session>false</print-session>
<print-connection>false</print-connection>
<print-date>true</print-date>
</logging-options>
</logging>
<primary-project xsi:type="class">com.pstechnology.toplink.ToplinkProject</primary-project>
<login xsi:type="database-login">
<platform-class>com.pstechnology.eaf.persistence.toplink.Oracle10Platform</platform-class>
<external-connection-pooling>true</external-connection-pooling>
<external-transaction-controller>false</external-transaction-controller>
<sequencing>
<default-sequence xsi:type="native-sequence">
<name>Default</name>
</default-sequence>
</sequencing>
<datasource>jdbc/jobtrax_job_datasource</datasource>
<bind-all-parameters>true</bind-all-parameters>
</login>
</session>
</toplink-sessions>
[2/17/11 16:22:10:696 EST] 00000018 SystemOut O [TopLink Warning]:
2011.02.17 04:22:10.690--Thread(Thread[server.startup : 0,5,main])--Local
Exception Stack:
Exception [TOPLINK-22103] (Oracle TopLink - 10g Release 3 (10.1.3.0.0)
(Build 060118)): oracle.toplink.exceptions.RemoteCommandManagerException
Exception Description: Could not look up remote connection under name
jms/jobtrax.TCF with URL corbaloc:rir:/NameServiceServerRoot
Internal Exception: javax.naming.NamingException: Error during resolve
[Root exception is javax.naming.AuthenticationException: Login failed:
com.ibm.websphere.security.auth.WSLoginFailedException [Root exception is
com.ibm.websphere.security.auth.WSLoginFailedException]]
at
oracle.toplink.exceptions.RemoteCommandManagerException.errorLookingUpRemoteConnection
(RemoteCommandManagerException.java:75)
at
oracle.toplink.remotecommand.jms.JMSTopicTransportManager.getTopicConnectionFactory
(JMSTopicTransportManager.java:206)
at
oracle.toplink.remotecommand.jms.PstJMSTopicTransportManager.createJMSTopicRemoteConnection
(PstJMSTopicTransportManager.java:67)
at
oracle.toplink.remotecommand.jms.JMSTopicTransportManager.createLocalConnection
(JMSTopicTransportManager.java:106)
at
oracle.toplink.remotecommand.jms.JMSTopicDiscoveryManager.startDiscovery
(JMSTopicDiscoveryManager.java:44)
at oracle.toplink.remotecommand.RemoteCommandManager.initialize
(RemoteCommandManager.java:132)
at oracle.toplink.publicinterface.DatabaseSession.login
(DatabaseSession.java:517)
at oracle.toplink.tools.sessionmanagement.SessionManager.getSession
(SessionManager.java:379)
at
com.pstechnology.eaf.persistence.toplink.TopLinkRepository.getServerSession
(TopLinkRepository.java:163)
at
com.pstechnology.eaf.persistence.toplink.TopLinkRepository.getClientSession
(TopLinkRepository.java:198)
at
com.pstechnology.eaf.persistence.toplink.TopLinkRepository.getReadSession
(TopLinkRepository.java:216)
at com.pstechnology.eaf.persistence.toplink.TopLinkRepository.read
(TopLinkRepository.java:318)
at
com.pstechnology.repository.admin.ApplicationPropertyRepository.findApplicationPropertyByEnumId
(ApplicationPropertyRepository.java:70)
at
com.pstechnology.service.admin.AdministrationService.findApplicationPropertyValue
(AdministrationService.java:179)
at
com.pstechnology.scheduling.trigger.AbolishedTaskSimpleTrigger.getTimerRepeatIntervalValue
(AbolishedTaskSimpleTrigger.java:45)
at
com.pstechnology.scheduling.trigger.AbolishedTaskSimpleTrigger.afterPropertiesSet
(AbolishedTaskSimpleTrigger.java:30)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods
(AbstractAutowireCapableBeanFactory.java:1198)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean
(AbstractAutowireCapableBeanFactory.java:1167)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean
(AbstractAutowireCapableBeanFactory.java:427)
at org.springframework.beans.factory.support.AbstractBeanFactory
$1.getObject(AbstractBeanFactory.java:249)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton
(DefaultSingletonBeanRegistry.java:155)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:246)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:160)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons
(DefaultListableBeanFactory.java:291)
at
org.springframework.context.support.AbstractApplicationContext.refresh
(AbstractApplicationContext.java:352)
at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>
(ClassPathXmlApplicationContext.java:122)
at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>
(ClassPathXmlApplicationContext.java:66)
at com.pstechnology.service.SchedulingContext.initialize
(SchedulingContext.java:56)
at com.pstechnology.servlet.InitializationServlet.init
(InitializationServlet.java:52)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init
(ServletWrapper.java:358)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init
(ServletWrapperImpl.java:169)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize
(ServletWrapper.java:1809)
at
com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper
(WebExtensionProcessor.java:98)
at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings
(WebApp.java:678)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinally
(WebApp.java:429)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize
(WebAppImpl.java:304)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication
(WebGroupImpl.java:100)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication
(VirtualHostImpl.java:166)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp
(WSWebContainer.java:731)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication
(WSWebContainer.java:616)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install
(WebContainerImpl.java:376)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start
(WebContainerImpl.java:668)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start
(ApplicationMgrImpl.java:1122)
at
com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart
(DeployedApplicationImpl.java:1319)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start
(DeployedModuleImpl.java:609)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start
(DeployedApplicationImpl.java:944)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication
(ApplicationMgrImpl.java:725)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start
(ApplicationMgrImpl.java:2046)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start
(CompositionUnitMgrImpl.java:439)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start
(CompositionUnitImpl.java:123)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start
(CompositionUnitMgrImpl.java:382)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$300
(CompositionUnitMgrImpl.java:110)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl
$CUInitializer.run(CompositionUnitMgrImpl.java:949)
at com.ibm.wsspi.runtime.component.WsComponentImpl
$_AsynchInitializer.run(WsComponentImpl.java:349)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1563)
Internal Exception Stack:
javax.naming.NamingException: Error during resolve [Root exception is
javax.naming.AuthenticationException: Login failed:
com.ibm.websphere.security.auth.WSLoginFailedException [Root exception is
com.ibm.websphere.security.auth.WSLoginFailedException]]
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup
(CNContextImpl.java:1840)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup
(CNContextImpl.java:1749)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt
(CNContextImpl.java:1500)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookup
(CNContextImpl.java:637)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:165)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:179)
at javax.naming.InitialContext.lookup(InitialContext.java:455)
at
oracle.toplink.remotecommand.jms.JMSTopicTransportManager.getTopicConnectionFactory
(JMSTopicTransportManager.java:204)
at
oracle.toplink.remotecommand.jms.PstJMSTopicTransportManager.createJMSTopicRemoteConnection
(PstJMSTopicTransportManager.java:67)
at
oracle.toplink.remotecommand.jms.JMSTopicTransportManager.createLocalConnection
(JMSTopicTransportManager.java:106)
at
oracle.toplink.remotecommand.jms.JMSTopicDiscoveryManager.startDiscovery
(JMSTopicDiscoveryManager.java:44)
at oracle.toplink.remotecommand.RemoteCommandManager.initialize
(RemoteCommandManager.java:132)
at oracle.toplink.publicinterface.DatabaseSession.login
(DatabaseSession.java:517)
at oracle.toplink.tools.sessionmanagement.SessionManager.getSession
(SessionManager.java:379)
at
com.pstechnology.eaf.persistence.toplink.TopLinkRepository.getServerSession
(TopLinkRepository.java:163)
at
com.pstechnology.eaf.persistence.toplink.TopLinkRepository.getClientSession
(TopLinkRepository.java:198)
at
com.pstechnology.eaf.persistence.toplink.TopLinkRepository.getReadSession
(TopLinkRepository.java:216)
at com.pstechnology.eaf.persistence.toplink.TopLinkRepository.read
(TopLinkRepository.java:318)
at
com.pstechnology.repository.admin.ApplicationPropertyRepository.findApplicationPropertyByEnumId
(ApplicationPropertyRepository.java:70)
at
com.pstechnology.service.admin.AdministrationService.findApplicationPropertyValue
(AdministrationService.java:179)
at
com.pstechnology.scheduling.trigger.AbolishedTaskSimpleTrigger.getTimerRepeatIntervalValue
(AbolishedTaskSimpleTrigger.java:45)
at
com.pstechnology.scheduling.trigger.AbolishedTaskSimpleTrigger.afterPropertiesSet
(AbolishedTaskSimpleTrigger.java:30)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods
(AbstractAutowireCapableBeanFactory.java:1198)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean
(AbstractAutowireCapableBeanFactory.java:1167)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean
(AbstractAutowireCapableBeanFactory.java:427)
at org.springframework.beans.factory.support.AbstractBeanFactory
$1.getObject(AbstractBeanFactory.java:249)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton
(DefaultSingletonBeanRegistry.java:155)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:246)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:160)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons
(DefaultListableBeanFactory.java:291)
at
org.springframework.context.support.AbstractApplicationContext.refresh
(AbstractApplicationContext.java:352)
at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>
(ClassPathXmlApplicationContext.java:122)
at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>
(ClassPathXmlApplicationContext.java:66)
at com.pstechnology.service.SchedulingContext.initialize
(SchedulingContext.java:56)
at com.pstechnology.servlet.InitializationServlet.init
(InitializationServlet.java:52)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init
(ServletWrapper.java:358)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init
(ServletWrapperImpl.java:169)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize
(ServletWrapper.java:1809)
at
com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper
(WebExtensionProcessor.java:98)
at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings
(WebApp.java:678)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinally
(WebApp.java:429)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize
(WebAppImpl.java:304)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication
(WebGroupImpl.java:100)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication
(VirtualHostImpl.java:166)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp
(WSWebContainer.java:731)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication
(WSWebContainer.java:616)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install
(WebContainerImpl.java:376)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start
(WebContainerImpl.java:668)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start
(ApplicationMgrImpl.java:1122)
at
com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart
(DeployedApplicationImpl.java:1319)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start
(DeployedModuleImpl.java:609)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start
(DeployedApplicationImpl.java:944)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication
(ApplicationMgrImpl.java:725)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start
(ApplicationMgrImpl.java:2046)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start
(CompositionUnitMgrImpl.java:439)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start
(CompositionUnitImpl.java:123)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start
(CompositionUnitMgrImpl.java:382)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$300
(CompositionUnitMgrImpl.java:110)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl
$CUInitializer.run(CompositionUnitMgrImpl.java:949)
at com.ibm.wsspi.runtime.component.WsComponentImpl
$_AsynchInitializer.run(WsComponentImpl.java:349)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1563)
Caused by: javax.naming.AuthenticationException: Login failed:
com.ibm.websphere.security.auth.WSLoginFailedException [Root exception is
com.ibm.websphere.security.auth.WSLoginFailedException]
at com.ibm.ws.naming.util.SecurityUtil.login(SecurityUtil.java:121)
at com.ibm.ws.naming.jndicos.CNContextImpl.login
(CNContextImpl.java:4516)
at com.ibm.ws.naming.jndicos.CNContextImpl.cosResolve
(CNContextImpl.java:2781)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup
(CNContextImpl.java:1790)
... 60 more
Caused by: com.ibm.websphere.security.auth.WSLoginFailedException
at com.ibm.ws.security.ltpa.LTPAServerObject.authenticate
(LTPAServerObject.java:998)
at com.ibm.ws.security.server.lm.ltpaLoginModule.login
(ltpaLoginModule.java:643)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at javax.security.auth.login.LoginContext.invoke
(LoginContext.java:795)
at javax.security.auth.login.LoginContext.access$000
(LoginContext.java:209)
at javax.security.auth.login.LoginContext$4.run
(LoginContext.java:709)
at java.security.AccessController.doPrivileged
(AccessController.java:251)
at javax.security.auth.login.LoginContext.invokePriv
(LoginContext.java:706)
at javax.security.auth.login.LoginContext.login
(LoginContext.java:603)
at com.ibm.ws.security.auth.JaasLoginHelper.jaas_login
(JaasLoginHelper.java:354)
at com.ibm.ws.security.auth.ContextManagerImpl.login
(ContextManagerImpl.java:4024)
at com.ibm.ws.security.auth.ContextManagerImpl.login
(ContextManagerImpl.java:3728)
at com.ibm.ws.security.auth.ContextManagerImpl.login
(ContextManagerImpl.java:3724)
at com.ibm.ws.security.auth.ContextManagerImpl.login
(ContextManagerImpl.java:3475)
at com.ibm.ws.naming.util.SecurityUtil$1.run(SecurityUtil.java:115)
at com.ibm.ws.naming.util.SecurityUtil$1.run(SecurityUtil.java:111)
at com.ibm.ws.security.util.AccessController.doPrivileged
(AccessController.java:118)
at com.ibm.ws.naming.util.SecurityUtil.login(SecurityUtil.java:109)
... 63 more
Caused by: com.ibm.websphere.security.PasswordCheckFailedException
at com.ibm.ws.wim.registry.util.LoginBridge.checkPassword
(LoginBridge.java:204)
at com.ibm.ws.wim.registry.WIMUserRegistry$1.run
(WIMUserRegistry.java:181)
at com.ibm.ws.security.auth.ContextManagerImpl.runAs
(ContextManagerImpl.java:4610)
at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem
(ContextManagerImpl.java:4698)
at
com.ibm.ws.wim.security.authz.jacc.JACCSecurityManager.runAsSuperUser
(JACCSecurityManager.java:432)
at
com.ibm.ws.wim.security.authz.ProfileSecurityManager.runAsSuperUser
(ProfileSecurityManager.java:964)
at com.ibm.ws.wim.registry.WIMUserRegistry.checkPassword
(WIMUserRegistry.java:170)
at com.ibm.ws.security.registry.UserRegistryImpl.checkPassword
(UserRegistryImpl.java:338)
at com.ibm.ws.security.ltpa.LTPAServerObject.authenticate
(LTPAServerObject.java:973)
... 83 more
Caused by: com.ibm.websphere.wim.exception.PasswordCheckFailedException:
CWWIM4537E No principal is found from the 'admin' principal name.
at com.ibm.ws.wim.ProfileManager.loginImpl(ProfileManager.java:3607)
at com.ibm.ws.wim.ProfileManager.genericProfileManagerMethod
(ProfileManager.java:292)
at com.ibm.ws.wim.ProfileManager.login(ProfileManager.java:400)
at com.ibm.websphere.wim.ServiceProvider.login
(ServiceProvider.java:485)
at com.ibm.ws.wim.registry.util.LoginBridge.checkPassword
(LoginBridge.java:169)We are taking another run at TopLink 10.1.3 and have run into this problem again.
It turns out that this is fairly reproducable. It occurs when we remove the last item (or all of the items) from the parent collection.
It occurs with transparent indirection on or off.
I've added several tests to our Junit suite to detect this behavior with various objects. Sometimes they fail, sometimes they pass. Going back to TopLink 9, a couple of the tests that fail in 10 fail, but most of them pass.
Given the number of folks who shared our probem in TopLink9, I wonder how many have a similar problem in 10. I also wonder why the behavior differs somewhat between 9 and 10. Though our expanded test suite is now detecting the behavior in 9, it is less frequent. -
Problem in accessing two different InitialContexts simultaneously
Hi All
I have a strange problem the scenario is as below
I have two different web logic servers as server1 and server2
The Realm on server1 is user1 and password is pwd1
The Realm on server1 is user2 and password is pwd2
In my application on server1 I created the database connection with DataSource lookup by setting InitialContext values as java.naming.security.principal to user1 and java.naming.security.credentials to pwd1 and i have done some data base transaction .
In between i need to made a remote EJB call which is on server2 so i created an other
InitialContext by setting java.naming.security.principal to user2 and java.naming.security.credentials to pwd2 and this 2nd context i am closing after placing the HomeObject in a HashMap.
After completing the EJB call I have to continue the remaining database transactions by getting the connection from lookup.
Here i am getting the following error
*Caused by: java.sql.SQLException: Pool connect failed : java.lang.SecurityException: [Security:090398]Invalid Subject:user2*
If any one has faced the same problem or know the solution to this problem please help me in solving this.
Thanks in Advance.The thread that establishes an initial context with a WLS server gets infected with the security credential of the initial context. Anything that thread does afterwards will be using that credential. A typical solution to this would be to obtain and cache the current subject on the thread before getting the second initial context, and then resume the subject when you need to go back to work with the first initial context. You may want to look into weblogic.Security.Security class for the APIs that you need to accomplish this.
Regards,
Dongbo
Edited by: user650694 on Dec 12, 2008 10:31 AM -
Problem with InitialContext Creation in Weblogic 5.1
Hi all,
We are using Weblogic 5.1 on Windows and Solaris.
We are trying to get InitialContext by the following code snippet.
This piece of code is in a Thread which is kicked off by a startup class.
The purpose of getting the initialContext here is to get a reference to a JMS
queue and to start listening for any messages that are put into the queue.
Hashtable htEnv = new Hashtable();
htEnv.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
htEnv.put(Context.PROVIDER_URL, "t3://ip_address:port_number");
return new InitialContext(htEnv);
Sometimes this code takes almost 15 minutes to return an InitialContext.
Some other times it does not return at all, neither does it throw any exception.
In the application this code may get called multiple times simultaneously.
The problem is not consistent also.
There is one aspect that has been noticed. A number of InitialContext Objects
are initiated in the application and are not closed after use (As recommended
in the weblogic documentation).
The other observation is that the occurrence of the above explained problem is
very consistent when the executeThreadCount of the Weblogic server is low (<=
15). However, once the executeThread count is increased to a higher value (30
to 45) the occurrence of the problem is very rare.
Any information regarding this problem would be extremely helpful.
Thanks and Regards,
UdayThank you Bhagvan,
The creation of initial context in every call is a clear mistake. Caching has
to be implemented.
However , i need some more information about this ....
As you said the initial context is being created at every instant for a lookup
of any object in the jndi tree in the remote machine(I'll name this "machine A").
Simultaneously there is an attempt for creation of an InitialContext in the other
machine(call it "machine B") for the remote "machine A".
This is needed because "machine B" has to get a reference to a JMS queue on "machine
A" and start listening for any messages in it.
It is at this point that the InitialContext creation takes randomly long times
to return.
That is the call is made by populating a Hashtable with the properties of the
remote "machine A" like the IP address, Port number of "machine A" and using this
Hashtable as a parameter in "machine B" to get the InitialContext.
I was also wondering if there is a limit on the number of InitialContext objects
that can be opened at any instant in a server.
Could you please throw more light on these areas ........
Thanks and regards,
uday
"bhagvan" <[email protected]> wrote:
>
Is there any particular reason why you want to get
a new initial context in every call ?? My suggestion
is to cache it based on the application parameters let us
say the client user or client's machine or any other parameter
which is unique for a client.
hope this helps.
"Uday Reddy" <[email protected]> wrote:
Hi all,
We are using Weblogic 5.1 on Windows and Solaris.
We are trying to get InitialContext by the following code snippet.
This piece of code is in a Thread which is kicked off by a startup class.
The purpose of getting the initialContext here is to get a reference
to a JMS
queue and to start listening for any messages that are put into thequeue.
Hashtable htEnv = new Hashtable();
htEnv.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
htEnv.put(Context.PROVIDER_URL, "t3://ip_address:port_number");
return new InitialContext(htEnv);
Sometimes this code takes almost 15 minutes to return an InitialContext.
Some other times it does not return at all, neither does it throw any
exception.
In the application this code may get called multiple times simultaneously.
The problem is not consistent also.
There is one aspect that has been noticed. A number of InitialContext
Objects
are initiated in the application and are not closed after use (As recommended
in the weblogic documentation).
The other observation is that the occurrence of the above explainedproblem
is
very consistent when the executeThreadCount of the Weblogic server is
low (<=
15). However, once the executeThread count is increased to a highervalue
(30
to 45) the occurrence of the problem is very rare.
Any information regarding this problem would be extremely helpful.
Thanks and Regards,
Uday -
JMS Wrappers can't cache JNDI lookups when using secured queues
Hi All!
We are working on a jms client, inside a webapp(servlets), using Weblogic 9.2 and Weblogic 10.3.
As we want to use secured queues and keep being efficient we tryed to use Weblogic JMS Wrappers, that should work according to the docs:
Enhanced Support for Using WebLogic JMS with EJBs and Servlets
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms/j2ee.html
But we are facing a problem:
When we define a JMS Wrapper and try to cache JNDI lookups for the QueueConnectionFactory and Queue, as the docs recommend for efficiency, the connection to the queue is ignoring the user/pwd.
The JMS Wrapper is using <res-auth>Application</res-auth>.
We are creating the connection using createQueueConnection(user, pwd) from QueueConnectionFactory and after several tests it seems that the user and password are ingored unless a jndi lookup is made in the same thread, as if when there are not any thread credentials present user and password are ignored for the connection...
so the question is:
That behaviour goes against Weblogic JMS Wrapper documentation, doesn't it?
Is there then any other way to access efficiently secured queues using a servlet as a client? (iit's not an option for us to use mdbs, or ejbs).
If it helps, this seems related to this still opened spring-weblogic issue: SPR-2941 --> http://jira.springframework.org/browse/SPR-2941 and SPR-4720 --> http://jira.springframework.org/browse/SPR-4720
Thanxs
And here goes our DDs and code to reproduce:
First in pretty format:
web.xml --> http://pastebin.com/f5f85e8d4
weblogic.xml --> http://pastebin.com/f2fbe10cc
Client code --> http://pastebin.com/f586d32d9
And now emmebded in the msg:
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">
<description>WebLogic Descriptor</description>
<resource-description>
<res-ref-name>jms/QCF</res-ref-name>
<jndi-name>weblogic.jms.ConnectionFactory</jndi-name>
</resource-description>
</weblogic-web-app>weblogic.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name> QCFWrapperCredentialsTest </display-name>
<description> QCFWrapperCredentialsTest </description>
<servlet id="Servlet_1">
<servlet-name>QCFWrapperCredentialsTest</servlet-name>
<servlet-class>QCFWrapperCredentialsTest</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping id="ServletMapping_1">
<servlet-name>QCFWrapperCredentialsTest</servlet-name>
<url-pattern>/Test</url-pattern>
</servlet-mapping>
<resource-ref>
<res-ref-name>jms/QCF</res-ref-name>
<res-type>javax.jms.QueueConnectionFactory</res-type>
<res-auth>Application</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</web-app>And our test client:
import java.io.*;
import java.util.Properties;
import javax.jms.*;
import javax.naming.*;
import javax.servlet.http.*;
public class QCFWrapperCredentialsTest extends HttpServlet {
QueueConnectionFactory factory = null;
Queue queue = null;
String jndiName = "java:comp/env/jms/QCF";
String queueName= "jms/ColaEntradaConsultas";
String user = "usuarioColas";
String pwd = "12345678";
String userjndi = "usuarioColas";
String pwdjndi = "12345678";
String serverT3URL="t3://127.0.0.1:7007";
public void init() {
setupJNDIResources();
private void setupJNDIResources(){
try {
Properties props = new Properties();
props.put("java.naming.factory.initial",
"weblogic.jndi.WLInitialContextFactory");
props.put("java.naming.provider.url",serverT3URL );
props.put("java.naming.security.principal", userjndi);// usr
props.put("java.naming.security.credentials", pwdjndi);// pwd
InitialContext ic = new InitialContext(props);
factory = (QueueConnectionFactory) ic.lookup(jndiName);
queue = (Queue) ic.lookup(queueName);
} catch (NamingException e) {
e.printStackTrace();
public void service(HttpServletRequest req, HttpServletResponse res) {
res.setContentType("text/html");
Writer wr = null;
try {
wr = res.getWriter();
//Comment this out, do a lookup for each request and it will work
//setupJNDIResources();
String user = this.user;
String pwd = this.pwd;
//read users and passwords from the request in case they are present
if (req.getParameter("user") != null) {
user = req.getParameter("user");
if (req.getParameter("pwd") != null) {
pwd = req.getParameter("pwd");
wr.write("JNDI User: *" + userjndi + "* y pwd: *" + pwdjndi + "*<p>");
wr.write("Queue User: *" + user + "* y pwd: *" + pwd + "*<p>");
//Obtain a connection using user/pwd
QueueConnection conn = factory.createQueueConnection(user, pwd);
QueueSession ses = conn.createQueueSession(true,
Session.SESSION_TRANSACTED);
QueueSender sender = ses.createSender(queue);
TextMessage msg = ses.createTextMessage();
msg.setText("Hi there!");
conn.start();
sender.send(msg);
ses.commit();
sender.close();
ses.close();
conn.close();
} catch (Exception e) {
e.printStackTrace();
try {
wr.write(e.toString());
} catch (Exception e2) {
e2.printStackTrace();
finally{
try {
wr.close();
} catch (IOException e) {
e.printStackTrace();
}Edited by: user2525402 on Feb 9, 2010 7:14 PMThanks Tom,
Quite a useful response .-)
Leaving aside the fact that weblogic behaviour with jms wrappers and secured queues seems to not be working as the docs says...
Talking about workarounds:
Both workarounds you suggest works, but as you already noted, creating a new JNDI context just to inject credentials into the threads is overkill when high performance is needed.
I also found more information about the same issue here: http://sleeplessinslc.blogspot.com/2009/04/weblogic-jms-standalone-multi-threaded.html
And he suggest the same workaround, injecting credentials
So I tried the second approach, successfully, injecting credentials into the thread using the security API.
This way, using JMS wrappers and injecting credentials into the thread we get the best performance available, caching resource using wrappers and using credentials in a somewhat efficient way.
Now the test snippet looks like this:
import java.io.*;
import java.security.PrivilegedAction;
import java.util.Properties;
import javax.jms.*;
import javax.naming.*;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginException;
import javax.servlet.http.*;
import weblogic.jndi.Environment;
import weblogic.security.auth.Authenticate;
public class JMSWrapperCredentialsTest extends HttpServlet {
QueueConnectionFactory factory = null;
Queue queue = null;
String jndiName = "java:comp/env/jms/QCF";
String queueName= "jms/ColaEntradaConsultas";
String user = "usuarioColas";
String pwd = "12345678";
String userjndi = "usuarioColas";
String pwdjndi = "12345678";
String serverT3URL="t3://127.0.0.1:7007";
public void init() {
setupJNDIResources();
private void setupJNDIResources(){
try {
Properties props = new Properties();
props.put("java.naming.factory.initial",
"weblogic.jndi.WLInitialContextFactory");
props.put("java.naming.provider.url",serverT3URL );
props.put("java.naming.security.principal", userjndi);// usr
props.put("java.naming.security.credentials", pwdjndi);// pwd
InitialContext ic = new InitialContext(props);
factory = (QueueConnectionFactory) ic.lookup(jndiName);
queue = (Queue) ic.lookup(queueName);
} catch (NamingException e) {
e.printStackTrace();
public void service(HttpServletRequest req, HttpServletResponse res) {
final HttpServletRequest fReq=req;
final HttpServletResponse fRes=res;
PrivilegedAction action = new java.security.PrivilegedAction() {
public java.lang.Object run() {
performRequest(fReq,fRes);
return null;
try {
Subject subject=createSingleSubject(serverT3URL,user,pwd);
weblogic.security.Security.runAs(subject, action);
} catch (Exception e) {
e.printStackTrace();
public void performRequest(HttpServletRequest req, HttpServletResponse res) {
res.setContentType("text/html");
Writer wr = null;
try {
wr = res.getWriter();
//Comment this out, do a lookup for each request and it will work
//setupJNDIResources();
String user = this.user;
String pwd = this.pwd;
//read users and passwords from the request in case they are present
if (req.getParameter("user") != null) {
user = req.getParameter("user");
if (req.getParameter("pwd") != null) {
pwd = req.getParameter("pwd");
wr.write("JNDI User: *" + userjndi + "* y pwd: *" + pwdjndi + "*<p>");
wr.write("Queue User: *" + user + "* y pwd: *" + pwd + "*<p>");
//Obtain a connection using user/pwd
QueueConnection conn = factory.createQueueConnection(user, pwd);
QueueSession ses = conn.createQueueSession(true,
Session.SESSION_TRANSACTED);
QueueSender sender = ses.createSender(queue);
TextMessage msg = ses.createTextMessage();
msg.setText("Hi there!");
conn.start();
sender.send(msg);
ses.commit();
sender.close();
ses.close();
conn.close();
} catch (Exception e) {
e.printStackTrace();
try {
wr.write(e.toString());
} catch (Exception e2) {
e2.printStackTrace();
finally{
try {
wr.close();
} catch (IOException e) {
e.printStackTrace();
private Subject createSingleSubject(String providerUrl, String userName, String password) {
Subject subject = new Subject();
// Weblogic env class
Environment env = new Environment();
if(providerUrl!=null)
env.setProviderUrl(providerUrl);
env.setSecurityPrincipal(userName);
env.setSecurityCredentials(password);
try {
// Weblogic Authenticate class will populate and Seal the subject
Authenticate.authenticate(env, subject);
return subject;
catch (LoginException e) {
throw new RuntimeException("Unable to Authenticate User", e);
catch (Exception e) {
throw new RuntimeException("Error authenticating user", e);
}Thanks a lot for the help
Maybe you are looking for
-
How to install oracle 11g on fedora 13 or RHLE
hello, am a beginner on linux and start study oracle developer self study and i need some one explain hot to install oracle on fedora or rhle or centos i give up using microshit sorry microsoft so any one help me plz
-
PhotoShop Elements 5.0 error messages
I have read all the problems that everyone has been having with Adobe Photoshop Elements 5.0, I also until ONE day ago have received the error message (Adobe Photoshop: Attempt to access invalid address). Yes, Adobe Support has reply that they no l
-
Marking up a downloaded document
Hi all! Not too tech savy over here to say the least, so I have a Q for those here who are. I just downloaded and saved to file, an application form in pdf, on adobe reader. I want to fill the application out on the computer, as opposed to copying i
-
Are equations created with MathMagic in Captivate 7 accessible for screen readers?
I'm looking for the best way to create accessible math equations in Captivate 7. Also, on a related note, the sample "clips" that should appear in MathMagic are not showing up in the Clips window when I insert an equation in Captivate. Can I download
-
Not sure anyone will be able to helpbut here goes; I have a series of articles each with a web view. The html image is set to 400pxls square, and I create my web view 400, so when imported into a 768x1024 folio, the html animation works fine. And thi