InitialContext Caching
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,
Doug
Why 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
Similar Messages
-
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 -
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 -
Singleton, Concurrency and Performance
Dear all,
Below is part of the code of my Singleton ServiceLocator:
public class ServiceLocator {
private InitialContext ic;
private Map cache;
private static ServiceLocator me;
static {
try {
me = new ServiceLocator();
} catch(ServiceLocatorException se) {
System.err.println(se);
se.printStackTrace(System.err);
private ServiceLocator() throws ServiceLocatorException {
try {
ic = new InitialContext();
cache = Collections.synchronizedMap(new HashMap());
} catch (NamingException ne) {
throw new ServiceLocatorException(ne);
} catch (Exception e) {
throw new ServiceLocatorException(e);
public static ServiceLocator getInstance() {
return me;
public EJBLocalHome getLocalHome(String jndiHomeName) throws ServiceLocatorException {
EJBLocalHome home = null;
try {
if (cache.containsKey(jndiHomeName)) {
home = (EJBLocalHome) cache.get(jndiHomeName);
} else {
home = (EJBLocalHome) ic.lookup(jndiHomeName);
cache.put(jndiHomeName, home);
} catch (NamingException ne) {
throw new ServiceLocatorException(ne);
} catch (Exception e) {
throw new ServiceLocatorException(e);
return home;
I 've some questions concerning the concept of Singleton:
1. Assume using the code above. If 2 threads access the getInstance method at the same time, is that one of the thread will get the instance and the other thread will get null or queued up and wait?
2. If the answer of question #1 is positive, can we conclude that Singleton will lower the performance of web application which needs high concurrency?
3. Should we create a pool of ServiceLocators instead of making it Singleton?
4. For EJBs looking up EJBs, why we should not use Singleton ServiceLocator?
Thanks in advance.
Jerry.I 've some questions concerning the concept of
Singleton:
1. Assume using the code above. If 2 threads access
the getInstance method at the same time, is that one
of the thread will get the instance and the other
thread will get null or queued up and wait?If I read correctly your code, your initialize the singleton instance statically (beforehand).
The first thread that invokes getInstance will be somehow "queued up" while the VM loads and initializes the ServiceLocator class (including executing the static block that initializes the singleton instance).
Afterwards, for the lifetime of this VM, all subsequent threads that will invoke getInstance will undergo no penalty, as no synchronization is involved.
Well-known threading issues involving singleton access (search "Double-checked locking") appear only with code that wants to perform "lazy loading" without synchronization.
Performance issues (or supposed performance issues) incurred by synchronization only occur to code that uses synchronized blocks or methods, obviously.
2. If the answer of question #1 is positive, can we
conclude that Singleton will lower the performance of
web application which needs high concurrency?First, I woudn't worry too much about it prematurely.
Next, if this singleton happens to be a performance bottleneck, it wouldn't be in the getInstance but merely in your access to the synchronized collection (which, by the way, does not prevent an EJBLOcalHome to be looked up and inserted twice :o)
But I sincerely doubt it could be anything measurable.
So go ahead with a plain simple singleton this way. If you happen to hit a performance problem, profile it and come back with the results.
3. Should we create a pool of ServiceLocators instead
of making it Singleton?You need to pool objects when their methods use up a lot of serial time.
Here I really think the getLocalHome will be fast enough to not matter compared to everything else (DB access, file access, network latency, your business logic,...).
If if it did, there would be other means (read-write lock) to lower the serial cost.
Moreover, pooling your locator would divide your cache efficiency (hits/hits+misses) by the number of instances...
>
4. For EJBs looking up EJBs, why we should not use
Singleton ServiceLocator?? -
Difficult ClassLoader problems with multiple deployed enterprise Apps
Greetings!
When multiple instances of an enterprise application are deployed, ClassLoader issues are causing ClassCast Exceptions in the instantiation of Stateless SessionBeans. These ClassCast Exceptions are causing the Stateless Session beans to not be created appropriately/correctly, and in turn there is an InvocationTargetException resulting in an HTTP 500 Internal Server Error (mapped to a custom handler).
The setup is SJSAS2005Q2, JDK 1.5, MySQL 5.0, Linux (RedHat 9, and Debian 3.0/3.1)
Below is a typical example:
Exception creating stateless session bean : [{0}]java.lang.reflect.InvocationTargetException
<<long stack Trace omitted>>
Caused by: java.lang.ClassCastException: $Proxy111 at com.acjust.ecommerce.ejb.preferences.PreferenceManagerBean.ejbCreate(PreferenceManagerBean.java:354) ... 67 moreHere is the code from PreferenceManagerBean, the offending line is the (first one) that does a lookup on PreferencesBean and casts the result. This is a SessionFacade (there are many others) and they all (may) exhibit this behavior when there are multiple enterprise apps running.
public void ejbCreate() {
LookupServiceHelper lookup = LookupServiceHelper.getInstance();
preferencesHome = (LocalPreferencesHome)
lookup.getLocalHome(IConstants.PREFERENCES_BEAN);
companyInformationHome = (LocalCompanyInformationHome)
lookup.getLocalHome(IConstants.COMPANY_INFORMATION_BEAN);
businessAddressHome = (LocalBusinessAddressHome)
lookup.getLocalHome(IConstants.BUSINESS_ADDRESS_BEAN);
sitePreferencesHome = (LocalSitePreferencesHome)
lookup.getLocalHome(IConstants.SITE_PREFERENCES_BEAN);
paymentPreferencesHome = (LocalPaymentPreferencesHome)
lookup.getLocalHome(IConstants.PAYMENT_PREFERENCES_BEAN);
productPreferencesHome = (LocalProductPreferencesHome)
lookup.getLocalHome(IConstants.PRODUCT_PREFERENCES_BEAN);
}When there is one instance of the App, it works perfectly. When there are two instances, one works perfectly, and the other one will have the above issues with the instantiation of Stateless Session Beans (the broken enterprise app is the one that is NOT loaded or reloaded most recently).
Thinking that the problem may be solved by rearranging or repackaging the software, multiple solutions have been tried. (ClassCast Exceptions such as these are typically the result of helper classes being loaded by one class-loader, then loaded by another, compared or casted, and the two are not equivalent). In this case, though, the software is behaving as though each enterprise app does not have its own class loader hierarchy, which is obviously highly undesirable for the situation at-hand. At any rate, bundling all library classes at the app server classpath level, putting all library classes in each jar, and war, and putting all library classes in the ear/lib directory and using MANIFEST.MF classpath entries to point all ear subcomponents at the library classes - none of these potential solutions has alleviated this problem. In addition, the EJB classes themselves triggering the exception(s) are not helper classes but EJBs that are correctly packaged in their respective EJB-JARS.
Here is the sun SJSAS 8 classloader hierarchy from the userguide:
http://docs.sun.com/source/817-6087/dgdeploy.html#wp58491
Can somebody from the Sun App Server team speak to whether or not this is an Application Server issue? Why should the classloader hierarchy from one enterprise app interfere with any other? Are there known workarounds?
Any help is greatly appreciated.
Best, AdamHi Ken,
I have pretty much ruled out "artifacts" in the Application Server's Classpath, because we already tried reinstalling the Application Server. It is a freshly downloaded SJSAS 8 2005 Q2 downloaded a few days ago with nothing added to the Server Classpath other than a database driver [${com.sun.aas.installRoot}/mysql/lib/mysql-connector-java-3.1.11-bin.jar added to the server CLASSPATH suffix after the PointBase driver(s)].
Yes, each ear has its own name. Once the two enterprise apps have been created/packaged by the ANT build script (they are the same except for the slight differences in deployment descriptors we discussed earlier), one is renamed and we use the SJSAS administrative console to deploy them, both deploy correctly, without errors and begin listening for connections at their respective context-roots. Each enterprise application has two web-wars, one public/customer facing, and one administrative. The first enterprise app listens on /e (public facing) and /a (administrative) and the second listens on / (public facing) and /admin (administrative).
Also, you are correct; each ear has its own copy of the LookupServiceHelper class. Again, there is nothing shared on the App Server Classpath other than that jdbc driver for mysql.
Here is the LookupServiceHelper code:
package com.acjust.ecommerce.util;
import java.sql.Connection;
import java.sql.SQLException;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import java.util.logging.Logger;
import javax.ejb.EJBLocalHome;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;
* This class provides JNDI helper functions to look up EJB
* Home implementations.
* @author Copyright (c) 1998-2005 by A. C. Just, Inc. All Rights Reserved.
public class LookupServiceHelper {
* This is the only object of type LookupServiceHelper; this class
* is a singleton.
private static LookupServiceHelper instance = null;
* The logging object for this singleton
private final Logger logger = Logger.getLogger(getClass().getName());
private InitialContext initialContext = null;
private Map cache = null;
* The no argument constructor is private to enforce the fact
* that we do not want to create any other instances of this
* class.
private LookupServiceHelper() {
try {
initialContext = new InitialContext();
cache = Collections.synchronizedMap(new HashMap());
} catch (NamingException ne) {
throw new LookupServiceException(ne);
} catch (Exception e) {
throw new LookupServiceException(e);
* This method returns the only object of this class.
* @return instance The only object of type LookupServiceHelper.
public static LookupServiceHelper getInstance() {
if(null == instance) {
try {
instance = new LookupServiceHelper();
} catch (LookupServiceException lse) {
instance.logger.severe("Failed to create lookup service " +
lse.getMessage());
return instance;
* This utility method looks up an enterprise JavaBean
* in the distributed naming service. It is not type safe;
* that property is guaranteed by the callers.
* @param bean The name of the enterprise JavaBean to find
* in the naming service (a prefix will be automatically added).
* @return An Object that can be casted to a LocalHomeInterface.
public EJBLocalHome getLocalHome(String bean) {
EJBLocalHome localHome = null;
logger.entering("LookupServiceHelper","getLocalHome",bean);
try {
String jndiHomeName = getFullyQualifiedEJBName(bean);
logger.info("looking for " + jndiHomeName);
if (cache.containsKey(jndiHomeName)) {
logger.info("found cached reference");
localHome = (EJBLocalHome) cache.get(jndiHomeName);
} else {
logger.info("no reference found; performing lookup");
localHome = (EJBLocalHome) initialContext.lookup(jndiHomeName);
cache.put(jndiHomeName, localHome);
} catch (NamingException ne) {
throw new LookupServiceException(ne);
} catch (Exception e) {
throw new LookupServiceException(e);
logger.exiting("LookupServiceHelper","getLocalHome",localHome);
return localHome;
* This utility method looks up a javax.mail.Session session
* in the distributed naming service. It is not type safe;
* that property is guaranteed by the callers.
* @param resource The name of the mail session resource to find
* in the naming service (a prefix will be automatically added).
* @return An Object that can be casted to a javax.mail.Session.
public javax.mail.Session getMailSession(String resource) {
javax.mail.Session session = null;
logger.entering("LookupServiceHelper","getMailSession",resource);
try {
String jndiName = getFullyQualifiedMailResourceName(resource);
logger.info("looking for " + jndiName);
if (cache.containsKey(jndiName)) {
logger.info("found cached reference");
session = (javax.mail.Session) cache.get(jndiName);
} else {
logger.info("no reference found; performing lookup");
session = (javax.mail.Session) initialContext.lookup(jndiName);
cache.put(jndiName, session);
} catch (NamingException ne) {
throw new LookupServiceException(ne);
} catch (Exception e) {
throw new LookupServiceException(e);
logger.exiting("LookupServiceHelper","getMailSession",session);
return session;
* Get a connection from the database pool.
* @return Connection
public Connection getDBConnection(String resource) {
Connection connection = null;
try {
String jndiName = getFullyQualifiedDBName(resource);
logger.info("looking for " + jndiName);
if(cache.containsKey(jndiName)) {
logger.info("found cached reference");
connection = (Connection) cache.get(jndiName);
} else {
logger.info("no reference found; performing lookup");
DataSource dataSource = (DataSource) initialContext
.lookup(jndiName);
connection = dataSource.getConnection();
//do not cache the database connection;
//you will get an IllegalStateException if you do
//cache.put(jndiName,connection);
} catch(NamingException ne) {
logger.warning("getConnection failed (naming): " + ne.getMessage());
throw new LookupServiceException(ne);
} catch (SQLException sql) {
logger.warning("getConnection failed (db): " + sql.getMessage());
throw new LookupServiceException(sql);
return connection;
* This utility method takes an enterprise JavaBean name
* and combines it with a prefix to form a fully qualified name
* suitable for using to query the distributed naming service.
* @param bean The name of the enterprise JavaBean to add.
* @return The fully qualified name (e.g. java:comp/env/ejb/ABeanRef).
private String getFullyQualifiedEJBName(String bean) {
return IConstants.JNDI_EJB_PREFIX + bean;
* This utility method takes a messaging resource name
* and combines it with a prefix to form a fully qualified name
* suitable for using to query the distributed naming service.
* @param resource The name of the mail resource
* @return The fully qualified name (e.g. java:comp/env/mail/MailSessionRef).
private String getFullyQualifiedMailResourceName(String resource) {
return IConstants.JNDI_MAIL_PREFIX + resource;
* This utility method takes a messaging resource name
* and combines it with a prefix to form a fully qualified name
* suitable for using to query the distributed naming service.
* @param jdbc The name of the JDBC resource.
* @return The fully qualified name (e.g. java:comp/env/jdbc/mysql).
private String getFullyQualifiedDBName(String resource) {
return IConstants.JNDI_DB_PREFIX + resource;
Some sample exception stack trace(s) (this is a different stateless session than the one before - but indicative of the same problem).
[#|2005-11-10T14:00:20.566-0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.container.ejb|_ThreadID=29;|EJB5070: Exception creating stateless session bean : [{0}]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:410)
at com.sun.ejb.containers.StatelessSessionContainer.access$100(StatelessSessionContainer.java:75)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:597)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:168)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:359)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:1072)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:772)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:126)
at $Proxy167.authenticateCustomer(Unknown Source)
at com.acjust.ecommerce.web.businessdelegate.customer.CustomerManagerBusinessDelegate.authenticate(CustomerManagerBusinessDelegate.java:77)
at com.acjust.ecommerce.web.action.customer.LoginAction.execute(LoginAction.java:29)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:185)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:653)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:534)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doTask(ProcessorTask.java:403)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:55)
Caused by: java.lang.ClassCastException: $Proxy214
at com.acjust.ecommerce.ejb.client.customermanager.CustomerManagerBean.ejbCreate(CustomerManagerBean.java:71)
... 49 more
|#]
[#|2005-11-10T14:00:20.577-0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.container.ejb|_ThreadID=29;|EJB5018: An exception was thrown during an ejb invocation on [CustomerManagerBean]|#]
[#|2005-11-10T14:00:20.578-0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.container.ejb|_ThreadID=29;|
javax.ejb.EJBException: nested exception is: javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.lang.reflect.InvocationTargetException
javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.lang.reflect.InvocationTargetException
javax.ejb.CreateException: Could not create stateless EJB: java.lang.reflect.InvocationTargetException
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:418)
at com.sun.ejb.containers.StatelessSessionContainer.access$100(StatelessSessionContainer.java:75)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:597)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:168)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:359)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:1072)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:772)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:126)
at $Proxy167.authenticateCustomer(Unknown Source)
at com.acjust.ecommerce.web.businessdelegate.customer.CustomerManagerBusinessDelegate.authenticate(CustomerManagerBusinessDelegate.java:77)
at com.acjust.ecommerce.web.action.customer.LoginAction.execute(LoginAction.java:29)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:185)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:653)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:534)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doTask(ProcessorTask.java:403)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:55)
javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.lang.reflect.InvocationTargetException
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:599)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:168)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:359)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:1072)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:772)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:126)
at $Proxy167.authenticateCustomer(Unknown Source)
at com.acjust.ecommerce.web.businessdelegate.customer.CustomerManagerBusinessDelegate.authenticate(CustomerManagerBusinessDelegate.java:77)
at com.acjust.ecommerce.web.action.customer.LoginAction.execute(LoginAction.java:29)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:185)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:653)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:534)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doTask(ProcessorTask.java:403)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:55)
javax.ejb.EJBException: nested exception is: javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.lang.reflect.InvocationTargetException
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:364)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:1072)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:772)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:126)
at $Proxy167.authenticateCustomer(Unknown Source)
at com.acjust.ecommerce.web.businessdelegate.customer.CustomerManagerBusinessDelegate.authenticate(CustomerManagerBusinessDelegate.java:77)
at com.acjust.ecommerce.web.action.customer.LoginAction.execute(LoginAction.java:29)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:185)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:653)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:534)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doTask(ProcessorTask.java:403)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:55)
|#]
[#|2005-11-10T14:00:20.651-0800|WARNING|sun-appserver-pe8.1_02|org.apache.struts.action.RequestProcessor|_ThreadID=29;|Unhandled Exception thrown: class javax.ejb.EJBException|#]
[#|2005-11-10T14:00:20.779-0800|SEVERE|sun-appserver-pe8.1_02|javax.enterprise.system.container.web|_ThreadID=29;|StandardWrapperValve[action]: Servlet.service() for servlet action threw exception
javax.ejb.EJBException: nested exception is: javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.lang.reflect.InvocationTargetException
javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.lang.reflect.InvocationTargetException
javax.ejb.CreateException: Could not create stateless EJB: java.lang.reflect.InvocationTargetException
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:418)
at com.sun.ejb.containers.StatelessSessionContainer.access$100(StatelessSessionContainer.java:75)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:597)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:168)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:359)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:1072)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:772)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:126)
at $Proxy167.authenticateCustomer(Unknown Source)
at com.acjust.ecommerce.web.businessdelegate.customer.CustomerManagerBusinessDelegate.authenticate(CustomerManagerBusinessDelegate.java:77)
at com.acjust.ecommerce.web.action.customer.LoginAction.execute(LoginAction.java:29)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:185)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:653)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:534)
at com.sun.enterprise.web.connector.grizzly.Proce -
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? -
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 -
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]) -
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 -
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 -
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
-
Error while running forge post Endeca integration with ATG
Hi All, We have integrated Endeca application with ATG and then tried running the Endeca baseline update script. However the script failed with the below error message Parsing XML dimensions data with validation turned on Parsing project file "C:\app
-
Flash 11.7.700.169: "Adobe Flash Player 11.7 r700 has stopped working"
Okay, I posted this already, and have had no one help me. I posted this 2 days ago!!! Original post: http://forums.adobe.com/message/5314268#5314268 Please. If I'm missing something, let me know. If there's help, where is it? Where's Adobe's prompt h
-
HP C7280 all-in-one duplex printing problem - Long and short sided binding!
I use a HP 7280 all-in-one printer and have the duplexer attached. Up to installing snow leopard I have been able to print two sided documents from ipages no problems. But now every time I try to print a two sided document in flips the second side ve
-
Hardware: SSD drives and scratch disks
Hi, I am building a new system for Photoshop. Two quick questions: 1. I note in Adobe's system reqs it says Photoshop cannot be installed on flash-based storage devices. Does this include SSDs? Is there a genuine problem here (i.e. if my application
-
NM output is slight different than in MA
Hi guys, one questions from MA newbe. i use default parser in NM and default viewpoint in MA, but there are some missing information in MA: No router preference and output is slight different than in NM, like A is H now. i used before NM, but now try