[GLASSFISH-19891] Connection Pool timing out in-use (checked out) connections. Created: 15/Mar/13  Updated: 15/Mar/13

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: bvarner Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian linux 6.0, Oracle JDK 7



 Description   

I'm running glassfish 3.1.2.2 on Oracle JDK 7, Debian 6.0 (x86_64, amd64).

Here's the behavior I see. The thread that processes idle connection timeout is ignoring if a connection managed by the pool is checked out or checked in, and closes it even if it's currently in use.

Set "Idle Timeout" to something non-zero. (say, 60 seconds)

@Resource(name = "jdbc/some/pool")
DataSource dataSource;


public void doSomething() {
    Connection c = dataSource.getConnection();
    try {
    // Do things with this connection. Operations which take longer to complete than 'idle timeout'.
    // We use jasper reports to generate some really complex reports with a connection. The connection handle is 
    // constantly in use during this process. Yet, for some reason, after <idle timeout> seconds, the connection
    // underlying the handle is 'closed' by the idle timeout.
    } finally {
         // Of course you should close this nicely, or use the JDK7 try with resources....
         c.close();
    }
}

The end result is that my transaction fails, gets marked rollback only, my application fails to work properly unless I'm using fixed-size connection pools, and the monitoring metrics get skewed.

I have connection pools reporting obscure numbers. From what I remember stepping through the code the other day, the managed connection factory (or whatever was maintaining monitoring counts) isn't properly updating the metrics in at least one case where an exception (unexpectedly) occurs. While that itself is another bug, it's also a side-effect of a poorly behaving container that seems to have a difference concept of the word 'idle' than any other connection pool I've ever seen.

It's like glassfish considers the only operations which determine 'idle' state as getConnection() and close().






[GLASSFISH-5232] Inbound Resource Adatper - required-config-property Created: 30/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: franz1180 Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File testConnectorEAR.ear    
Issuezilla Id: 5,232

 Description   

Although not required by the jca 1.5 spec (marked as optinal) it would be quite
useful if the jca container would check the required-config-property tags of an
inbound resource adapter.

Up to now the required-config-property tags are not checked, so that mdb can
register themselves for inbound processing even if they have incorrect settings

Adding a check for the required-config-property tags would enhance the way of
error handling because erros would already occur before runtime - they would be
checked during deployment giving better error messages

i will also add a test application which shows the bug



 Comments   
Comment by franz1180 [ 30/Jun/08 ]

Created an attachment (id=1592)
EAR Application with a resource adapter containing an required-config-property - EJB application gets deployed although it dosn't set the required-config-property

Comment by Sivakumar Thyagarajan [ 23/Jul/08 ]

Requesting Jagadish to investigate and fix.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-14753] Oracle proxy session problems Created: 17/Nov/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: ailitche Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File SunAS9ServerPlatform.java    
Issuezilla Id: 14,753

 Description   

To reproduce define two GF data sources that use Oracle database - jta-managed
and non jta-managed. Set maxpoolsize of non-jta data source to 1.
Let's say the Oracle data sources use user "MY_MAIN_USER".
In the Oracle database create a new user "MY_PROXY_USER" and grant it
connection through main user:
create user "MY_PROXY_USER" identified by "password";
grant connect to "MY_PROXY_USER";
grant resource to "MY_PROXY_USER";
alter user "MY_PROXY_USER" grant connect through "MY_MAIN_USER";

In both tests below the following proxyProperties used to open proxy session:
Properties proxyProperties = new Properties();
proxyProperties.setProperty(OracleConnection.PROXY_USER_NAME, "MY_PROXY_USER");

Issue 1 (jta).
Run a simple test: in non-transactioned method on session bean:
begin jta transaction;
acquire connection from jta data source;
unwrap the contained in the connection OracleConnection;
oracleConnection.openProxySession(OracleConnection.PROXYTYPE_USER_NAME,
proxyProperties);
rollback jta transaction

that causes:
<error message="org.omg.CORBA.INTERNAL: JTS5031: Exception
[org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on
Resource [rollback] operation. vmcid: 0x0 minor code: 0 completed: No"
type="javax.transaction.SystemException">javax.transaction.SystemException:
org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid:
0x0 minor code: 0 completed: Maybe] on Resource [rollback] operation. vmcid:
0x0 minor code: 0 completed: No
at com.sun.jts.jta.TransactionManagerImpl.rollback
(TransactionManagerImpl.java:359)
at
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.rollbackD
istributedTransaction(JavaEETransactionManagerJTSDelegate.java:208)
at
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.rollback
(JavaEETransactionManagerSimplified.java:881)
at com.sun.enterprise.transaction.TransactionManagerHelper.rollback
(TransactionManagerHelper.java:94)
at
org.eclipse.persistence.testing.tests.jpa.proxyauthentication.ProxyAuthenticatio
nServerTestSuite.testJtaDataSource(ProxyAuthenticationServerTestSuite.java:377)
at
org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBareServer
(JUnitTestCase.java:534)
at
org.eclipse.persistence.testing.framework.server.TestRunnerBean.runTest
(TestRunnerBean.java:87)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod
(EJBSecurityManager.java:1056)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke
(EJBSecurityManager.java:1128)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod
(BaseContainer.java:5292)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext
(InterceptorManager.java:797)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround
(SystemInterceptorProxy.java:157)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke
(SystemInterceptorProxy.java:139)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept
(InterceptorManager.java:858)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext
(InterceptorManager.java:797)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept
(InterceptorManager.java:367)
at com.sun.ejb.containers.BaseContainer.__intercept
(BaseContainer.java:5264)
at com.sun.ejb.containers.BaseContainer.intercept
(BaseContainer.java:5252)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke
(EJBObjectInvocationHandler.java:201)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke
(EJBObjectInvocationHandlerDelegate.java:75)
at $Proxy137.runTest(Unknown Source)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod
(ReflectiveTie.java:146)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke
(ReflectiveTie.java:176)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServan
t(CorbaServerRequestDispatcherImpl.java:682)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch
(CorbaServerRequestDispatcherImpl.java:216)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest
(CorbaMessageMediatorImpl.java:1841)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest
(CorbaMessageMediatorImpl.java:1695)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput
(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback
(RequestMessage_1_2.java:221)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest
(CorbaMessageMediatorImpl.java:797)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch
(CorbaMessageMediatorImpl.java:561)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork
(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork
(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run
(ThreadPoolImpl.java:528)
</error>

All it takes to avoid exception is to close proxy session before the rollback:
oracleConnection.close(OracleConnection.PROXY_SESSION);
It's easily done in the test above, however if rollback is cause by timeout the
user has no chance to close proxy connection - so GF should do that:
if(oracleConnection.isProxySession())

{ oracleConnection.close(OracleConnection.PROXY_SESSION); }

Issue 2 (non-jta).
Probably related to the first one: connection released back to the connection
pool with the proxy session still open.
Run a simple test: in non-transactioned method on session bean:
acquire connection from non-jta data source;
unwrap the contained in the connection OracleConnection;
oracleConnection.openProxySession(OracleConnection.PROXYTYPE_USER_NAME,
proxyProperties);
release the connection;
again, acquire connection from non-jta data source;
unwrap the contained in the connection OracleConnection;
oracleConnection.isProxyProperty() returns true.

That means the connection has been released into the pool with proxy session
still opened.



 Comments   
Comment by ailitche [ 17/Nov/10 ]

Created an attachment (id=5502)
Eclipselink uses unwrapConnection method of the attached class to unwrapped connection acquired from ds

Comment by Jagadish [ 20/Nov/10 ]

This isn't a bug as such in the pooling/JDBC infrastructure since using physical
connection is out of control of pooling mechanism.
Marking this as Enhancement.





[GLASSFISH-10392] Warning messages when shutting down instance with LOCAL broker and active connections Created: 19/Oct/09  Updated: 06/Jan/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Attachments: Text File server.log    
Issuezilla Id: 10,392
Status Whiteboard:

v3_exclude 3.1-exclude

Tags: 3_1-exclude

 Description   

Configure Glassfish to use a LOCAL broker and run an application which creates
and closes some outbound MQ connections (e.g. using a Session Bean). Then shut
down the instance. The server log shows numerous warning messages.

What follows is an example, see the attached server.log for a full example.

MQJMSRA_CL1101: onEvent:Connection Event for mc=7 :xacId=:event:E201:[E201]:
Connection closed due to admin requested shutdown: localhost:7676(2669),
com.sun.messaging.jms.notification.ConnectionClosedEvent[source=BrokerAddress=localhost:7676(2669),
ConnectionID=910048231024248064, ReconnectEnabled: true, IsConnectedToHABroker:
false]

[I500]: Caught JVM Exception: java.io.EOFException: Trying to read 72 bytes.
Already read 0 bytes.

[I107]: Connection recover state: RECOVER_INACTIVE, broker: localhost:7676(2669)

[I107]: Connection recover state: RECOVER_INACTIVE, broker: localhost:7676(2669)
[I107]: Connection recover state: RECOVER_INACTIVE, broker: localhost:7676(2669)
[I500]: Caught JVM Exception: java.lang.NullPointerException
[I500]: Caught JVM Exception: com.sun.messaging.jms.JMSException: [C4062]:
Cannot perform operation, connection is closed.
[I500]: Caught JVM Exception: java.net.SocketException: Socket is closed

It appears that the problem is that the RA is being shut down before the
connection pool is shut down.

This problem can be seen with Glassfish 2.1.1 build 29.
This problem does not occur with Glassfish V3 build 64.



 Comments   
Comment by Nigel Deakin [ 19/Oct/09 ]

Created an attachment (id=3550)
server log to demonstrate issue

Comment by Satish Kumar [ 20/Oct/09 ]

Adding v3_exclude to the status whiteboard since this works on V3...

Comment by Satish Kumar [ 26/Oct/09 ]

In v2.x, ra.stop is called before terminating all connections. Hence the
exceptions below.

This issue has been fixed in V3 but is still a problem in the v2.x code base.
Requestion Jagadish to investigate this issue...

Comment by Jagadish [ 14/May/10 ]

This issue is not applicable for v3.x versions.
v3.x versions has a proper shutdown sequence, all pools, resources are destroyed
and then resource-adapter is stopped during server shutdown or rar undeployment.

Comment by Jagadish [ 15/May/10 ]

Fixing status whiteboard keys

Comment by jthoennes [ 17/May/10 ]

Hi Jagadish,

I am wondering why you assigned the milestone v2.1.2 to this issue.
I was thinking the v2.1 development has been stopped to concentrate on v3.

Did Sun Oracle change its mind?

Thanks, Jörg

Comment by Jagadish [ 17/May/10 ]

Hi Jorg,
v2.x code base and v3.x code base are significantly different.
The shutdown sequence of connection-pools and resource-adapter are proper in v3
and hence this issue is not applicable for v3.x versions.
This issue will be applicable for v2.x versions only but the default target
milestone for any issue created in issue tracker is 3.0.1. Usually, the target
milestone will be current development version (or next release) of the product.
For 2.1.1 based code base, next logical release number available in issue
tracker is 2.1.2 (though there are no current plans for 2.1.2, AFAIK) and hence
I marked target milestone as 2.1.2
If there is any other release number (> 2.1.1, based on v2.x code base) that
will be planned as next release, I shall update the target milestone accordingly.

Thanks,
-Jagadish

Comment by Jagadish [ 05/Oct/10 ]

3.1-exclude keyword





[GLASSFISH-11680] unregister resource triggers exception Created: 15/Mar/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: vince kraemer Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 11,680
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude

 Description   

See https://netbeans.org/bugzilla/show_bug.cgi?id=128664 for details.



 Comments   
Comment by Nazrul [ 15/May/10 ]

->Jagadish

Comment by Jagadish [ 20/Sep/10 ]

This is not applicable for v3.x versions as the code-base is different.
Marking the target as 9.2 which may be the next release based on 9.x codebase.

Comment by Jagadish [ 23/Sep/10 ]

adding status whiteboard keyword

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-11679] Use OSGi defined mechanism for loading and using JDBC drivers Created: 14/Mar/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,679

 Description   

OSGi RFC#122 tries to standardize the way by which drivers (datasources) are
made available to OSGi applications via OSGi Service registry.
Currently GlassFish (which runs on OSGi) has its traditional way of detecting
JDBC drivers (drivers are made available in "lib" directories of GlassFish).

This behavior can be changed so that GlassFish can rely on OSGi to get installed
jdbc-drivers in the system and make use of them.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-14619] create-connector-security-map command does not update an existing map (or man page broke) Created: 11/Nov/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: v2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ryan O'Connell Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,619
Status Whiteboard:

3_1-exclude

Tags: 3_1-exclude

 Description   

See bug ID 14548 for background info.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=14548

There is another issue related to the issue above. It looks like the
update-connector-security-map command takes both the --addprincipals and
--addusergroups options. It should probably take one or the other but not both.

I'm sure this would have been discovered when fixing the
create-connector-security-map issue but just wanted to point it out.

I believe the --remove options are also an issue.






[GLASSFISH-14588] Should we expose _list-resources command? Created: 10/Nov/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nazrul Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,588

 Description   

[Tracking Bug]

This came up during a review at AS ARCH.

We have a hidden command called _list-resources. Should we make this public?

I am filing this bug to track this decision.



 Comments   
Comment by Jagadish [ 10/Nov/10 ]

IIRC, our initial proposal was to provide list-application-scoped-resources (or
list-resources) and the decision at AS-ARCH was not to introduce so many
commands, instead add a flag "--resources" for existing "list-applications"
commands. Please let me know whether there is any new input that necessitates
"list-resources" to be exposed.





[GLASSFISH-3272] Automatically detecting Lazy Connection Enlistment, Lazy Connection Association support by Resource adapters Created: 28/Jun/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,272

 Description   

GF V2 has lazy-connection-association & lazy-connection-enlistment features
enabled via connection pool properties.

These are optional properties according to Connector Specification.

According to JCA 1.5, application server can automatically (programatically)
detect whether a Resource adapter could make use of lazy-connection-enlistment,
association features. Refer JCA 1.5 specification 7.14.1.1 / 7.14.2.1



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-583] support autodeployment of sun-resource files Created: 18/Apr/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 583

 Description   

A JBoss user is able to register resources by taking a template data source
definition, filling in some blanks and putting it into a deployment directory.

They like this.

We could do something similar with files that conform to the sun-resource dtd,
placed in the autodeploy directory.

Related issue: https://glassfish.dev.java.net/issues/show_bug.cgi?id=582



 Comments   
Comment by Hong Zhang [ 08/Nov/07 ]

Downgrade to P4 as netbeans is not using sun-resources.xml mechanism anymore.
Assign to connector team who leads the sun-resources.xml effort. We will revisit
when necessary.

Comment by vince kraemer [ 08/Nov/07 ]

this has nothing to do with NetBeans, so the justification to lower the priority
is kind of bogus.

The feature request came from user feedback... just like issue 582.

Comment by Sivakumar Thyagarajan [ 26/Sep/08 ]

Transferring to Jagadish as he owns Connectors backend in v3

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-930] don't require DOCTYPE declaration in sun resources files used by add-resources Created: 14/Aug/06  Updated: 29/Feb/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1pe, 3.1.2_b23
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Cheng Fang Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 930

 Description   

asadmin add-resources <file> currently requires the sun resources file contain a
DTD declaration. Otherwise, it failed with this error:

Operation 'createResource' failed in 'resources' Config Mbean.
Target exception message: Document root element "resources", must match DOCTYPE
root "null".
CLI137 Command add-resources failed.

Users usually hand-edit sun resources files, so we could simplify it by not
requiring a DTD declaration. In JBoss, all such files (e.g.,
jboss.home/docs/examples/jca/mysql-ds.xml, etc) do not require any doctype.

In fact, if I supply a invalid system id url, asadmin add-resources still works.
So asadmin is not using the system id url supplied in sun resources file, which
is fine. The following DOCTYPE is accepted by asadmin

<!DOCTYPE resources PUBLIC "-//Sun Microsystems Inc.//DTD Application Server 9.0
Domain//EN"
"aaaaaaaa/Sun/AppServer/lib/dtds/sun-resources_1_2.dtd">

Xml validation for sun resources files adds little value. For resource
creation, asadmin also takes input from other non-xml source, so I suppose
asadmin already does programatically input validation. Why waste time on xml
parser validation?

asadmin help add-resources man page is not accurate:

An example XML file follows. Replace
<install_dir> with the location of
your Application Server installa-
tion.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources PUBLIC
"-//Sun Microsystems Inc.//DTD Application Server 9.0 Domain//EN"
"<install_dir>/lib/dtds/sun-resources_1_2.dtd">

The system id should not be a path; it should be a url. This results in sun
resources files not reusable across machines. I noticed another issue (439)
asking to use a http url, but why not just remove this DOCTYPE?



 Comments   
Comment by km105526 [ 31/Aug/06 ]

The way the entity resolution for the resources.xml works should be properly
documented. As of now, the way it works is:

  • resolve the xml against the sun-resources_x_y.dtd that is present with the app
    server installation. It does not even look at its predecessors. For app server
    9.0 for example, it would resolve against sun-resources_1_2.dtd.

I am not sure if we should relax the DOCTYPE requirement though. I agree however
that we should use the SystemID and PublicID appropriately as documented.

Comment by km105526 [ 31/Aug/06 ]

...

Comment by Tom Mueller [ 23/Jun/10 ]

Sreenivas no longer on project.

Comment by Tom Mueller [ 23/Jul/10 ]

Please evaluate whether this should be targeted for 3.1 or a future release. If
for a future release, please lower priority. If not applicable anymore, please
mark as resolved. - Thanks.

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared the Fix version since this issue isn't going to be fixed in 9.1pe





[GLASSFISH-4208] Admin GUI should tell user configuration exceptions Created: 16/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,208

 Description   

When configuring a .rar in the admin gui, it can happen that a setter method
throws an exception. Currently, the admin gui just ignores that. If the user
isn't clever enough to check the log preventively, he will never know that the
resource adapter actually is misconfigured.

It would be great for users to get some kind of unmistakeable hint that
exception X happened when setting property Y to the value Z.



 Comments   
Comment by Anissa Lam [ 16/Feb/08 ]

Backend doesn't thrown any exception but returns successfully, thats why gui
doesn't show any warning.
Transfer to 'jca', they need to throws an exception, with the exact cause.

Comment by Sivakumar Thyagarajan [ 20/Feb/08 ]

Requesting Jagadish to investigate and fix if required.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4043] Link a non-JMS MDB to a RAR automatically - ease of use Created: 28/Jan/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux
URL: http://www.nabble.com/forum/ViewPost.jtp?post=15107852&framed=y


Issuezilla Id: 4,043

 Description   

— ease of use request for enhancement —

As detailed in the discussions at
http://www.nabble.com/forum/ViewPost.jtp?post=15107852&framed=y, it would ease
deployment if GlassFish could automatically find out the resource adapter to
bind to for a non-JMS MDBs under certain common-case conditions.

If there is only one installed non-JMS RA that implements the message listener a
non-JMS MDB specifies, and if there is no sun-ejb-jar.xml bundled with the
archive to provide the resource-adapter-mid, it would be useful to auto-generate
a sun-ejb-jar.xml to point to the available non-JMS RA. This would help users
deploy a non-JMS MDB without any vendor specific deployment descriptors.

However if there are more than one non-JMS RAs that supports the non-JMS message
listener in question, the deployment should fail as expected.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-3912] Config. properties merge() action should warn the user when the property name differ by case Created: 12/Dec/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,912

 Description   

In Connectors runtime, there are many instances where config properties
specified in ra.xml will be merged with properties specified by user.

eg: resource-adapter-config, admin-object-resource, managed-connection-factory
config properties against ra.xml values.

When the property names specified in ra.xml and in domain.xml differ by "case"
(eg: databaseName & DatabaseName, in-correctly specified by the user) they are
considered as two different properties, but when set on a JavaBean (MCF/
ResourceAdapter) one will overwrite other. The order in which this will be
overwritten is unknown.

In these cases, it is necessary to log a WARNING message about this behaviour.



 Comments   
Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-15832] Executed app, then clicked Flush, got: class java.lang.RuntimeException Created: 04/Feb/11  Updated: 04/Feb/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: easarina Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File flush-pool.png     JPEG File ie8_bug1.jpg    

 Description   

Build 41 02/02. OEL machines. Created a cluster with three instances on three machines. Deployed to the cluster NileBookStore app and created correpondent oracle JDBC resources. Then executed this app. After that open correpondent JDBC Connection Pool (NilePool) and clicked Flush. Then after sometime I saw at screen:
class java.lang.RuntimeException (see attachment) and I saw such error messages in server.log:
=============================================

[#|2011-02-04T00:50:53.836-0800|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=308;_ThreadName=Thread-1;|java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event129'.

at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)

at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)

at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)

at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)

at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)

at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)

at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:244)

at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)

at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)

at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)

at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)

at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)

at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)

at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)

at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)

at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)

at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)

at com.sun.grizzly.ContextTask.run(ContextTask.java:71)

at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)

at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)

at java.lang.Thread.run(Thread.java:662)

Caused by: 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:597)

at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)

at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)

... 49 more

Caused by: java.lang.IllegalArgumentException: Path segment is null

at com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:493)

at com.sun.jersey.api.uri.UriBuilderImpl.segment(UriBuilderImpl.java:324)

at org.glassfish.admingui.common.util.RestUtil.appendEncodedSegment(RestUtil.java:365)

at org.glassfish.admingui.common.handlers.RestApiHandlers.encodeUrl(RestApiHandlers.java:371)

... 55 more

==========================================

Reproduced this issue three times.



 Comments   
Comment by Jason Lee [ 04/Feb/11 ]

Can you attach the app and give instructions on how exactly you configured the connection pool?

Comment by Anissa Lam [ 04/Feb/11 ]

easarina put the following comment in the wrong issue. She has that in GLASSFISH-15823 instead.
Here is the instruction she provides. you can download the app from GLASSFISH-15823.

$asadmin create-jdbc-connection-pool --datasourceclassname oracle.jdbc.pool.OracleDataSource --steadypoolsize 50 --maxpoolsize 150 --property user=doculabs:password=doculabs:url=jdbc\\:oracle\\:thin\\:@192.18.66.64\\:1521
:MININILE --target c1 NilePool

$asadmin create-jdbc-resource --connectionpoolid NilePool --target c1 jdbc/Nile

$asadmin set server-config.java-config.classpath_prefix="/export/ojdbc14.jar"

$asadmin set c1-config.java-config.classpath_prefix="/export/ojdbc14.jar"
$asadmin deploy --target c1 --availabilityenabled=true /export/NileBookStore.war

Also I've copied ojdbc14.jar in domains/domain1/lib/ext directories on all machines.

Comment by Jagadish [ 04/Feb/11 ]

1) I am not sure whether "classpath_prefix" is supported anymore.
2) flush/ping connection pool are executed on DAS and so there is no need for cluster setup to try to reproduce the issue.
3) Created the pool (modified steady pool and max pool to 2 and 8 respectively for faster response times) and resource in DAS
4) Deployed the app in DAS
5) accessed the app, added shopping items, did checkout.
6) access GUI, NilePool, press Flush connection pool.
Flush succeeded message was shown and did not see "RuntimeException" screen.

Comment by Jagadish [ 04/Feb/11 ]

flush pool success message console image attached

Comment by easarina [ 04/Feb/11 ]

Edit prefix is not a necessary action. Most important to copy ojdbc14.jar to each domain/domain1/lib/ext dir.

I've deployed NileBookStore to cluster. The cluster had three instances on three different machines

Comment by easarina [ 04/Feb/11 ]

I've installed today build 02/03 and can see a little bit different behavior. I've executed the app manually and also started stress test 300 simultaneous users against this installation. And then when I've clicked Flush, I saw Failed to flush connection pool NilePool due to Flush Connection Pool failed for NilePool. Please see server.log for more details..

I can not believe that 300 simultaneous users did not initialized the pool.

So I believe this message is wrong. My installation:

asqe-x2250-st5 DAS, in3
asqe-x2250-st6 in2
asqe-x2250-st7 in3

The installation under /export/glassfish3.
Instances port: 18080

Comment by Anissa Lam [ 04/Feb/11 ]

So, with the latest build, you see the error message, instead of the runtime exception on screen, is this correct ?

Comment by Anissa Lam [ 04/Feb/11 ]

The error comes from backend and GUI displays that correctly with latest build.
Transfer to 'jca'.

Comment by Jagadish [ 04/Feb/11 ]

Anissa :

Refer the other issue raised by Elena for "failure of flush-connection-pool"
http://java.net/jira/browse/GLASSFISH-15829 based on this issue.

Also, refer my evaluation above where I have stated that flush-connection-pool is applicable only on "DAS". It does not have a target.
So, if you have deployed the application only on clusters (not on DAS), then flush will not find any connections (pool is not initialized) in DAS and will fail which is the expected behavior.

Refer my other evaluation where I have tried the Nile book store in DAS and had attached the image showing flush connection pool successful as the resource (pool), application were deployed on DAS and was accessed using "localhost:8080/NileBookStore".

Transferring this back to Anissa for the original reason why the issue was raised, "RuntimeException" text shown in the console. If it is no more reproducible, please close the issue.

Comment by easarina [ 04/Feb/11 ]

create-jdbc-connection-pool also doesn't have a target option but it is applicable to all instances in a cluster. I believe the flush-connection-pool has to work for all instances in a cluster. Otherwise it doesn't make any sense.

Comment by Jagadish [ 04/Feb/11 ]

create-jdbc-connection-pool does not have an active target (its deprecated since 8.x).
It creates the pool in all instances in 3.1 for a different design (command replication) reason which is internal.
If you try 2.x, you will not see that create-jdbc-connection-pool creating the configuration in instances by default. Only when a jdbc-resource is created for the instance, pool configuration will be made available. In any case, these are unrelated for the current issue.

flush does not have target.
ping has target deprecated (no-op) since 8.x

Comment by easarina [ 04/Feb/11 ]

I just wanted to say doesn't matter, create-jdbc-connection-pool has target or not, it works for any instance in cluster. And flush also has to work for the clustered instances.

Comment by Jagadish [ 04/Feb/11 ]

That would be an RFE, please raise one.

Comment by Anissa Lam [ 04/Feb/11 ]

change to RFE according to the latest comment.

easarina : "I just wanted to say doesn't matter, create-jdbc-connection-pool has target or not, it works for any instance in cluster. And flush also has to work for the clustered instances."

Jagadish: "That would be an RFE, please raise one."





[GLASSFISH-16332] Allow ConnectorRuntime to return a ProbeProviderFactory Created: 10/Apr/11  Updated: 11/Apr/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: jsl123 Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 minute
Time Spent: Not Specified
Original Estimate: 1 minute


 Description   

The connector architecture doesn't (seem to) currently support injection, therefore if one wants to provide custom monitoring for a resource adapter, the only option seems to be to create an OSGI component instead of a WAR. The alternative to creating a OSGI component is to inject a org.glassfish.flashlight.provider.ProbeProviderFactory object and manually register the probe providers, however as injection isn't supported, this is impossible.

A simple solution would be to add the following to the com.sun.enterprise.connectors.ConnectorRuntime class

@Inject
private ProbeProviderFactory probeProviderFactory;

public ProbeProviderFactory getProbeProviderFactory(){
return probeProviderFactory;
}

this means that a jca component can simply call

ConnectorRuntime.getRuntime().getProbeProviderFactory().getProbeProvider(xxxx);

A similar mechanism seems to be in place in the EJB components which offer

ppf=EjbContainerUtilImpl.getInstance().getProbeProviderFactory();

Alternatively a mechanism for injecting this (and possibly other resources) directly would be much appreciated...

Thanks



 Comments   
Comment by Jagadish [ 11/Apr/11 ]

There is no support for resource injection in a resource-adapter artifact.

There are two options :
1) Similar to injection, we can look at making ProbeProviderFactory available via naming lookup.
2) As you have suggested, we can look at providing an API.
However, "EjbContainerUtil" is not a public API.
We can look at providing a public API from connector-runtime.

Comment by jsl123 [ 11/Apr/11 ]

I'm happy with either solution. I used ConnectorRuntime as it seemed fitting and as this isn't in the specs, wasn't too worried about it being glassfish only and not having a public api. Happy to test whatever is decided upon.

Thanks





[GLASSFISH-16051] XAStress Test fails with Glassfish / LOCAL MQ Created: 18/Feb/11  Updated: 14/Nov/11

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b43
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mathim Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish mq


Attachments: Text File broker.log     Text File broker_stacktrace.log     Text File glassfish_stacktrace.log     Text File server.log     Text File server.log    
Tags: 3_1-exclude, 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

XAStress test is an glassfish/mq integration stress test.

the test passes on glassfish/mq with MQ running as Embedded (default setup)

but running the test with glassfish and MQ as a LOCAL broker (non-default), the test failed after 72 hours (72 hours is the criteria for declaring the test pass)

But the problem can be consistently reproduced in a shorter timeframe by running the test on faster systems.

The problem
-----------

After running the XAStress for a day or two, glassfish server briefly becomes unresponsive to asadmin commands and hangs for about 10 - 15 minutes.

After this time, there are exceptions on the glassfish server.log and there is loss of a message in jms which causes the test to fail.

Listing the jms destination on the MQ broker shows the following.

-----------------------------------------------------------------------------------------------
Name Type State Producers Consumers Msgs
Total Wildcard Total Wildcard Count Remote UnAck Avg Size
-----------------------------------------------------------------------------------------------
MDB_XAT_TOPIC Topic RUNNING 0 0 1 0 1 0 1 260.0
mq.sys.dmq Queue RUNNING 0 - 0 - 0 0 0 0.0

Successfully listed destinations.



 Comments   
Comment by mathim [ 18/Feb/11 ]

Found the following exceptions on the glassfish server.

[#|2011-02-18T03:43:29.579-0800|WARNING|glassfish3.1|javax.resourceadapter.mqjmsra.inbound.message|_ThreadID=89;_ThreadName=Thread-1;|MQJMSRA_RA2001: Exception on stopMessageConsumer:Ignoring:
javax.resource.ResourceException: MQRA:EC:Error on closing MessageConsumer
at com.sun.messaging.jms.ra.EndpointConsumer.stopRemoteMessageConsumer(EndpointConsumer.java:661)
at com.sun.messaging.jms.ra.EndpointConsumer.stopMessageConsumer(EndpointConsumer.java:627)
at com.sun.messaging.jms.ra.ResourceAdapter.endpointDeactivation(ResourceAdapter.java:531)
at com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:339)
at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(MessageBeanContainer.java:912)
at com.sun.ejb.containers.MessageBeanContainer.cleanupResources(MessageBeanContainer.java:878)
at com.sun.ejb.containers.MessageBeanContainer.doConcreteContainerShutdown(MessageBeanContainer.java:948)
at com.sun.ejb.containers.BaseContainer.undeploy(BaseContainer.java:4200)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:309)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:314)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1023)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:333)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.sun.messaging.jms.JMSException: MQRA:OMRP:Didnot finish waiting for OMRs to return:null
at com.sun.messaging.jms.ra.OnMessageRunnerPool.waitForAllOnMessageRunners(OnMessageRunnerPool.java:229)
at com.sun.messaging.jms.ra.MessageListener.waitForAllOnMessageRunners(MessageListener.java:168)
at com.sun.messaging.jms.ra.EndpointConsumer.stopRemoteMessageConsumer(EndpointConsumer.java:647)
... 39 more
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.sun.messaging.jms.ra.OnMessageRunnerPool.waitForAllOnMessageRunners(OnMessageRunnerPool.java:226)
... 41 more

#]

[#|2011-02-18T03:43:29.588-0800|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=86;_ThreadName=Thread-1;|javax.resource.ResourceException: MQRA:EC:Error on closing MessageConsumer
at com.sun.messaging.jms.ra.EndpointConsumer.stopRemoteMessageConsumer(EndpointConsumer.java:661)
at com.sun.messaging.jms.ra.EndpointConsumer.stopMessageConsumer(EndpointConsumer.java:627)
at com.sun.messaging.jms.ra.ResourceAdapter.endpointDeactivation(ResourceAdapter.java:531)
at com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:339)
at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(MessageBeanContainer.java:912)
at com.sun.ejb.containers.MessageBeanContainer.cleanupResources(MessageBeanContainer.java:878)
at com.sun.ejb.containers.MessageBeanContainer.doConcreteContainerShutdown(MessageBeanContainer.java:948)
at com.sun.ejb.containers.BaseContainer.undeploy(BaseContainer.java:4200)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:309)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:314)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1023)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:333)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.sun.messaging.jms.JMSException: MQRA:OMRP:Didnot finish waiting for OMRs to return:null
at com.sun.messaging.jms.ra.OnMessageRunnerPool.waitForAllOnMessageRunners(OnMessageRunnerPool.java:229)
at com.sun.messaging.jms.ra.MessageListener.waitForAllOnMessageRunners(MessageListener.java:168)
at com.sun.messaging.jms.ra.EndpointConsumer.stopRemoteMessageConsumer(EndpointConsumer.java:647)
... 39 more
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.sun.messaging.jms.ra.OnMessageRunnerPool.waitForAllOnMessageRunners(OnMessageRunnerPool.java:226)
... 41 more

#]

[#|2011-02-18T03:43:29.589-0800|WARNING|glassfish3.1|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=86;_ThreadName=Thread-1;|[MDBContainer] Current thread done cleanup()... |#]

[#|2011-02-18T03:43:29.594-0800|INFO|glassfish3.1|javax.enterprise.system.container.appclient.org.glassfish.appclient.server.core|_ThreadID=86;_ThreadName=Thread-1;|ACDEPL104: Java Web Start services stopped for the app client XATStress/app-client-ic.jar|#]

[#|2011-02-18T03:43:29.627-0800|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=89;_ThreadName=Thread-1;|service exception
java.lang.RuntimeException: ClientAbortException: java.nio.channels.ClosedChannelException
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:256)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: ClientAbortException: java.nio.channels.ClosedChannelException
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:439)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:253)
... 17 more
Caused by: java.nio.channels.ClosedChannelException
at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:133)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:108)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:76)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:326)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:398)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:376)
at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1241)
at com.sun.grizzly.tcp.Response.action(Response.java:268)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:434)
... 20 more

#]
Comment by mathim [ 21/Feb/11 ]

attaching the log files and the stack trace for glassfish / mq broker

Comment by amyk [ 21/Feb/11 ]

The imqcmd output in the Description indicates the message had been delivered to client consumer and the broker was waiting for ack.

Comment by Chris Kasso [ 21/Feb/11 ]

Issue excluded, submitted after cutoff.

Comment by Nigel Deakin [ 22/Feb/11 ]

This test case involves an app client that writes messages to a topic, and two MDBs (1 CMT, 1 BMT) that consume these messages (unpon receiving a message, sending a reply to a reply queue and a reply topic respectively, then if on even message count or JMSRedelivered true , commit, else rollback the transaction). The app client then receives the reply messages. If the app client doesn't receive the expected messages within a timeout period the test script undeploys the application.

The above exception occurred when the application was undeployed. It shows that one or more MDB threads were blocked, thereby preventing application shutdown.

The thread dumps were logged after this point, and didn't show anything significant.

To find the root cause of this problem we need thread dumps before the application is undeployed. This might explain why the MDBs stopped processing messages and why the undeploy failed.

We are re-running these tests now to obtained the required information.

Comment by mathim [ 22/Feb/11 ]

attach server log with more lines

Comment by amyk [ 22/Feb/11 ]

The attached server log (the one with more lines) shows following exception on JMSRA delivering a message to MDB.

[#|2011-02-16T15:54:36.762-0800|INFO|glassfish3.1|javax.resourceadapter.mqjmsra.inbound.message|_ThreadID=85;_ThreadName=Thread-1;|MQJMSRA_MR1101: onMessage:WorkException-error code: 1 on omrId=29
javax.resource.spi.work.WorkRejectedException: error code: 1
at com.sun.enterprise.connectors.work.WorkCoordinator.workTimedOut(WorkCoordinator.java:278)
at com.sun.enterprise.connectors.work.WorkCoordinator.lock(WorkCoordinator.java:365)
at com.sun.enterprise.connectors.work.CommonWorkManager.startWork(CommonWorkManager.java:278)
at com.sun.enterprise.connectors.work.CommonWorkManager.startWork(CommonWorkManager.java:247)
at com.sun.enterprise.connectors.work.WorkManagerProxy.startWork(WorkManagerProxy.java:90)
at com.sun.messaging.jms.ra.OnMessageRunner.onMessage(OnMessageRunner.java:384)
at com.sun.messaging.jms.ra.MessageListener.onMessage(MessageListener.java:216)
at com.sun.messaging.jmq.jmsclient.MessageConsumerImpl.deliverAndAcknowledge(MessageConsumerImpl.java:358)
at com.sun.messaging.jmq.jmsclient.MessageConsumerImpl.onMessage(MessageConsumerImpl.java:287)
at com.sun.messaging.jmq.jmsclient.SessionReader.deliver(SessionReader.java:119)
at com.sun.messaging.jmq.jmsclient.ConsumerReader.run(ConsumerReader.java:192)
at java.lang.Thread.run(Thread.java:662)

#]
Comment by Nigel Deakin [ 03/Mar/11 ]

The javax.resource.spi.work.WorkRejectedException: error code: 1 is a timeout, which shouldn't happen in a call to Workmanager.startWork with no timeout.

Reassigning to Jagadish to investigate further.





[GLASSFISH-17188] MDB calls to setRollbackOnly without a XAResource given to the MessageEndpoint does no more thow a Exception Created: 11/Aug/11  Updated: 28/Nov/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: juergenschmied Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 3.1 with java 1.6.0_26-b03 on windows


Tags: 3_1_2-exclude, JCA, MDB, MessageDrivenContext, RA, setRollbackOnly

 Description   

Szenario:
1.) isDeliveryTransacted of the used endpoint is true (checked)
2.) RA calls MessageEndpointFactory.createEndpoint with xaResource = null
3.) RA calls the endpoint method
4.) MDB gets the Message and calls setRollbackOnly() on the injected MessageDrivenContext
5.) the endpoint method returns without a exception (This is the Bug !)

In Version 3.0.1 a Exception was throw in step (5) to inform the RA of the failed transaction. I could do a rollback in a simple exception handler.

in Version 3.1 no Exception is thrown. The RA is not informed of the failed transaction.

If I give a XA Resource to createEndpoint the rollback method on the XAResource is called so the setRollbackOnly() is processed by the AS orderly.



 Comments   
Comment by Jagadish [ 14/Nov/11 ]

Can you provide a sample application with RAR to reproduce the issue ?





[GLASSFISH-17142] ClassLoader / memory leak in ConnectorTimerProxy Created: 01/Aug/11  Updated: 14/Nov/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rwruck Assignee: Jagadish
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude

 Description   

The ConnectorTimerProxy is used to lazily initialize a Timer object. There once was an issue where usage of this proxy caused the proxied timer thread to be bound to the WebApp's ClassLoader, thus preventing it from being discarded when undeploying the application (see GLASSFISH-7074).

Unfortunately, there is another way to create a memory leak: ConnectorTimerProxy extends java.util.Timer and thus it has a TimerThread of its own that's never used since all methods delegate to the proxy timer.
BUT this means that the very first call to getProxy() will create a TimerThread that inherits the calling thread's context class loader and it seems I just came across this case.

jhat says:

Static reference from com.sun.enterprise.connectors.util.ConnectorTimerProxy.connectorTimer
(from class com.sun.enterprise.connectors.util.ConnectorTimerProxy) :
--> com.sun.enterprise.connectors.util.ConnectorTimerProxy@0x9c036b8 (28 bytes) (field thread:)
--> java.util.TimerThread@0x9bf1e58 (113 bytes) (field contextClassLoader:)
--> org.glassfish.web.loader.WebappClassLoader@0x97d9630 (164 bytes) 

Since the ConnectorTimerProxy's own TimerThread is not used at all, I'd suggest to add a call to super.cancel() in the constructor.



 Comments   
Comment by Hong Zhang [ 02/Aug/11 ]

assign to jagadish for evaluation

Comment by rwruck [ 02/Aug/11 ]

Update: While it may be a good idea to stop the unneccesary timer thread, it does not solve the issue, because the TimerThread object which holds the reference to the WebApp's ClassLoader is not set to null in the JDK's cancel() implementation.
A patched glassfish where the getProxy() method uses the same workaround as the getTimer() method, i.e. use the ConnectorClassLoader for creating the ConnectorTimerProxy instance itself, does not expose the described issue anymore.

Comment by rwruck [ 02/Aug/11 ]

Update 2: It seems that the current workaround is not enough to eliminate references to the WebApp ClassLoader. While the contextClassLoader of the timer threads is now set to the connectorClassLoader, they still inherit the caller thread's AccessControlContext - which in turn refers to the thread's ClassLoader.

jhat says:

Static reference from com.sun.enterprise.connectors.util.ConnectorTimerProxy.connectorTimer
(from class com.sun.enterprise.connectors.util.ConnectorTimerProxy) :
--> com.sun.enterprise.connectors.util.ConnectorTimerProxy@0x9b66f00 (32 bytes) (field timer:)
--> java.util.Timer@0x9b746e0 (20 bytes) (field thread:)
--> java.util.TimerThread@0x9b55748 (113 bytes) (field inheritedAccessControlContext:)
--> java.security.AccessControlContext@0x9b72308 (21 bytes) (field context:)
--> [Ljava.security.ProtectionDomain;@0x9b7c358 (80 bytes) (Element 6 of [Ljava.security.ProtectionDomain;@0x9b7c358:)
--> java.security.ProtectionDomain@0x983e028 (30 bytes) (field classloader:)
--> org.glassfish.web.loader.WebappClassLoader@0x9762c30 (164 bytes)

I don't know of any way to specify a newly created thread's AccessControlContext - in fact, being able to do so would break the whole security model.

Maybe I'm missing something but to me it seems that the ConnectorTimerProxy should NEVER be used by a thread whose AccessControlContext might refer to a WebApp's ProtectionDomain - or at least getProxy() and getTimer() need to be called once before any WebApp has a chance to do so. That would reduce the problem to cases where handleTimerException is involved.





[GLASSFISH-16750] IllegalArgumentException when JDBC statement leak detection is enabled for an app-scoped JDBC connection pool Created: 27/May/11  Updated: 02/Aug/11

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: arungupta Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File MessageFormatTest.java    
Tags: 3_1_1-next, 3_1_1-scrubbed

 Description   

An app-scoped JDBC connection pool with the following parameters:

connection-leak-timeout-in-seconds="10"
statement-leak-timeout-in-seconds="2"
statement-timeout-in-seconds="6"

should enable JDBC statement leak detection. But it throws the following error in the console:

WARNING: RAR8012: Exception while scheduling timer : Timer already cancelled.
INFO: Recreating Timer and scheduling at fixed rate
SEVERE: Exception in thread "connector-timer-proxy"
SEVERE: java.lang.IllegalArgumentException: can't parse argument number PoolInfo : (name=java:app/myConnectionPool)
at java.text.MessageFormat.makeFormat(MessageFormat.java:1339)
at java.text.MessageFormat.applyPattern(MessageFormat.java:458)
at java.text.MessageFormat.<init>(MessageFormat.java:350)
at com.sun.enterprise.util.i18n.StringManagerBase.getStringWithDefault(StringManagerBase.java:206)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.printConnectionLeakTrace(ConnectionLeakDetector.java:177)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.potentialConnectionLeakFound(ConnectionLeakDetector.java:157)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.access$000(ConnectionLeakDetector.java:60)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector$ConnectionLeakTask.run(ConnectionLeakDetector.java:222)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

The same parameters work fine if these parameters are used on the pre-created JDBC connection pool of jdbc/__default.



 Comments   
Comment by Jagadish [ 27/May/11 ]

Root cause seems to be due to StringManager not able to handle the string that has "

{" / "}

" in the text.

eg: PoolInfo/ResourceInfo's toString will be of the form :

{ PoolInfo : (name=MY_POOL), (applicationName=MY_APP), (moduleName=MY_MODULE)}

which when used with "LocalStrings.getStringsWithDefault" results in the reported exception.

There should be a way to escape these characters so that they do not affect LocalStrings functionality.

Transferring to Naman for comments.
If there are escape characters that could be used, please transfer the issue to me with a sample.

Comment by naman_mehta [ 02/Aug/11 ]

Attaching test java class for message formatting where string has { } this kind of content...

Comment by naman_mehta [ 02/Aug/11 ]

Assigning to Jagadish for verification and fix the same...





[GLASSFISH-16240] Support DeleteResources(sun-resources-xml) AdminCommand Created: 21/Mar/11  Updated: 24/Mar/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Aslak Knutsen Assignee: Jagadish
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The AddResources(sun-resources-xml) is excellent for adding a set of resources, but the API is missing a equal command to reverse the process, (Delete|Purge|Remove)Resources(sun-resources-xml) is no where to be found.

The 'workaround' in the current API seems to be to read the sun-resources-xml file in question and run the individual delete resource commands, e.g. DeleteJDBCResource, DeleteJMSResource.

A DeleteResources(sun-resources-xml) command that would reverse a AddResources(sun-resources-xml) command would be helpful.






[GLASSFISH-20943] Ejbca hangs with SJAS 9.1_02 Created: 30/Dec/13  Updated: 30/Dec/13

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vaibhav_shriv Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We have ejbca(v 4.0.6) based PKI deployed in our environment. We observed deadlock in jstack logs.

We suspect that the issue could be same as bug : https://java.net/jira/browse/GLASSFISH-3960
We are using Sun Application Server 9.1 Update 2. Is the fix for above bug has included in 9.1 Update 2 version of Sun application server.

Deadlock snippet:
=========================================
Thread "Finalizer" thread-id 3 thread-stateWAITINGWaiting on lock: java.lang.ref.ReferenceQueue$Lock@1738249
at: java.lang.Object.wait(Native Method)
at: java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
at: java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at: java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

Thread "Reference Handler" thread-id 2 thread-stateWAITINGWaiting on lock: java.lang.ref.Reference$Lock@6e9be1
at: java.lang.Object.wait(Native Method)
at: java.lang.Object.wait(Object.java:485)
at: java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)

Following thread(s) were deadlocked:
Thread "p: thread-pool-1; w: 200" thread-id 3,375 thread-stateBLOCKEDWaiting on lock: com.sun.enterprise.resource.SJSASResourcePool@1bf849a
Owned by: p: thread-pool-1; w: 121 Id: 2,113

Thread "p: thread-pool-1; w: 121" thread-id 2,113 thread-stateBLOCKEDWaiting on lock: com.mysql.jdbc.JDBC4PreparedStatement@511ec7
Owned by: p: thread-pool-1; w: 57 Id: 2,035

Thread "p: thread-pool-1; w: 57" thread-id 2,035 thread-stateBLOCKEDWaiting on lock: com.mysql.jdbc.JDBC4Connection@9abe3c
Owned by: p: thread-pool-1; w: 121 Id: 2,113
=======================================






[GLASSFISH-20770] Handle cases where "user" is not set in subject while persisting job information Created: 20/Aug/13  Updated: 21/Aug/13

Status: Open
Project: glassfish
Component/s: failover
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Jagadish [ 21/Aug/13 ]

FIX INFORMATION :

svn log -v -r 62575
------------------------------------------------------------------------
r62575 | jr158900 | 2013-08-20 21:59:17 +0530 (Tue, 20 Aug 2013) | 5 lines
Changed paths:
M /trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/AdminCommandInstanceImpl.java

GLASSFISH-20770 : Handle cases where "user" is not set in subject while persisting job information
Reviewed by : Martin
Tests Passed : QL (all profiles)





[GLASSFISH-20723] deploy jpa app failed Created: 25/Jul/13  Updated: 04/Jun/14

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lzg5039 Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Tags: 4_0_1-reviewed

 Description   

following steps are excuted,the bug would happen
1. create-cluster ijserver1
2. create-local-instance --cluster ijserver1 ij1inst1
3. start-instance ij1inst1
4. create-jdbc-resource --target ijserver1 --connectionpoolid pool jdbc/jpaused
5. create-local-instance --cluster ijserver1 ij1inst2
6. deploy --target ijserver1 c:\JPAAPP.jar
JPAAPP needs to meet the following 2 conditions
(1)contains <jta-data-source>jdbc/jpaused</jta-data-source>.
(2)contains @PersistenceContext(unitName = "pu1")
EntityManager em;

when excute step 6,exception will happen.The following exception will be printted out in server.log of DAS .

[#|2013-05-30T09:13:59.717+0900|INFO|||_ThreadID=65;_ThreadName=admin-thread-pool-12011(5);|RAR8029: Resource [ jdbc/carshop ] of type [ jdbc ] is not enabled|#]

[#|2013-05-30T09:13:59.717+0900|INFO|||_ThreadID=65;_ThreadName=admin-thread-pool-12011(5);|RAR8029: Resource [ jdbc/carshop ] of type [ jdbc ] is not enabled|#]

[#|2013-05-30T09:13:59.719+0900|SEVERE|||_ThreadID=65;_ThreadName=admin-thread-pool-12011(5);|Exception while preparing the app|#]

[#|2013-05-30T09:13:59.719+0900|SEVERE|||_ThreadID=65;_ThreadName=admin-thread-pool-12011(5);|java.lang.StackOverflowError
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4615)
at java.util.regex.Pattern$CharProperty.match(Pattern.java:3694)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
at java.util.regex.Pattern$Behind.match(Pattern.java:5036)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
at java.util.regex.Pattern$Start.match(Pattern.java:3408)
at java.util.regex.Matcher.search(Matcher.java:1199)
at java.util.regex.Matcher.find(Matcher.java:592)
at java.util.regex.Pattern.split(Pattern.java:1200)
at java.util.regex.Pattern.split(Pattern.java:1259)
at org.jvnet.hk2.config.ConfigModel.camelCaseToXML(ConfigModel.java:313)
at org.jvnet.hk2.config.ConfigModel.toProperty(ConfigModel.java:303)
at org.jvnet.hk2.config.Dom.invoke(Dom.java:915)
at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
at $Proxy14.getResourceRef(Unknown Source)
at com.sun.enterprise.config.serverbeans.Server$Duck.getResourceRef(Server.java:372)
at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:959)
at org.jvnet.hk2.config.Dom.invoke(Dom.java:912)
at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
at $Proxy14.getResourceRef(Unknown Source)
at com.sun.enterprise.connectors.util.ResourcesUtil.isResourceReferenceEnabled(ResourcesUtil.java:892)
at com.sun.enterprise.connectors.util.ResourcesUtil.isEnabled(ResourcesUtil.java:725)
at com.sun.enterprise.resource.deployer.JdbcResourceDeployer.deployResource(JdbcResourceDeployer.java:105)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:90)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)

#]


 Comments   
Comment by Hong Zhang [ 25/Jul/13 ]

assign to connector team for initial evaluation based on the stack trace

Comment by Ron Peng [ 26/Jul/13 ]

I find that when excute [create-local-instance], the jdbc resource [jdbc/jpaused] is binded to the JNDI Context of DAS.

In additon, ResourceProxy.create() also have a problem. Sometimes, due to isEnabled is false, deployResource() just print a INFO message, but lookup() always excuted.

Maybe this is the reason of the problem.

Comment by lzg5039 [ 19/Aug/13 ]

When execute step 5,cluster's jdbc resource is binded to jndi context of Das.And it is saved in map.
Key:jdbc resource name
Value:ResourceProxy Object
When deploy JPA app, Das will look up jdbc resource on its own jndi context firstly.At this time the following steps will be executed.
1.executes lookup method,then gets ResourceProxy Object by jdbc resource name.
2.creates real resource,then replaces ResourceProxy Object with the real resource.
3.executes lookup method,then gets real resource which is created by step 2.
Because there is no resource-ref in Das,so real resource can not be created in step 2.The obect which is getted by step 3 is still ResourceProxy Object,so afer step 3 is executed ,the step 2 will be executed.Then dead loop will happen.

Comment by lzg5039 [ 11/Dec/13 ]

Hi Jagadish
Could you help me,and give me some advices.
thanks.





[GLASSFISH-21208] nonXA resource not resused when in a transaction Created: 19/Sep/14  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gfuser Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

when in a transaction if there are multiple calls to getConnection on the same Shareable Resource, you get a different connection everytime. This leads to connection leak.



 Comments   
Comment by gfuser [ 19/Sep/14 ]

This issue has been reported several times in previous version also, but never got answered by the developer.
Fix seems to be pretty simple, but seems to have been not fixed for a while. It is easily reproducible.
If you define the same data source as XA and run the same test, GF seems to work fine with Single phase commit.

Please comment on the issue, indicating is it working as designed ? or will it be addressed?





[GLASSFISH-21082] For GlassFish standalone client without ACC: ConnectionManagerImpl.internalGetConnection(...) doesn't use the username of ConnectionRequestInfo Created: 09/Jun/14  Updated: 19/Jun/14

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Zhao Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-18715 Cannot deny user(s) from producing me... Open
Duplicate
is duplicated by MQ-307 username/password parameters in Conne... Closed

 Description   

The method takes cxRequestInfo as a parameter, but it doesn't use its username for authorization, but always use prin instead.

    protected Object internalGetConnection(ManagedConnectionFactory mcf,
                                           final ResourcePrincipal prin, ConnectionRequestInfo cxRequestInfo,
                                           boolean shareable, String jndiNameToUse, Object conn, boolean isUnknownAuth)
            throws ResourceException {

            ...

            } else {
                if (prin == null) {   // should it test cxRequestInfo == null instead?
                    info = new ClientSecurityInfo(cxRequestInfo);
                } else {
                    info = new ClientSecurityInfo(prin);
                    if (prin.equals(defaultPrin)) {
                        subject = pmd.getSubject();
                    } else {
                        subject = ConnectionPoolObjectsUtils.createSubject(mcf, prin);
                    }
                }
            }


 Comments   
Comment by David Zhao [ 09/Jun/14 ]

Here is a test case of JMS resource adaptor,

Use a standalone GF server with JMS Service of EMBEDDED or LOCAL.
Add a new imq user "imqusermgr add -u myuser -p mypass -g user". This imq cmd can be found under mq/bin.
In imq's accesscontrol.properties, add a line "connection.NORMAL.deny.user=guest" to deny guest for getting connection. The properties file can be found under imqbroker's configuration folder like "glassfish4\glassfish\domains\domain1\imq\instances\imqbroker\etc".
Start GF domain
Create JMS connection factory "asadmin create-jms-resource --target server --restype javax.jms.QueueConnectionFactory jms/myFactory ".
Create a JavaSE JMS client application,

Properties jndiProps = new Properties();
jndiProps.put("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory");
jndiProps.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
jndiProps.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
jndiProps.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");
jndiProps.setProperty("org.omg.CORBA.ORBInitialPort", "3700");

ctx = new InitialContext(jndiProps);
qconFactory = (ConnectionFactory) ctx.lookup("jms/myFactory");

Connection qcon = qconFactory.createConnection("myuser", "mypass");
System.out.println(qcon);

Run the client application which is remotely to GF server (not in appclient container), then you will get the following security exception that shows the user being authenticated is guest instead of expected myuser which we specified in ConnectionFactory.createConnection(String username, String password) API.

SEVERE: MQJMSRA_MC4001: constructor:Aborting:JMSException on createConnection=[C4084]: User authentication failed: user=guest, broker=localhost:7676(58859), error code: C4084
com.sun.messaging.jms.JMSSecurityException: [C4084]: User authentication failed: user=guest, broker=localhost:7676(58859)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.authenticate(ProtocolHandler.java:1124)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.hello(ProtocolHandler.java:1041)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.hello(ProtocolHandler.java:932)

Comment by dhaneesh.t.b [ 18/Jun/14 ]

I did a comparison of this with the existing JDBC behaviour .
try

{ InitialContext ctx = new InitialContext(jndiProps); DataSource ds = (DataSource) ctx.lookup("jdbc/pgrs"); Connection connection = ds.getConnection("test","test123"); System.out.println("Created Connection"); }

catch (Exception e)

{ e.printStackTrace(); }

The same scenario is working in case of JDBC and not working for JMS.
The code flow is almost till the function invocation of createManagedConnection() on ManagedConnectionFactory implementation object as below.
ManagedConnection mc =
mcf.createManagedConnection(subject, reqInfo);

In case of JMS the ManagedConnectionFactory implementation is is com.sun.messaging.jms.ra.ManagedConnectionFactory where as for JDBC it is com.sun.gjc.spi.CPManagedConnectionFactory.

So the logic of using the credential from the default principal object or cxRequest info is been implemented inside the appropriate ManagedConnectionFactory implementation.

Here is the implementation of JDBC com.sun.gjc.spi.CPManagedConnectionFactory.createManagedConnection

public javax.resource.spi.ManagedConnection createManagedConnection(javax.security.auth.Subject subject, ConnectionRequestInfo cxRequestInfo) throws ResourceException {
PasswordCredential pc = SecurityUtils.getPasswordCredential(this, subject, cxRequestInfo);
.
.
.
if (isEqual(pc, getUser(), getPassword()))

{ cpConn = dataSource.getPooledConnection(); }

else

{ cpConn = dataSource.getPooledConnection(pc.getUserName(), new String(pc.getPassword())); }

.
.
.

SecurityUtils.getPasswordCredential invocation creates the PasswordCredential object considering the cxRequestInfo object which contains user provided userName/password.

Here is the code snippet of getPasswordCredential() implementation for JDBC.
public static PasswordCredential getPasswordCredential(final ManagedConnectionFactory mcf, final Subject subject, javax.resource.spi.ConnectionRequestInfo info) throws ResourceException {
if (info == null)

{ . . . }

else

{ ConnectionRequestInfoImpl cxReqInfo = (ConnectionRequestInfoImpl) info; PasswordCredential pc = new PasswordCredential(cxReqInfo.getUser(), cxReqInfo.getPassword().toCharArray()); pc.setManagedConnectionFactory(mcf); return pc; }

}

In case of JMS ManagedConnection object creation, the cxRequestInfo is ignored if the subject is a non null object.

Below is the code snippent.
static public PasswordCredential
getPasswordCredential(
final com.sun.messaging.jms.ra.ManagedConnectionFactory mcf,
final Subject subject,
com.sun.messaging.jms.ra.ConnectionRequestInfo myinfo)
throws javax.resource.ResourceException
{
String username2use = null;
String password2use = null;

PasswordCredential pc = null;

//System.out.println("MQRA:U:getPC()-subject="subject":CRInfo="+myinfo);
if (subject != null)

{ . . . }

if (pc != null)

{ return pc; }

else {
if (myinfo != null) {
if (myinfo.getUserName() != null)

{ //System.out.println("MQRA:U:getPC():non-null CRI:creating pwc from CRI"); username2use = myinfo.getUserName(); password2use = myinfo.getPassword(); }

else {
.
.
.

Comment by amyk [ 19/Jun/14 ]

>In case of JMS ManagedConnection object creation, the cxRequestInfo is ignored if the subject is a non null object.

Hi Jagadish, Connector 1.7 specification 9.1.8.2 Contract for Resource Adapter:

"Option A. The resource adapter explicitly checks whether the passed Subject instance carries a PasswordCredential instance .. If the Subject instance contains a PasswordCredential instance, the resource adapter extracts the username and password from the PasswordCredential. It uses the security information to authenticate the resource principal, .."





[GLASSFISH-21075] Wrong or missing class in Connection Pool "connection-definition-name" attribute does not cause an Error, but Glassfish then chooses the ConnectionFactory randomly Created: 27/May/14  Updated: 27/May/14

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dl_7p Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: configuration, connectionpool, jca, resource-adapter

 Description   

When the connection pool for a resource adapter is misconfigured in the domain.xml such that the connection-definition-name attribute points to a missing class, or to a class that does not implement ConnectionFactory, glassfish seems to randomly (or at least non-deterministically) pick a class implementing ConnectionFactory from the resource adapter.
This is fine as long as the RA only has one ConnectionFactory implementation, but for adapters with multiple connection factories and ConnectionDefinition annotations this can lead to an InjectionException at a later point, when an EJB tries to get a factory instance via @Resource and the AS tries to supply an instance of the wrong type.

I would expect glassfish to treat a connection-definition-name value that does not point to an existing class which implements ConnectionFactory as an error, and not create the connection pool. An appropriate message should appear in the server.log and should tell the user if the class is missing or if it does not implement the required interface.






[GLASSFISH-21051] ConnectionPoolEmitterImpl is not thread safe. Misuse of HashMap (resourceAppAssociationMap) Created: 25/Apr/14  Updated: 03/Jun/14

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: syangjava Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours
Environment:

REDHAT Linux 6


Tags: 4_0_1-reviewed

 Description   

We configured max thread pool size to be 150 in glassfish 3.1.2.2. We noticed most thread were blocked after a while, and there was an exception like this: 'java.util.concurrent.RejectedExecutionException: The thread pool's task queue is full, limit: 4096'. We did thread dump analysis and heapdump analysis. There were a couple of threads in runnable state with stacktrace like this:

(first thread)
"connector-timer-proxy" daemon prio=5 tid=69 RUNNABLE
at java.util.HashMap.removeEntryForKey(HashMap.java:569)
Local Variable: java.util.HashMap$Entry#3068822
Local Variable: java.util.HashMap$Entry#2436928
at java.util.HashMap.remove(HashMap.java:538)
Local Variable: java.util.HashMap#166939
Local Variable: java.lang.Long#267315
at com.sun.enterprise.resource.pool.monitor.ConnectionPoolEmitterImpl.connectionDestroyed(ConnectionPoolEmitterImpl.java:184)
Local Variable: com.sun.enterprise.resource.pool.monitor.ConnectionPoolEmitterImpl#1
at com.sun.enterprise.resource.pool.PoolLifeCycleListenerRegistry.connectionDestroyed(PoolLifeCycleListenerRegistry.java:151)
Local Variable: java.util.AbstractList$Itr#106505
at com.sun.enterprise.resource.pool.ConnectionPool.deleteResource(ConnectionPool.java:974)
at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.removeResource(RWLockDataStructure.java:153)
Local Variable: com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure#1
at com.sun.enterprise.resource.pool.ConnectionPool.reclaimConnection(ConnectionPool.java:1643)
Local Variable: java.lang.String#1077104
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.potentialConnectionLeakFound(ConnectionLeakDetector.java:161)
Local Variable: java.lang.StackTraceElement[]#2777
Local Variable: com.sun.enterprise.resource.pool.ConnectionPool#1
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.access$000(ConnectionLeakDetector.java:60)
Local Variable: com.sun.enterprise.resource.ResourceHandle#88
Local Variable: com.sun.enterprise.resource.pool.ConnectionLeakDetector#1
at com.sun.enterprise.resource.pool.ConnectionLeakDetector$ConnectionLeakTask.run(ConnectionLeakDetector.java:222)
Local Variable: com.sun.enterprise.resource.pool.ConnectionLeakDetector$ConnectionLeakTask#1
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

(second thread)
"http-thread-pool-8009(56)" daemon prio=5 tid=296 RUNNABLE
at java.util.HashMap.transfer(HashMap.java:484)
Local Variable: java.util.HashMap$Entry#3402865
at java.util.HashMap.resize(HashMap.java:463)
Local Variable: java.util.HashMap$Entry[]#800390
at java.util.HashMap.addEntry(HashMap.java:755)
at java.util.HashMap.put(HashMap.java:385)
at com.sun.enterprise.resource.pool.monitor.ConnectionPoolEmitterImpl.getAppName(ConnectionPoolEmitterImpl.java:320)
at com.sun.enterprise.resource.pool.monitor.ConnectionPoolEmitterImpl.connectionUsed(ConnectionPoolEmitterImpl.java:234)
at com.sun.enterprise.resource.pool.PoolLifeCycleListenerRegistry.connectionUsed(PoolLifeCycleListenerRegistry.java:145)
Local Variable: java.util.AbstractList$Itr#106556
at com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:532)
Local Variable: com.sun.enterprise.resource.ResourceHandle#377
at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
Local Variable: com.sun.enterprise.resource.allocator.LocalTxConnectorAllocator#166
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:245)
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:170)
Local Variable: com.sun.enterprise.resource.ResourceSpec#504
at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:338)
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:301)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:190)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:160)
at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:113)

(third thread)
"http-thread-pool-8009(138)" daemon prio=5 tid=378 RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
Local Variable: java.lang.Long#267316
at com.sun.enterprise.resource.pool.monitor.ConnectionPoolEmitterImpl.getAppName(ConnectionPoolEmitterImpl.java:313)
at com.sun.enterprise.resource.pool.monitor.ConnectionPoolEmitterImpl.connectionUsed(ConnectionPoolEmitterImpl.java:234)
at com.sun.enterprise.resource.pool.PoolLifeCycleListenerRegistry.connectionUsed(PoolLifeCycleListenerRegistry.java:145)
Local Variable: java.util.AbstractList$Itr#106506
at com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:532)
at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
Local Variable: com.sun.enterprise.resource.allocator.LocalTxConnectorAllocator#79
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:245)
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:170)
Local Variable: com.sun.enterprise.resource.ResourceSpec#96
at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:338)
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:301)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:190)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:160)
at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:113)

(fourth thread)
"http-thread-pool-8009(11)" daemon prio=5 tid=251 RUNNABLE
at java.util.HashMap.transfer(HashMap.java:484)
Local Variable: java.util.HashMap$Entry[]#943178
Local Variable: java.util.HashMap$Entry#3075959
at java.util.HashMap.resize(HashMap.java:463)
Local Variable: java.util.HashMap$Entry[]#1092899
at java.util.HashMap.addEntry(HashMap.java:755)
at java.util.HashMap.put(HashMap.java:385)
at com.sun.enterprise.resource.pool.monitor.ConnectionPoolEmitterImpl.getAppName(ConnectionPoolEmitterImpl.java:320)
Local Variable: java.lang.String#1256767
at com.sun.enterprise.resource.pool.monitor.ConnectionPoolEmitterImpl.connectionUsed(ConnectionPoolEmitterImpl.java:234)
at com.sun.enterprise.resource.pool.PoolLifeCycleListenerRegistry.connectionUsed(PoolLifeCycleListenerRegistry.java:145)
Local Variable: java.util.AbstractList$Itr#106557
at com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:532)
Local Variable: com.sun.enterprise.resource.ResourceHandle#351
at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
Local Variable: com.sun.enterprise.resource.allocator.LocalTxConnectorAllocator#165
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:245)
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:170)
Local Variable: com.sun.enterprise.resource.ResourceSpec#503
at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:338)
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:301)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:190)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:160)
at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:113)

The CPU usage was way higher than normal. And all blocked threads were blocked on the same java lock and the same line of code. The following is an example.

"http-thread-pool-8009(96)" daemon prio=5 tid=336 BLOCKED
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.startConnectionLeakTracing(ConnectionLeakDetector.java:113)
at com.sun.enterprise.resource.pool.ConnectionPool.setResourceStateToBusy(ConnectionPool.java:324)

Basically all 3 threads were running in infinite loop. The cause was the misuse of a HashMap object (resourceAppAssociationMap) in a concurrent environment in ConnectionPoolEmitterImpl. This is a related article.
http://mailinator.blogspot.com/2009/06/beautiful-race-condition.html

The fix actually should be quite easy. Just use ConcurrentHashMap instead of HashMap for resourceAppAssociationMap.

Can we get a patch soon on this?



 Comments   
Comment by reza_rahman [ 25/Apr/14 ]

Note that this is now under review for 4.0.1

Comment by syangjava [ 25/Apr/14 ]

So there is no plan to have a release after 3.1.2.2?

Is there a way we can get a patch?

Comment by reza_rahman [ 25/Apr/14 ]

Not sure if it will be back-ported. The only way to get an individual patch is through GlassFish 3 commercial support if you have purchased it.

Comment by Jagadish [ 26/Apr/14 ]

Same as issue :
https://java.net/jira/browse/GLASSFISH-19190

Comment by syangjava [ 28/Apr/14 ]

So this problem was known in the '3.1.2_b14' release and never fixed? Is there any plan to make another glassfish 3 release soon, for example, 3.1.2.3 with this fix?

Comment by reza_rahman [ 28/Apr/14 ]

As you may be aware, we are currently very focused on GlassFish 4.0.1. Although a further GlassFish 3 release may happen, it's not currently in planning that I know of. If this is a critical production issue that needs to be addressed quickly your best bet is really talking to your Oracle sales rep or perhaps patching it yourself?

Comment by syangjava [ 28/Apr/14 ]

We think it is possible we can patch this ourselves. Is there any legal restrictions on this?

Comment by reza_rahman [ 28/Apr/14 ]

I would just review the CDDL/licensing terms that should be very lightweight and well understood in your case? BTW, the safest bet is probably just contributing the patch back.





[GLASSFISH-20227] alternative "ramid" for JMS and undeploying MDB-apps Created: 08/Apr/13  Updated: 09/Apr/13

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pierrecdn Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian/6.0



 Description   

Hello,

I recently added this option to default the JMS Adapter to HornetQ, after deploying the JCA connector "hornetq-ra" :

 
asadmin create-jvm-options -Dcom.sun.enterprise.connectors.inbound.ramid=hornetq-ra

But, when I undeployed an application that contains MDBs, no unsubscribe was done.
Consequently I had these kinds of errors :

  • re-deploying the app :
     
    [#|2013-04-08T14:55:30.414+0200|SEVERE|glassfish3.1.2|org.hornetq.ra.inflow.HornetQActivation|_ThreadID=42;_ThreadName=Thread-2;|Unable to
    reconnect org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@258d90b8 destination=/topic/adm-srvapp/coordination 
    destinationType=javax.jms.Topic ack=Auto-acknowledge durable=true clientID=client-id subscription=subscription-name 
    user=null maxSession=5)
    javax.jms.IllegalStateException: Cannot create a subscriber on the durable subscription since it already has subscriber(s)
    
  • sending a message :
    [#|2013-04-08T14:56:46.322+0200|SEVERE|glassfish3.1.2|org.hornetq.ra.inflow.HornetQMessageHandler|_ThreadID=2525;_ThreadName=Thread-2;|Failed to deliver message
    javax.ejb.EJBException: app:BackendMessageHandler: message-driven bean invocation closed by container
    

It works when I set a deployment descriptor in my projects like (even if the JVM option is deleted from domain.xml) :

<ejb>
  <ejb-name>BackendMessageHandler</ejb-name>
  <jndi-name>jms/adm-srvapp/app</jndi-name>
  <mdb-resource-adapter>
    <resource-adapter-mid>hornetq-ra</resource-adapter-mid>
  </mdb-resource-adapter>
</ejb>

What's wrong : glassfish and the RA_MID option ? Or the HornetQ JCA adapter ?



 Comments   
Comment by David Zhao [ 09/Apr/13 ]

This seems like connector related. Forward to JCA team for review.





[GLASSFISH-20392] It should need only 1 physical connection when using Non-XA connection sharing Created: 23/Apr/13  Updated: 23/Apr/13

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: xj Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Only one physical connection is needed in XA connection sharing. However, it is required to prepare two physical connections in Non-XA Transaction connection sharing case.

The current implementation in GF 3.1.2 is as follows:
----->
Two connections are acquired in the transaction.
Though two connections (and hence two physical connections) are
acquired, only one will be used in the transaction.
ie., the "handle" for both the connections would point to 1 physical
connection.
The other one is unused till the transaction is complete.
Once the transaction is complete, the "handles" would start referring to
their own physical connections.

eg:

Con1 = GetConnection(); //Con1 has Physical Con-1
Con2 = GetConnection(); //Con-2 has Physical Con-2

Con1 and Con2 can be used independently and the work done is
independent.

Tx.Begin()

Con1.execute
Con2.execute
[Both the above statements would be through one physical connection eg:
Con-2 will be using Physical Con-1 of Con1 due to connection sharing.]

Tx.Commit()
//At this stage, They would be re-wired so that
Con1.execute(..) // would use Physical Con-1
Con2.execute(..) //would use Physical Con-2

<-----

Using Non-XA Transaction connection sharing, only one physical connection should be required if multiple connections are needed from same transaction scope in an application.






GlassFish services and components to conform with configuration modularity (GLASSFISH-19408)

[GLASSFISH-19603] Connector service to become compatible with the configuration modualrity Created: 29/Jan/13  Updated: 29/Jan/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Masoud Kalali Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[GLASSFISH-19508] Race condition due to unsychronized HashMap access in ConnectorObjectFactory.getObjectInstance Created: 09/Jan/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2, 3.1.2.2, 4.0_b70
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: pdudits Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.7.0_05 64-bit, Windows Server 2008 R2, Glassfish 3.1.2



 Description   

Maps created in ConnectorRegistry.getResourceFactories are neither concurrent or synchronized. I am experiencing a race condition when ConnectorObjectFactory.getObjectInstance() concurrently invokes put on such map. The result is corruption of HashMap's hashtable and infinite loops in HashMap.get() or HashMap.put() bringing system's CPUs utilization to constant 100%.

Even though this has been only reproduced on Glassfish 3.1.2, these classes did not change in 3.1.2.2 or 4.0, so the bug also applies to all the versions.

Example stack trace:

pool-30-thread-39013
  at java.util.HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (HashMap.java:391)
  at com.sun.enterprise.resource.naming.ConnectorObjectFactory.getObjectInstance(Ljava/lang/Object;Ljavax/naming/Name;Ljavax/naming/Context;Ljava/util/Hashtable;)Ljava/lang/Object; (ConnectorObjectFactory.java:188)
  at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; (SerialContext.java:580)
  at com.sun.enterprise.naming.impl.SerialContext.lookup(Ljava/lang/String;I)Ljava/lang/Object; (SerialContext.java:514)
  at com.sun.enterprise.naming.impl.SerialContext.lookup(Ljava/lang/String;)Ljava/lang/Object; (SerialContext.java:455)
  at javax.naming.InitialContext.lookup(Ljava/lang/String;)Ljava/lang/Object; (InitialContext.java:411)
  at javax.naming.InitialContext.lookup(Ljava/lang/String;)Ljava/lang/Object; (InitialContext.java:411)
  at org.glassfish.osgi.ee.resources.ResourceProxy.getActualObject()Ljava/lang/Object; (ResourceProxy.java:81)
  at org.glassfish.osgi.ee.resources.ResourceProxy.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; (ResourceProxy.java:69)
  at $Proxy416.getConnection()Ljava/sql/Connection; (Unknown Source)
  at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(Ljavax/sql/DataSource;)Ljava/sql/Connection; (DataSourceUtils.java:111)
  at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(Ljavax/sql/DataSource;)Ljava/sql/Connection; (DataSourceUtils.java:77)
  at org.springframework.jdbc.core.JdbcTemplate.execute(Lorg/springframework/jdbc/core/PreparedStatementCreator;Lorg/springframework/jdbc/core/PreparedStatementCallback;)Ljava/lang/Object; (JdbcTemplate.java:572)
  at org.springframework.jdbc.core.JdbcTemplate.update(Lorg/springframework/jdbc/core/PreparedStatementCreator;Lorg/springframework/jdbc/core/PreparedStatementSetter;)I (JdbcTemplate.java:811)
  at org.springframework.jdbc.core.JdbcTemplate.update(Ljava/lang/String;Lorg/springframework/jdbc/core/PreparedStatementSetter;)I (JdbcTemplate.java:867)
  at org.springframework.jdbc.core.JdbcTemplate.update(Ljava/lang/String;[Ljava/lang/Object;)I (JdbcTemplate.java:875)
  ...

After one hour run, the system had almost 30 threads stuck in this stacktrace.



 Comments   
Comment by Jagadish [ 25/Mar/13 ]

http://java.net/jira/browse/GLASSFISH-19746 will take care of this issue.
Marking this for 4.0.1 as we are past the timeline for 4.0

Comment by pdudits [ 26/Mar/13 ]

That's a pity, I submitted the OCA over two weeks ago, but it is still not processed. There was also no reply when I asked for status, or whether there is any issue with the submission last week. Does it usually take this long?





[GLASSFISH-18817] Broken redeploy leaves partial EAR installation! Created: 21/Jun/12  Updated: 11/Jul/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mkarg Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 (64 Bit), JDK1.6.0_26



 Description   

For good reason, it is not possible to undeploy a EAR constaining RARs: As the RARs are possibly still used by different EARs, this is not possible without specifying "--cascade=true".

But when REDEPLOY crashes the result can be the following scenario:

EAR is uninistalled (list-applications says EAR is gone; another redeploy says EAR is gone), but the RARs are actually still in place!

This foils the idea of the "-cascade=true" safety switch! If this situation is allowed, then it also must be allowed to do an undeploy WITHOUT "-cascade=true"!

To reproduce this, you simple need to redeploy a EAR containing a WAR, and the new version of the WAR contains a typo in module's URI in glassfish-application.xml. The result of this is that the redeploy stops with the message that no such URI is known, the RARs are still in place, the EAR is completely undeployed.



 Comments   
Comment by Hong Zhang [ 21/Jun/12 ]

For the reproducible case, did you mean redeploy an EAR containing a RAR as this issue is related to RAR? It will be nice if you could just attach a simple test case to the issue so we know we are looking at the same issue as you are facing. Thanks.

Comment by mkarg [ 25/Jun/12 ]

Yes I mean redeploying an EARs containing RARs.

For reproduction, I can send you our EAR. But this is closed source, so I cannot upload it in JIRA. If you like to get the EAR, please let me know the eMail address where to send it.

Comment by Hong Zhang [ 25/Jun/12 ]

Please send the test case to hzhang_jn@java.net. Just need a simple test case to reproduce the problem, not necessarily the real application. Thanks.

Comment by Jeremy_Lv [ 26/Jun/12 ]

I wonder if you can send me the simple test case so that I can reproduce it too. My email address is lvsongping@cn.fujitsu.com. Thank you.

Comment by mkarg [ 10/Jul/12 ]

(File provided directly to Hong Zhang by FTP transfer)

Comment by Hong Zhang [ 11/Jul/12 ]

Thanks for sending me the application! I was actually later able to reproduce the problem with a simpler test case that Jagadish provided me also.

This is what I found from my investigation:

1. The cascade check is only made for undeployment and not redeployment, this is by design after confirming with the connector team. And seems we don't try to delete and then re-create the connector related resources as part of the redeployment.

2. If I redeploy with a valid application (say, if I redeploy the exact same application again), the redeployment finished as expected and no issues.

3. If I redeploy with an invalid application (for example, change the web module uri to an invalid uri), the redeployment failed with the application undeployed as part of the roll back logic. I think the rars are also undeployed, but the connector resources are still around (as the redeployment does not try to delete and re-create them).

I will let connector team to take over from here to see how we can improve the failed redeployment case better (maybe delete the connector resources as part of the roll back logic?).





[GLASSFISH-19111] CNFE for a WebLogic resource-adapter class when MDB deployed in GF cluster Created: 27/Sep/12  Updated: 27/Sep/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jleinawe Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux adc2180829 2.6.18-308.0.0.0.1.el5xen #1 SMP Sat Feb 25 16:26:29 EST 2012 x86_64 x86_64 x86_64 GNU/Linux


Attachments: Text File server.log    

 Description   

This is related to bug 14404726 in Oracle bug database. To run reproduction you will need assistance from Anil Kedia or Rajesh Gupta to setup the WebLogic server for JMS. The reproduction is designed to use WebLogic server at url: 't3://dickens:8121,dickens:8122,dickens:8123'

(this is configured in wljmsra.rar's ra.xml file)

The reproduction is in this zip file
ftp://bugftp.us.oracle.com/upload/bug_14/bug14377936/FannieMae_0926.zip

unzip
cd ./FannieMae
sh ./build_commands.sh

(this will kill any GF processes running, unzip glassfish to the ./bea/glassfish directory, deploy and configure wljmsra.rar, deploy the test ear files, stop/start the GF servers)

The rar and ear files are under the ./stage directory

After the run, if you look at an instance log,
./bea/glassfish/glassfish3/glassfish/nodes/localhost-gfdomain/instance1/logs/server.log

You will see this error (see attached server.log for an example)
[#|2012-09-26T11:26:27.855-0700|SEVERE|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.inbound|_ThreadID=102;_ThreadName=Thread-2;|RAR8503: Exception while creating ActivationSpec and getting inbound resources for recovery
javax.resource.spi.EISSystemException: constructor: weblogic.jms.common.JMSException: [JMSClientExceptions:055053]Error creating connection to the server: java.rmi.UnmarshalException: failed to unmarshal class weblogic.jms.client.JMSConnection; nested exception is:
java.lang.ClassNotFoundException: Failed to load class weblogic.jms.client.JMSXAConnection.

If you uncomment this line in build_commands.sh, you don't get the ClassNotFoundExceptions. (weblogic.jms.client.JMSXAConnection is in this file.
#JOHN cp ./stage/rar/wlthint3client.jar ./bea/glassfish/glassfish3/glassfish/lib

Also note that I'm only deploying one ear file in build_command.sh to simplify the test, to deploy all the test ears, you will need to uncomment
#JOHN ./bea/glassfish/glassfish3/bin/asadmin --passwordfile password.txt --interactive=false deploy --name SenderRecoveryMDB --force=true --upload=true --target c1 stage/SenderRecoveryMDB.ear

#JOHN ./bea/glassfish/glassfish3/bin/asadmin --passwordfile password.txt --interactive=false deploy --name JMSSenderBean --force=true --upload=true --target c1 stage/JMSSenderBean.ear






[GLASSFISH-18399] need a test-case for installed-libraries usage in both the application as well in RAR Created: 23/Feb/12  Updated: 23/Feb/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We might need a test-case to exercise the installed libraries support in connectors.
We currently have it only for connectors, ie., a rar can be deployed with installed library references.
However, we need to cover the following scenario :

  • deploy .rar with installed library references
  • deploy an application with installed library references that also depends on the above .rar

This will help to exercise the installed libraries support in the class-loader-hierarchy of the application (including the .rar).
Manual test-case worked fine. We need an automated one.






[GLASSFISH-18512] RAR8029 while creating Admin Object Resources for WebSphere MQ Queue + workaround Created: 15/Mar/12  Updated: 14/May/14

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mtalijanac Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows7 x64 + JDK1.6.0_31 (x86) + Glassfish 3.1.2 +
WebSphere MQ 7.0.2 running on remote machine


Tags: administration, connectors, jndi, websphere

 Description   

Hello.

I am trying to connect GlassFish 3.1.1 & 3.1.2 servers to the WebSphere MQ (WMQ) Queue Manager using wmq.jmsra rar archive provided by WMQ.

Deployment of WMQ JCA archive, and creation of Connector Resources & Connector Connection Pools works as espected. CFs are published to the JNDI; resources are visible trough list-jndi-entries; ping test are successful and applications are able to resolve connection factories (I tested CF and QCF, didn't try TCF).

However creation of Admin Object Resources, the actual queues (MQQueueProxy class), is not working. While everything looks nice in admin console, there is a log message: "INFO: RAR8029: Resource [ jms/DEMO_QUEUE ] of type [ aor ] is not enabled". Checkbox "Status" on "Edit Admin Object Resource" screens states that Status is enabled. JNDI reference is not published to the JNDI; at least it is not visible using list-jndi-entries nor lookup trough application.

Trough JMX console (JConsole) it is possible to edit "Enabled" attribute of associated MBean, and thus to really enable given queue. After that jndi references is visible trough list-jndi-entries, and applications are able to use give Q. Enabled queues are also visible trough Eclipse under GlassFish Management/Resurces/admin-object which is a nice touch.

Maybe this is just a GUI bug?

I tested this on GlassFish 3.1.1 & 3.1.2 and both behave same.



 Comments   
Comment by Tom Mueller [ 15/Mar/12 ]

Tom, can you determine whether this is a connector related issue or an admin GUI issue?

Comment by Tom Mueller [ 15/Mar/12 ]

Jagadish, can you please determine whether this is a connector problem or an admin GUI problem? Thanks.

Comment by Jagadish [ 20/Mar/12 ]

Hi mtalijanac,
I assume, you are creating the admin object resource with "target" as server. (DAS). Could you please confirm. If its for different target (eg: instance or a cluster), the resource-adapter should also be enabled in the target (instance / DAS).

Comment by Stephen Davies [ 14/May/14 ]

Has this exact problem with the Glassfish generic resource adapter (genericra). Found that creating the Admin Object Resources with the asadmin utility, rather than the GF GUI, fixed the problem.





[GLASSFISH-18425] JCA: Inspect JDK 7 getMethods()/getDeclaredMethods() usage Created: 28/Feb/12  Updated: 28/Feb/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_b25
Fix Version/s: None

Type: Task Priority: Major
Reporter: Joe Di Pol Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Recent JDK 7 releases have altered the order of methods returned by the
Class.getMethods() and Class.getDeclaredMethods() calls. The order is
no longer stable and can change from one JVM run to the next.

This caused a number of sporadic bugs to appear during 3.1.2 development
when running with JDK 7. Those have been fixed, but further inspection
of the source has found a number of cases where we use getMethods() and
getDeclaredMethods().

Each of these cases should be visually inspected to see if the code is
making any assumptions on the order of methods returned by get*Methods().
In particular it should handle the case of multiple methods having the
same name.

For more details on what to look for and how to fix it see this document:

https://wikis.oracle.com/display/GlassFish/Method+Ordering+from+Class.getMethods

Please inspect the following files for their use of getMethods() /
getDeclaredMethods() to ensure the code is not making any assumptions
with respect to the order of methods returned. Create bugs for
any issues that need to be fixed and link them to this task. Once you
have completed inspection update this task with status and close it.

Java EE Connector Architecture Runtime for GlassFish
    ConnectionDefinitionUtils.java
    ConnectorConfigParserUtils.java
    RARUtils.java
    SetMethodAction.java





[GLASSFISH-18614] Separate reosurces component from jca component Created: 11/Apr/12  Updated: 11/Apr/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-18615 [packager changes] Separate reosurces... Open
depends on GLASSFISH-17657 Separate reosurces component from jca... Resolved

 Description   

Currently resources runtime is embedded in jca component. While some resources depend on jca, not all do. e.g., a javamail resource or a jndi resource does not require jca. This task is created to separate out a resource container. Eventually this should get reflected in our packages as well.






[GLASSFISH-18603] validation during "undeploy" of application that has application/module scoped connector resources Created: 07/Apr/12  Updated: 07/Apr/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[ global resources = resources created via "create-xxx-resource" / "add-resources" command. ]

It is possible to deploy an application that has glassfish-resources.xml (application scoped resources) and there can be connector resources in the glassfish-resources.xml that refer a standalone resource-adapter.

While undeploying the standalone resource-adapter, validation should be done such that no application is having an application scoped connector type resources (connector resource, connector-connection pool, admin object) as its application scoped/module scoped resources. Such an use case result in undeployment failure.

This will be similar to failing undeployment of RAR when global resources of the RAR is present. There is "--cascade" flag for "undeploy" command to remove all global connector type resources of the RAR as part of the RAR undeployment, but with application scoped resources, it will be difficult so support --cascade for application scoped resources too.






[GLASSFISH-19427] connection leak reclaim does not work Created: 11/Dec/12  Updated: 04/Jun/14

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jifeng Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File LeakTimeout.war    
Tags: 4_0_1-reviewed

 Description   

I execute under three commands:

1.resources.jdbc-connection-pool.oracle_pool.pooling=false
2.set resources.jdbc-connection-pool.oracle_pool.connection-leak-timeout-in-seconds=10
3.set resources.jdbc-connection-pool.oracle_pool.connection-leak-reclaim=true

then I get jdbc connection from "oracle_pool" by my application,the connection that is not return back to the pool by my application within the specified period(leak-timeout), after 10 second, the function of connection-leak-reclaim does not work ,it is a pattern or a bug ?



 Comments   
Comment by jifeng [ 11/Dec/12 ]

test guide

1. create jdbc resource

asadmin start-database
asadmin create-jdbc-connection-pool --datasourceclassname org.apache.derby.jdbc.ClientDataSource --restype javax.sql.DataSource --isconnectvalidatereq=false --property User=APP:Password=APP:DatabaseName=EJB:PortNumber=1527:serverName=localhost:connectionAttributes=\\;create\\=true oracle_pool
asadmin set resources.jdbc-connection-pool.oracle_pool.pooling=false
asadmin set resources.jdbc-connection-pool.oracle_pool.connection-leak-timeout-in-seconds=10
asadmin set resources.jdbc-connection-pool.oracle_pool.connection-leak-reclaim=true
asadmin create-jdbc-resource  --target server --connectionpoolid oracle_pool jdbc/oracle

2.please download the attachment and deploy it

 
asadmin deploy --target server ./LeakTimeout.war

3.call:http://localhost:28282/LeakTimeout/UseConnection?sleepTime=20000

Comment by jifeng [ 04/Jan/13 ]

I think it is a bug:

com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure
public void removeResource(ResourceHandle resource) {
    boolean removed = false;
    writeLock.lock();
    try {
        removed = resources.remove(resource); "★"
    } finally {
        writeLock.unlock();
    }
    if(removed) {
       handler.deleteResource(resource);//not execute when the state of pool is unpooling

    }
}

the code which is marked as "★" has problem,because there is no connection in the pool when the state of pool is unpooling, so "handler.deleteResource(resource)" does not execute

I changed the code and it works fine

com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure
public void removeResource(ResourceHandle resource) {
    writeLock.lock();
    try {
        resources.remove(resource); 
    } finally {
        writeLock.unlock();
    }
    handler.deleteResource(resource)  
 }
}
Comment by jifeng [ 01/Aug/13 ]

Hi:
sfelts

This phenomenon also occurs in glassfish v4 .

when i used the way as above, it works fine

could you please confirm it and give me some suggestions?





[GLASSFISH-18197] connector container should use system provided parser for parsing resources xml Created: 14/Jan/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.0
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Refer the thread :
http://forums.java.net/node/882641

The application bundles a SAX parser which seem to be picked up by connector container for parsing glassfish-resources.xml. In the reported case, it might be a parser's issue which could not parse the xml. Ideally, the container should use the parser provided for the server instead of application bundled parser.






[GLASSFISH-18010] Resources Added using "Add Resource" feature do not show up for clusters and instances. Created: 15/Dec/11  Updated: 07/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2_b14
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: shaline Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris Sparc 10
FF 8.0.1
GF 3.1.2 SCF b14.


Attachments: XML File glassfish-resources.xml    
Tags: 3_1_2-exclude, 3_1_2-qa

 Description   

Enable Secure admin and access console remotely. Create a 2 instance cluster and start the cluster. Create a standalone instance and start the instance.
--Using the Add Resources feature select a glassfish-resources.xml file and first select the "server" as target. Resources will be added successfully. Check the Added Resources under server(Admin Server)/Resources Tab. We can see the JDBC resource added.
--Now go ahead and add the same glassfish-resources.xml and select the "cluster" target. Resources added successfully message is displayed. Check under Clusters/cluster1/Resources Tab. Notice that the resource is not listed.
--Repeat the steps for a standalone instance, message says Resources are added, but we do not find them under the Standalone-Instances/instance-name/Resources Tab.

Using CLI, these resources are listed for clusters and instances. if I do #asadmin list-jdbc-connection-pools cluster1, then I do see the pools for the cluster. But they do not show up in Console.

Attached the glassfish-resource.xml file to reproduce.



 Comments   
Comment by Anissa Lam [ 15/Dec/11 ]

I think Shaline is seeing the wrong thing. When you call add-resources using the same glassfish-resources.xml, but select another target, the command actually failed. There is no way that the resource is created for the other target using the add-resources command.

Here is what i see when using CLI to repeat the steps that Shaline reported above:

%> asadmin add-resources glassfish-resources.xml
Command : JDBC connection pool jdbc/test-pool created successfully.
Command : JDBC resource jdbc/test-ds created successfully.
Command add-resources executed successfully.

%>v3admin add-resources --target clusterABC glassfish-resources.xml
Command : A resource named jdbc/test-pool already exists.
Command : A JdbcResource named jdbc/test-ds already exists. If you are trying to create the existing resource configuration in target clusterABC, please use create-resource-ref command (or create resource-ref using admin console).
Command add-resources executed successfully.

However, when i try to do add-resources using GUI, it gives me an successfully message, but in fact, nothing happened. ie, no resource-ref is added for cluster-ABC. This is expected.

So, GUI should display the error message like CLI. It should not hide it and says successful. Maybe the backend didn't return a failure, or maybe GUI 'hide' the failure and didn't display that to user. This needs to be fixed.

Comment by Anissa Lam [ 15/Dec/11 ]

I know why Shaline is confused.
She said:
>> if I do #asadmin list-jdbc-connection-pools cluster1, then I do see the pools for the cluster. But they do not show up in Console.

She has mixed up connection-pools with jdbc Resources. Connection pool doesn't 'associate' with a target. Its for the entire domain. Resources has targets.

If she does
%asadmin list-jdbc-resources cluster1
she will see that the newly created resource, jdbc/test-ds will not show up.

%asadmin list-jdbc-connection-pools cluster1
will show all the connection pools for the domain, thus, she is seeing jdbc/test-pool.

Actually, list-jdbc-connection-pools should not take a target since it doesn't apply.
In fact, if you do
%asadmin list-jdbc-connection-pools lasjdlfajsdlfjlsakdjflksjdf

it will still show you the connection pools ok. The target is basically ignored. I think that command has a bug.

Comment by sumasri [ 19/Dec/11 ]

Here is what we see when using CLI to repeat the steps that Shaline reported above:

%> asadmin add-resources glassfish-resources.xml
Command : JDBC connection pool jdbc/test-pool created successfully.
Command : JDBC resource jdbc/test-ds created successfully.
Command add-resources executed successfully.

%>v3admin add-resources --target clusterABC glassfish-resources.xml
Command : A resource named jdbc/test-pool already exists.
Command : A JdbcResource named jdbc/test-ds already exists. If you are trying to create the existing resource configuration in target clusterABC, please use create-resource-ref command (or create resource-ref using admin console).
Command add-resources executed successfully.

In the second step, even though all resources are not added successfully, CLI is reporting it as success..
Hence, even GUI is just showing the success message.

It should be fixed it in the back end first. May be it should return a warning status and with the message.

Comment by sumasri [ 19/Dec/11 ]

Assigning it to jca team(Jagadish).

Comment by Tom Mueller [ 07/Mar/12 ]

Bulk update to set Fix Version to "not determined" for issues that had it set to a version that has already been released.





[GLASSFISH-18146] Allow global resources to be provisioned using glassfish-resources.xml Created: 07/Jan/12  Updated: 17/Oct/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently glassfish-resources.xml restricts resources to be in only in application/module scope. It is done this way as once the resource is created in global scope, it makes itself available for use by other applications and that creates a dependency among applications. When the original application gets undeployed, the referencing applications would fail to function. There have been suggestions of using reference counting as well. While this line of thinking is correct, but the same can be argued for any service that gets exposed by another application. More over, javax.annotation.sql.DataSourceDefinition, which is the spec equivalent of glassfish-resources for JDBC resource type, does not have such restriction. It allows resource to be created in global scope. Hence, we should remove this restriction from our implementation of glassfish-resources deployer.



 Comments   
Comment by Jagadish [ 17/Oct/12 ]

Not a mandatory feature for Java EE 7 RI.





[GLASSFISH-21356] Validation : Ensure that valid resource-adapter name is specified in @ConnectionFactoryDefinition/@AdministeredObjectDefinition Created: 08/May/15  Updated: 08/May/15

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.1
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As per the java-doc of @ConnectionFactoryDefinition.resourceAdapter(), the resource adapter specified must be available during deployment time:
http://docs.oracle.com/javaee/7/api/javax/resource/ConnectionFactoryDefinition.html#resourceAdapter%28%29

It implicitly indicates that deployment of the application archive that has these annotations (@ConnectionFactoryDefinition, @AdministeredObjectDefinition") can be failed if the resource-adapter name is invalid.

Today, GlassFish does not fail deployment of the archive, instead during first time lookup of the resource, the lookup will fail. Need to fix this behavior and make sure that validation is done as part of application deployment.






[GLASSFISH-15134] WorkCoordinator lock coordination is flawed Created: 13/Dec/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1_b31
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Scott Oaks Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CDS is reporting instances where MDB messages are not processed and a thread ends up blocked in this state:
"imqConsumerReader-9-2442126225450619648-0" daemon prio=3 tid=0x01cea800 nid=0xdb in Object.wait() [0xf109f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x647faca8> (a java.lang.Object)
    at java.lang.Object.wait(Object.java:485)
    at com.sun.enterprise.connectors.work.WorkCoordinator.lock(WorkCoordinator.java:339)
  • locked <0x647faca8> (a java.lang.Object)
    at com.sun.enterprise.connectors.work.CommonWorkManager.startWork(CommonWorkManager.java:203)
    at com.sun.enterprise.connectors.work.CommonWorkManager.startWork(CommonWorkManager.java:175)
    at com.sun.enterprise.connectors.work.WorkManagerProxy.startWork(WorkManagerProxy.java:89)
    at com.sun.messaging.jms.ra.OnMessageRunner.onMessage(OnMessageRunner.java:382)
    at com.sun.messaging.jms.ra.MessageListener.onMessage(MessageListener.java:214)
    at com.sun.messaging.jmq.jmsclient.MessageConsumerImpl.deliverAndAcknowledge(MessageConsumerImpl.java:338)
    at com.sun.messaging.jmq.jmsclient.MessageConsumerImpl.onMessage(MessageConsumerImpl.java:273)
    at com.sun.messaging.jmq.jmsclient.SessionReader.deliver(SessionReader.java:113)
    at com.sun.messaging.jmq.jmsclient.ConsumerReader.run(ConsumerReader.java:186)
    at java.lang.Thread.run(Thread.java:619)

From looking at the WorkCoordinator code, there are two potential problems:
1) The lock is acquired after the work has been submitted:
CommonWorkManager.startWork() {
...
wc.submitWork(WorkCoordinator.WAIT_UNTIL_START);
wc.lock();
...
}

If the workQueue.preInvoke() (from submitWork()) happens to run before wc.lock(), then the work coordinator will remain locked (the scenario CDS describes).

2) In other circumstances, the lock() method could return prior to when it is actually ready due to spurious wakeups. If the thread calling WorkCoordinator.lock() receives two spurious wakeups, it will return before it is intended to; wait/notify must always be called in a loop so that the thread that wakes up can test the condition to see if it actually exists.



 Comments   
Comment by Scott Oaks [ 13/Dec/10 ]

We have tracked down the customer problem to a different bug. Still, I am leaving this issue open – the code is wrong, and though it is highly unlikely that the race condition I described would happen, still better to program defensively.





[GLASSFISH-7065] Can't access native libraries inside a RAR file. Created: 19/Jan/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: dalenkruse Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File nativelibv15outbound.ear    
Issuezilla Id: 7,065
Status Whiteboard:

V2.1.1_exclude


 Description   

GlassFish currently does not provide access to a native library bundled inside a
RAR file. GlassFish must be configured to find the native library at a separate
location. See the forum post at
http://forums.java.net/jive/thread.jspa?threadID=56191&tstart=15



 Comments   
Comment by Dies Koper [ 26/Jan/09 ]

Created an attachment (id=2235)
test application helpful to reproduce the error

Comment by Dies Koper [ 26/Jan/09 ]

I have attached a test application useful to reproduce the issue. The RAR in the
EAR contains a simple Windows DLL library.

Steps to reproduce:
1. Deploy the EAR.
2. Create a connector connection pool.
3. Create a connector resource eis/nativelibv15outboundCF.
4. Create an Admin Object resource with name nativelibv15outboundAO and resource
type nativelibv15outbound.ra.DebugBox.
5. Access the servlet at http://localhost:8080/nativelibv15outboundWEB/, insert
some text in the two fields and click on Submit.

The server.log will contain the UnsatisfiedLinkError with a stacktrace
(reproduced in GFv2.1):

[#|2009-01-27T14:58:02.772+1100|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-0;|
Test calling native code...|#]

[#|2009-01-27T14:58:02.788+1100|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-0;|
java.library.path in system property —
D:\tests\GFv2.1\glassfish-v2.1-b60e\glassfish\lib;D:\tests\GFv2.1\glassfish-v2.1-b60e\glassfish\lib;D:\tests\GFv2.1\glassfish-v2.1-b60e\glassfish\bin;D:\tests\GFv2.1\glassfish-v2.1-b60e\glassfish\lib;D:\tests\GFv2.1\glassfish-v2.1-b60e\glassfish\lib|#]

[#|2009-01-27T14:58:02.788+1100|SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=3c5ebc72-8686-4821-bc41-9cad5d8dc2ec;|StandardWrapperValve[DebugServlet]:
PWC1406: Servlet.service() for servlet DebugServlet threw exception
java.lang.UnsatisfiedLinkError: no nativesample in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at nativelibv15outbound.ra.NativeLib.<clinit>(NativeLib.java:9)
at
nativelibv15outbound.ra.DebugMessageBox.callNativeMethod(DebugMessageBox.java:65)
at nativelibv15outbound.ra.DebugMessageBox.sendMessage(DebugMessageBox.java:55)
at nativelibv15outbound.ra.BoxManagerImpl.sendMessage(BoxManagerImpl.java:22)
at nativelibv15outbound.web.DebugServlet.sendMessage(DebugServlet.java:125)
at nativelibv15outbound.web.DebugServlet.service(DebugServlet.java:95)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-6388] java.lang.LinkageError during DeployEndpoint Created: 02/Oct/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: dernasherbrezon Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File Issue 6388.rar    
Issuezilla Id: 6,388

 Description   

Here is the scenario.

I've created two connector modules, one ear with endpoints(beans.jar) and one
shared library(lib.jar):
/ear
beans.jar
lib.jar
jca1-api.jar

/jca1
jca1-api.jar
jca1-impl.jar
lib.jar

/jca2
jca2-impl.jar
lib.jar

Then i:
1. deploy jca2
2. deploy jca1
3. deploy ear

And in logs i see:

[#|2008-10-02T11:35:36.546+0400|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=21;_ThreadName=Thread-38;_RequestID=1a1d1e5e-bae8-47f0-b21f-323de03db554;|java.lang.LinkageError:
loader constraint violation: loader (instance of
com/sun/enterprise/loader/EJBClassLoader) previously initiated loading for a
different type with name "org/test/POJO"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at com.sun.enterprise.loader.EJBClassLoader.findClass(EJBClassLoader.java:687)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
at java.lang.Class.getMethod0(Class.java:2688)
at java.lang.Class.getMethod(Class.java:1603)
at
com.sun.ejb.containers.interceptors.InterceptorManager.loadOnlyEjbCreateMethod(InterceptorManager.java:407)
at
com.sun.ejb.containers.interceptors.InterceptorManager.initCallbackIndices(InterceptorManager.java:309)
at
com.sun.ejb.containers.interceptors.InterceptorManager.buildInterceptorChain(InterceptorManager.java:234)
at
com.sun.ejb.containers.interceptors.InterceptorManager.<init>(InterceptorManager.java:121)
at
com.sun.ejb.containers.BaseContainer.initializeInterceptorManager(BaseContainer.java:2297)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:654)
at
com.sun.ejb.containers.MessageBeanContainer.<init>(MessageBeanContainer.java:150)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:524)
at com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:536)
at com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:188)
at
com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:126)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
at
com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at
com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
at
com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at
com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:591)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:635)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744)
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:597)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at
com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at
com.sun.enterprise.deployment.client.DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145)
at com.sun.enterprise.deployment.client.DeployAction.run(DeployAction.java:537)
at java.lang.Thread.run(Thread.java:619)

#]

Where is org.test.POJO is the simple pojo bean in shared library (lib.jar)
BUT! if i:
1. deploy jca1
2. deploy jca2
3. deploy ear
Everything is OK! it seems that jca classloader loading lib.jar in jca2
deployment phase and when i want to activateEndpoint with class loaded by
another jca module i'll get exception.

jca1 has its own messagelistener-type with method contains as parameter
org.test.POJO.

simple solution for this is to remove lib.jar from jca2. But this is very ugly
in architecture design and can be applied only for small use cases.

In attachment eclipse projects that create such modules.



 Comments   
Comment by dernasherbrezon [ 02/Oct/08 ]

Created an attachment (id=1921)
sample projects for modules

Comment by Jagadish [ 17/Oct/08 ]

adding cc

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-7511] parameter to workmanager.instantiation_error's message not substituted Created: 03/Apr/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,511
Status Whiteboard:

v3_exclude,V2.1.1exclude


 Description   

When specifying a non-existing thread pool ID for an RA and starting a cluster,
I got the following messages in server.log:

An error occurred during instantiation of the work manager

{0}

com.sun.enterprise.connectors.ConnectorRuntimeException
at
com.sun.enterprise.connectors.work.CommonWorkManager.<init>(CommonWorkManager.java:99)
...

The argument is not substituted.

The problem is the following code in:
com.sun.enterprise.connectors.BootstrapContextImpl#createWorkManager

String msg = localStrings.getString("workmanager.instantiation_error");
logger.log(Level.SEVERE, msg, e);

Instead of 'e' (which means the VM will invoke
Logger#log(String,String,Throwable), it should specify 'poolName' (so that
Logger#log(String, String, Object) is invoked), followed by a logging statement
for the stacktrace:

String msg = localStrings.getString("workmanager.instantiation_error");
logger.log(Level.SEVERE, msg, poolName);
logger.log(Level.SEVERE, "", e);

The stacktrace won't be useful to the user, but it might give more information
to a GF developer.



 Comments   
Comment by Jagadish [ 29/Aug/09 ]

Thanks for looking into this.

If there is an issue while getting the thread pool, it would have been logged by
https://glassfish.dev.java.net/source/browse/glassfish/appserv-core/src/java/com/sun/enterprise/connectors/work/CommonWorkManager.java?annotate=1.7

Also, BootStrapContextImpl uses LogStrings and not LocalStrings "key".

I guess, the actual message is logged by
com.sun.enterprise.connectors.work.WorkManagerFactory#getWorkManager()
which uses LocalStrings and the LocalStrings is defined as :

workmanager.instantiation_error=An error occurred during instantiation of the
work manager

{0}

So, we do not need the parameter as the "Pool not found" exception will be
logged anyway by CommonWorkManager. It is also possible that poolName would be
null (which will be eventually translated to default-thread-pool) here if no
thread-pool-id is explicitly set by the user

Actual fix would be :
===================================================================
RCS file:
/cvs/glassfish/appserv-core/src/java/com/sun/enterprise/connectors/work/LocalStrings.properties,v
retrieving revision 1.1
diff -r1.1 LocalStrings.properties
2c2
< workmanager.instantiation_error=An error occurred during instantiation of the
work manager {0}


> workmanager.instantiation_error=An error occurred during instantiation of the
work manager

Changing the release as v2 as it is reported in v2.

More changes :
1) We can also set the "initCause" of the exception when CommonWorkManager
catches NoSuchThreadPoolException and rethrows ConnectorRuntimeException
2) BootstrapContextImpl uses logString "workmanager.instantiation_error" which
does not seem to be defined. We need to define one. (This is fixed in v3)

I shall fix it in v3 soon.

Comment by Jagadish [ 31/Aug/09 ]

Provided the following fix for v3 :

svn log -v -r 30956
------------------------------------------------------------------------
r30956 | jr158900 | 2009-08-31 16:44:49 +0530 (Mon, 31 Aug 2009) | 6 lines
Changed paths:
M
/trunk/v3/connectors/work-management/src/main/java/com/sun/enterprise/connectors/work/CommonWorkManager.java
M
/trunk/v3/connectors/work-management/src/main/java/com/sun/enterprise/connectors/work/LocalStrings.properties
M
/trunk/v3/connectors/work-management/src/main/java/com/sun/enterprise/connectors/work/WorkManagerFactory.java

Comment by Jagadish [ 31/Aug/09 ]

Change above also includes changes for Monitoring registry registration for
jms-service element

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Jagadish [ 07/Sep/09 ]

adding status whiteboard flag for v3 as it is fixed in v3

Comment by jagadesh [ 15/Oct/09 ]

Will Not be fixed for V2.1.1

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-7905] deploy --libraries option does not work for RAR module Created: 17/Apr/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File InboundRA.rar     Java Archive File InboundRAUtilities.jar     GZip Archive it-7905-successful-deployment.server.log.tar.gz    
Issuezilla Id: 7,905
Status Whiteboard:

v3_exclude, v2.1.1_exclude


 Description   

I put the resource adapter's message listener and log wrapper in a separate jar
file so that I can share them with the MDB application that I will deploy
separately.
First I try to deploy the resource adapter with the --libraries option, but it
does not work:

asadmin deploy --libraries c:\InboundRAUtilities.jar c:\InboundRA.rar
Command deploy executed successfully with following warning messages: Error
occurred during application loading phase. The application will
not run properly. Please fix your application and redeploy.
WARNING: com.sun.enterprise.deployment.backend.IASDeploymentException

According to the server log the log wrapper in the library could not be found:

[#|2009-04-17T22:59:50.531+1000|WARNING|sun-appserver2.1|javax.enterprise.system.stream.err|_ThreadID=44;_ThreadName=httpWorkerThread-4848-4;_RequestID=b7eb0164-00ce-4506-9b97-557c12225b5f;|com.sun.enterprise.admin.event.AdminEventListenerException
at
com.sun.enterprise.server.StandAloneConnectorModulesManager.moduleEnabled(StandAloneConnectorModulesManager.java:481)
at
com.sun.enterprise.server.StandAloneConnectorModulesManager.moduleDeployed(StandAloneConnectorModulesManager.java:268)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.invokeModuleDeployEventListener(AdminEventMulticaster.java:1005)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.handleModuleDeployEvent(AdminEventMulticaster.java:992)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:470)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:182)
at
com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at
com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:231)
at
com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at
com.sun.enterprise.deployment.phasing.ResourceAdapterStartPhase.runPhase(ResourceAdapterStartPhase.java:127)
at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:966)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:609)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:653)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:773)
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:597)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:381)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:364)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:477)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at
com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at
com.sun.enterprise.admin.jmx.remote.server.callers.InvokeCaller.call(InvokeCaller.java:69)
at
com.sun.enterprise.admin.jmx.remote.server.MBeanServerRequestHandler.handle(MBeanServerRequestHandler.java:155)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.processRequest(RemoteJmxConnectorServlet.java:122)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.doPost(RemoteJmxConnectorServlet.java:193)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:315)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:288)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:647)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:579)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:831)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:116)
Caused by: java.lang.NoClassDefFoundError:
com/fujitsu/test/connector15/level2/LogWrapper
at
com.fujitsu.test.connector15.level2.ra.ResourceAdapterImpl.<init>(ResourceAdapterImpl.java:65)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at
com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:79)
at
com.sun.enterprise.connectors.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:300)
at
com.sun.enterprise.connectors.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:445)
at
com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:230)
at
com.sun.enterprise.server.ConnectorModuleLoader.load(ConnectorModuleLoader.java:118)
at
com.sun.enterprise.server.ConnectorModuleLoader.doLoad(ConnectorModuleLoader.java:142)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:238)
at
com.sun.enterprise.server.StandAloneConnectorModulesManager.moduleDeployed(StandAloneConnectorModulesManager.java:146)
at
com.sun.enterprise.server.StandAloneConnectorModulesManager.realDeployed(StandAloneConnectorModulesManager.java:338)
at
com.sun.enterprise.server.StandAloneConnectorModulesManager.moduleEnabled(StandAloneConnectorModulesManager.java:476)
... 63 more
Caused by: java.lang.ClassNotFoundException:
com.fujitsu.test.connector15.level2.LogWrapper
at com.sun.enterprise.loader.EJBClassLoader.findClassData(EJBClassLoader.java:738)
at com.sun.enterprise.loader.EJBClassLoader.findClass(EJBClassLoader.java:628)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)

#]

[#|2009-04-17T22:59:50.531+1000|WARNING|sun-appserver2.1|javax.enterprise.system.stream.err|_ThreadID=44;_ThreadName=httpWorkerThread-4848-4;_RequestID=b7eb0164-00ce-4506-9b97-557c12225b5f;|
... 80 more

#]

[#|2009-04-17T22:59:50.531+1000|WARNING|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=44;_ThreadName=httpWorkerThread-4848-4;_RequestID=b7eb0164-00ce-4506-9b97-557c12225b5f;|ADM5603:Event
listener error [null]|#]



 Comments   
Comment by Dies Koper [ 17/Apr/09 ]

Created an attachment (id=2623)
test app

Comment by Dies Koper [ 17/Apr/09 ]

Created an attachment (id=2624)
jar with classes that resource adapter depends on

Comment by Dies Koper [ 17/Apr/09 ]

On V3-ea-b42 it also fails, with the following stacktrace in server.log:

[#|2009-04-17T23:10:54.046+1000|SEVERE|glassfish|javax.enterprise.system.tools.admin|_ThreadID=14;_ThreadName=Thread-1;|Error
during deployment : com/fujitsu/test/connector15/level2/LogWrapper
java.lang.NoClassDefFoundError: com/fujitsu/test/connector15/level2/LogWrapper
at
com.fujitsu.test.connector15.level2.ra.ResourceAdapterImpl.<init>(ResourceAdapterImpl.java:65)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at
com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:92)
at
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:261)
at
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:373)
at
com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:339)
at
com.sun.enterprise.connectors.module.ConnectorDeployer.load(ConnectorDeployer.java:123)

Comment by Hong Zhang [ 17/Apr/09 ]

I will let jagadish look at this one..

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Jagadish [ 27/Sep/09 ]

Fixed the issue in v3

svn log -v -r 31944

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=14474

Comment by Jagadish [ 27/Sep/09 ]

Created an attachment (id=3328)
server.log indicating successful deployment of rar with --libraries option

Comment by Jagadish [ 27/Sep/09 ]
      • Issue 3808 has been marked as a duplicate of this issue. ***
Comment by Jagadish [ 28/Sep/09 ]

For v3 : Fix available from b 66

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-11821] poor error message from create-jdbc-connection-pool Created: 24/Apr/10  Updated: 02/Nov/10

Status: Reopened
Project: glassfish
Component/s: jdbc
Affects Version/s: v3.0.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Minor
Reporter: vince kraemer Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,821

 Description   

Here is the output that I get from 3.0.1 b12

vkraemer$ ../../GlassFish3.0.1.b12/glassfish/bin/asadmin create-jdbc-connection-pool foobar
com.sun.enterprise.admin.cli.CommandException: remote failure: JDBC connection pool foobar creation
failed. Constraints for this bean violated.
Message = Must specify a datasource/driver classname. DatasourceClassname is mandatory when
resType is javax.sql.DataSource/javax.sql.ConnectionPoolDataSource/javax.sql.XADataSource.
DriverClassname is mandatorywhen resType is java.sql.Driver.

Command create-jdbc-connection-pool failed.

Here is the output that I expected....

vkraemer$ ../../GlassFish3.0.1.b12/glassfish/bin/asadmin create-jdbc-connection-pool foobar
com.sun.enterprise.admin.cli.CommandException: remote failure: JDBC connection pool foobar creation
failed. Constraints for this bean violated.
Message = Must specify a datasource/driver classname. DatasourceClassname is mandatory when
resType is javax.sql.DataSource/javax.sql.ConnectionPoolDataSource/javax.sql.XADataSource.
DriverClassname is mandatorywhen resType is java.sql.Driver.
Usage: asadmin [asadmin-utility-options] create-jdbc-connection-pool
[--datasourceclassname <datasourceclassname>] [--restype <restype>]
[--steadypoolsize <steadypoolsize>] [--maxpoolsize <maxpoolsize>]
[--maxwait <maxwait>] [--poolresize <poolresize>]
[--idletimeout <idletimeout>] [--initsql <initsql>]
[--isolationlevel <isolationlevel>]
[--isisolationguaranteed[=<isisolationguaranteed(default:true)>]]
[--isconnectvalidatereq[=<isconnectvalidatereq(default:false)>]]
[--validationmethod <validationmethod>]
[--validationtable <validationtable>]
[--failconnection[=<failconnection(default:false)>]]
[--allownoncomponentcallers[=<allownoncomponentcallers(default:false)>]]
[--nontransactionalconnections[=<nontransactionalconnections(default:false)>]]
[--validateatmostonceperiod <validateatmostonceperiod>]
[--leaktimeout <leaktimeout>]
[--leakreclaim[=<leakreclaim(default:false)>]]
[--creationretryattempts <creationretryattempts>]
[--creationretryinterval <creationretryinterval>]
[--sqltracelisteners <sqltracelisteners>]
[--statementtimeout <statementtimeout>]
[--lazyconnectionenlistment[=<lazyconnectionenlistment(default:false)>]]
[--lazyconnectionassociation[=<lazyconnectionassociation(default:false)>]]
[--associatewiththread[=<associatewiththread(default:false)>]]
[--driverclassname <driverclassname>]
[--matchconnections[=<matchconnections(default:false)>]]
[--maxconnectionusagecount <maxconnectionusagecount>]
[-ping[=<ping(default:false)>]] [-pooling[=<pooling(default:true)>]]
[--statementcachesize <statementcachesize(default:0)>]
[--validationclassname <validationclassname>]
[--wrapjdbcobjects[=<wrapjdbcobjects(default:true)>]]
[--description <description>] [--property <property>]
[--target <target>] [?|-help[=<help(default:false)>]]
jdbc_connection_pool_id
Command create-jdbc-connection-pool failed.

The error would be even better if it said this

com.sun.enterprise.admin.cli.CommandException: remote failure: JDBC connection pool foobar creation
failed.
Message = Must specify a datasource/driver classname. The option --datasourceclassname or –
driverclassname is mandatory.

instead of this

com.sun.enterprise.admin.cli.CommandException: remote failure: JDBC connection pool foobar creation
failed. Constraints for this bean violated.
Message = Must specify a datasource/driver classname. DatasourceClassname is mandatory when
resType is javax.sql.DataSource/javax.sql.ConnectionPoolDataSource/javax.sql.XADataSource.
DriverClassname is mandatorywhen resType is java.sql.Driver.



 Comments   
Comment by Bill Shannon [ 14/Sep/10 ]

Reassign.

Comment by Jagadish [ 25/Sep/10 ]

"Constraints for this bean violated."
Above message is due to "bean-validation" constraints violation. This will
happen for any validation failure, not just for the reported case.

More samples :
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

asadmin set server.resources.jdbc-connection-pool.DerbyPool.max-pool-size=5
remote failure: Could not change the attributes: Constraints for this bean
violated.
Message = Max-pool-size has to be greater than or equal to steady-pool-size
Constraints for this bean violated. Message = Max-pool-size has to be greater
than or equal to steady-pool-size

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

asadmin set server.resources.jdbc-connection-pool.DerbyPool.max-pool-size=0
remote failure: Could not change the attributes:
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = maxPoolSize must be greater than or equal to 1
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = maxPoolSize must be greater than or equal to 1

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

asadmin set server.resources.jdbc-connection-pool.DerbyPool.pool-resize-quantity=-1
remote failure: Could not change the attributes:
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = poolResizeQuantity must be greater than or equal to 1
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = poolResizeQuantity must be greater than or equal to 1

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Either Config or HK2 module need to take care of this.

Comment by Tom Mueller [ 27/Sep/10 ]

The bean validation logic doesn't have any way to translate a validation failure
into a message about command line options. To do this, the command would need to
catch the validation exception, determine what the failure was, and then produce
an appropriate message. However, the trick here is to figure out how to catch the
validation exception and translate it into a command exception with a different
error message. Check with Jerome on that.

Comment by Jagadish [ 27/Sep/10 ]

This issue is not related to individual module or individual command.
This is common for all "configuration" beans that use bean-validation.
Instead of expecting individual modules/commands to handle the message, it would
be helpful if config / hk2 can handle this.

IIUC, the bug submitter's suggestion is :
eg:

Instead of :

remote failure: Could not change the attributes:
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated.
Message = poolResizeQuantity must be greater than or equal to 1

It should be :
poolResizeQuantity must be greater than or equal to 1

Comment by Tom Mueller [ 27/Sep/10 ]

Please reread the description. The submitter doesn't mention anything about
poolSizeQuantity. I agree that the bean validation message should be cleaned up
so that it doesn't have "Message = " or repeat the message; that would be a
different bug.

The submitters request was to change:

"Must specify a datasource/driver classname. DatasourceClassname is mandatory
when resType is
javax.sql.DataSource/javax.sql.ConnectionPoolDataSource/javax.sql.XADataSource.
DriverClassname is mandatory when resType is java.sql.Driver."

to

"Must specify a datasource/driver classname. The option --datasourceclassname or
--driverclassname is mandatory."

This reference to command options is specific to a particular command and cannot
be handled by the configuration framework without having knowledge about how
command options map to bean properties.

Comment by Jagadish [ 27/Sep/10 ]

Thanks, I have raised issue 13625 to track the bean validation related issue.

Comment by Tom Mueller [ 28/Sep/10 ]
      • Issue 13625 has been marked as a duplicate of this issue. ***
Comment by Jagadish [ 05/Oct/10 ]

setting target milestone

Comment by Jagadish [ 30/Oct/10 ]

Here is the latest output.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
asadmin create-jdbc-connection-pool foobar
remote failure: JDBC connection pool foobar creation failed. Constraints for
this bean violated.
Message = Must specify either datasource-classname or driver-classname.
datasource-classname is mandatory when res-type is javax.sql.DataSource or
javax.sql.ConnectionPoolDataSource or javax.sql.XADataSource. driver-classname
is mandatory when res-type is java.sql.Driver.

Command create-jdbc-connection-pool failed.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

There are two parts :
Part 1 :
"remote failure: JDBC connection pool foobar creation failed. Constraints for
this bean violated. "
Part 2 :
Message = Must specify either datasource-classname or driver-classname.
datasource-classname is mandatory when res-type is javax.sql.DataSource or
javax.sql.ConnectionPoolDataSource or javax.sql.XADataSource. driver-classname
is mandatory when res-type is java.sql.Driver.

Part 1 of the message is from the common framework. I have raised issue 13625
for the same.

Part 2 of the message is a bit verbose as it indicates the appropriate parameter
(either datasource-classname or driver-classname) to be used for various
"res-type".
If we provide the message : "either datasource-classname or driver-classname is
mandatory", then the relationship with restype is not clarified here.

Hence, I feel that current message is fine as we are trying to give more
information in the message w.r.t "restype" and "driver/datasource-classname"

Comment by vince kraemer [ 01/Nov/10 ]

The primary problem that I was concerned about is the following...

The error message does not provide feedback to the user in terms of the valid options to the command
that failed..

datasource-classname should be --datasourceclassname
driver-classname should be --driverclassname

in the error message.

Comment by Jagadish [ 02/Nov/10 ]

The difference in names is because they are from the config validation module
(that validates before persisting a configuration in domain.xml) which is common
for both CLI and GUI. Only other option would be to duplicate this validation in
CLI also.

Comment by vince kraemer [ 02/Nov/10 ]

can you have the message that gets generated by the config validation 'filtered' by the cli command to
remap the strings in the error message into the vocabulary of the command that executed?





[GLASSFISH-3317] Deploying a EJB Module containing persistence.xml and sun-resources.xml fails Created: 10/Jul/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: nityad Assignee: Jagadish
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive CustomerCMP-ejb.zip     Zip Archive CustomerCMP-ejb.zip     Zip Archive CustomerCMP-ejbWOPersistence.zip     Text File CustomerCMP-ejbWOPersistence.zip     Text File server.log    
Issuezilla Id: 3,317

 Description   

Win XP
GlassFish b54

Deploying an ejb project from NetBeans that contains both persistence.xml and
sun-resources.xml
containing the required resources fails with following exception,

TopLink, version: Oracle TopLink Essentials - 2.0 (Build b52-rc (06/20/2007))
Server: unknown
RAR7010: Pool not reachable.
RAR5114 : Error allocating connection : [This pool is not registered with the
runtime environment]
Exception occured in J2EEC Phase
com.sun.enterprise.deployment.backend.IASDeploymentException:
Internal Exception: java.sql.SQLException: This pool is not registered with the
runtime environment

Complete stacktrace is attached.

It appears that the persistence.xml is loaded/executed before the
sun-resources.xml is loaded and hence required resources are not found.

Deploying the app containing persistence.xml but without the sun-resources.xml
succeeds if resources are pre-registered on the server.
Attached project : CustomerCMP-ejb

Deploying the app containing sun-resources.xml but without the persistence.xml
succeeds and the resources defined in the sun-resources.xml are successfully
registered.
Attached project : CustomerCMP-ejbWOPersistence

Associated NetBeans issue : http://www.netbeans.org/issues/show_bug.cgi?id=106980



 Comments   
Comment by nityad [ 10/Jul/07 ]

Created an attachment (id=1016)
CustomerCMP with persistence.xml

Comment by nityad [ 10/Jul/07 ]

Created an attachment (id=1017)
CustomerCMP without persistence.xml

Comment by nityad [ 10/Jul/07 ]

Created an attachment (id=1018)
server.log - stack trace

Comment by Hong Zhang [ 10/Jul/07 ]

Downgrade the bug to P2 as there is the workaround of pre-registering resources.
Will look into this problem right away.

Comment by gfbugbridge [ 10/Jul/07 ]

<BT6579009>

Comment by marina vatkina [ 10/Jul/07 ]

Is this a regression? If yes, when did it stop working?

Comment by vince kraemer [ 10/Jul/07 ]

I doubt this use-case has ever been tested... so it has probably always been broken.

Comment by marina vatkina [ 10/Jul/07 ]

I suspect that it's not co-existance of persistence.xml and sun-resource.xml,
but ddl generation properties in the persistence.xml that cause the problem - I
see these lines in the persistence.xml:
<properties>
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>
</properties>

Was the support ever designed to auto-install resources for deployment?

Comment by vince kraemer [ 10/Jul/07 ]

that may be. could you test it and report back?

Comment by marina vatkina [ 10/Jul/07 ]

Can bug submitter check that?

Comment by kshitiz_saxena [ 10/Jul/07 ]

More clarification on pre-registering resources - It means that you create all
resources that are needed manually using CLI(asadmin command) or GUI.

Once these resources are created, they should not be part of sun-resources.xml.
Because in that case, deployment will fail as it will detect conflicting resources.

Comment by Hong Zhang [ 11/Jul/07 ]

When attaching the nb project, could you please also include the packaged
application (the jar/ear) inside the project? Also please make sure you attach
the zip as binary format. Thanks.

Comment by nityad [ 11/Jul/07 ]

Created an attachment (id=1020)
updated zip with archive

Comment by nityad [ 11/Jul/07 ]

Created an attachment (id=1021)
updated zip with archive

Comment by Hong Zhang [ 11/Jul/07 ]

Summary of the discussions so far:
1. The cause of the problem has been identified. It is related to the
drop/create table property in the persistence.xml as Marina pointed out.
<properties>
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>
</properties>
I have verified the application deploys successfully when this property is
removed from persistence.xml.

2. When this property is specified, the java2db tool will be triggered to
generate necessary artifacts (DDL etc) and create the tables during J2EECPhase
of the deployment. J2EECPhase is the initial phase of the deployment where it
processes the deployment descriptor and generates necessary artifacts.

3. The resource installation/creation happens at the beginning of the StartPhase
where the application is being loaded to the container. This happens after the
java2db tool's execution.

4. For the users to fully take advantage of the java2db tool (so the users don't
need to create tables themselves manually), the resource installation needs to
be happen before java2db tool's execution.

Comment by nityad [ 11/Jul/07 ]

Hong, Your analysis is spot on. The app does deploy when the persistence.xml
does not have <property name="toplink.ddl-generation"
value="drop-and-create-tables"/>

But execution fails because necessary tables are not present.

So the persistence.xml needs to have this property defined and the resources
should be registered before the java2db tool starts.

Comment by Hong Zhang [ 11/Jul/07 ]

Yes, the tables need to be there for the application to run. That was just to
verify the cause and not recommended as the fix

Comment by Hong Zhang [ 13/Jul/07 ]

Updates of my further investigation on possible fixes from the deployment side.

There were two possible fixes to this problem and neither of them worked out well:
1. Move the resource creation earlier in time, so resources are ready before the
java2db tool is invoked. This approach will affect any archive which has
sun-resources.xml bundled.
Java2db tool invocation happens inside J2EECPhase, so we need to move the
PreResCreationPhase before the J2EECPhase.
Further investigation shows this would not work as before J2EECPhase is
executed, the archive is not expanded and the deployment descriptors are not
parsed. The PreResCreationPhase relies on the archive expanded to parse the
sun-resources.xml and the deployment descriptors loaded to calculate the
expected sun-resources.xml paths.

2. Move the java2db execution later in time, so the resources are ready when the
java2db tool is invoked. The approach will affect any archive which uses
java2db tool.
The cmp code trigger java2db tool upon receiving various deployment events
sent from J2EECPhase, so the events need to be sent later at the beginning of
the ApplicationStartPhase.
Further investigation shows this would not work for the redeployment
scenario. In redeployment sceanrio, the deployment code sends a PRE_DEPLOY event
for the cmp code to drop old tables. At that point, the old application bits are
still in the respoistory and the new bits haven't been expanded. If we move the
PRE_DEPLOY event later around application loading time, the resource will be
available, but the old bits in the repository are already replaced by new bits,
and we cannot retrieve the old DDLs to drop tables.

Any other possible fixes would involve major changes in the deployment, for
example, insert the resource creation logic to the already crowded J2EECPhase.
They are just too risky at this point.

Will discuss with connector team who is driving this sun-resources.xml effort
to evaluate other options and decide the strategy for 9.1.

Comment by Hong Zhang [ 16/Jul/07 ]
      • Issue 3351 has been marked as a duplicate of this issue. ***
Comment by Hong Zhang [ 20/Jul/07 ]

Based on the discussions with various teams (connector team, cmp team, netbeans
team, JCAPS team), the netbeans 6 plug in will go back to the old resource
handling mechanism instead of the sun-resources.xml mechanism.

Downgrade the bug to P4 and revisit in the future release.

Comment by pjiricka [ 24/Jul/07 ]

cc myself (java.net requires me to add a comment to do that)

Comment by vladperl [ 26/Jul/07 ]

add to cc

Comment by Hong Zhang [ 17/Oct/11 ]

I think this is no longer a problem with our latest glassfish-resources.xml support, assigned to jagadish to confirm and close the issue.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4423] add-resources reference page Created: 13/Mar/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: vince kraemer Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,423
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

the description of xml-file-path is misleading and incorrect.



 Comments   
Comment by Paul Davies [ 20/Mar/08 ]

Reassigned to documentation project lead for version 9.1.1

Comment by harpreet [ 25/Mar/08 ]

minor issue marking for 9.2

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in 3.1.1.

Comment by vince kraemer [ 13/Jun/11 ]

I think the first and third bullet are 'correct'...

The second bullet is problematic...

If you specify only the file name, the XML file must reside in the as-install/domains/domain1/config directory on the DAS host. This requirement must be met even if you run the subcommand from another host.

Here are some problems...

1. do i have to put the files for resources that I want to add to domain2 into 'as-install/domains/domain1/config'.

2. if I put a file named pwdatd.xml into 'as-install/domains/domain1/config' and then attempt to use the command 'asadmin add-resources pwdatd.xml' the command fails

Here is an transcript that shows what happens...

bash-3.2$ /export/home/vkraemer/GlassFish_Server_3.1.1/bin/asadmin start-domain domain1
Waiting for domain1 to start .................
Successfully started the domain : domain1
domain Location: /export/home/vkraemer/GlassFish_Server_3.1.1/glassfish/domains/domain1
Log File: /export/home/vkraemer/GlassFish_Server_3.1.1/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
bash-3.2$ cp /export/home/vkraemer/NetBeansProjects/WebApplication97/setup/glassfish-resources.xml /export/home/vkraemer/GlassFish_Server_3.1.1/glassfish/domains/domain1/config/pollywaddledoodle.xml
bash-3.2$ /export/home/vkraemer/GlassFish_Server_3.1.1/bin/asadmin add-resources pollywaddledoodle.xml
remote failure: The system cannot find the path specified: pollywaddledoodle.xml
Command add-resources failed.
bash-3.2$

Comment by Paul Davies [ 13/Jun/11 ]

From my experiments, it would appear that if only a file name is specified, the file must be in the current working directory. I'll double-check with the owner of this subcommand.

Comment by Jagadish [ 21/Jun/11 ]

Updating the issue after discussions with Tom Mueller:

GlassFish 2.1 works in the following manner :
1) Absolute path works as expected
2) Relative path search is performed in the following order :
a) First search is done relative to the "pwd". If the file was found, it
will be used.
b) If the file was not found relative to "pwd", search is done relative
to "domain's config" directory.

There was a bug fix to address "upload" option in add-resources command
http://java.net/jira/browse/GLASSFISH-5696
which seem to have introduced a change in behavior.

The gap in GlassFish 3.0/3.1/3.1.1 is w.r.t the support of
looking at "domain's config directory". Again, this change in behavior
(regression) seems to be due to the above bug fix that uses "File" as a
type in order to support "upload" option.

Issue being the usage of :

@Param
File file

the parameter type "File" automatically provides/exposes the "--upload" flag (CLI framework feature) and it masks the fact of whether absolute path was specified or relative path was specified for the file. If we have to support the option of looking at the files in "config" directory, we need the absolute/relative path information. If we avoid using "File" as a parameter type, we will get the absolute/relative path information, but lose upload capability. We need to look at supporting "upload" option at the command level rather than framework level.

Workaround is to use absolute path or relative path w.r.t "current working directory" instead of relying on config directory.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4159] Failed to look up jms resources from other web servers Created: 12/Feb/08  Updated: 06/Jan/11

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 9.1peur1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Cheng Fang Assignee: Jagadish
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,159

 Description   

When looking up glassfish jms resources from other web servers like tomcat,
jetty, or resin, got the following exception:

com.sun.enterprise.connectors.ConnectorRuntimeException: Failed to look up
ConnectorDescriptor from JNDI
com.sun.enterprise.naming.factory.ConnectorObjectFactory.getObjectInstance(ConnectorObjectFactory.java:98)
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:403)
javax.naming.InitialContext.lookup(InitialContext.java:351)
foo.FooServlet.processRequest(FooServlet.java:56)
foo.FooServlet.doGet(FooServlet.java:95)
javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
javax.servlet.http.HttpServlet.service(HttpServlet.java:831)

All the necessary glassfish jar files have been copied to tomcat:
appserv-deployment-client.jar
appserv-admin.jar
javaee.jar
zappserv-rt.jar
appserv-ext.jar
imqjmsra.jar

Others have also reported the exactly the same problem on glassfish forum, with
no solution yet:

JMS remote client
http://forums.java.net/jive/thread.jspa?messageID=255213

JMS lookup problem
http://forums.java.net/jive/thread.jspa?threadID=36502&tstart=0



 Comments   
Comment by Cheng Fang [ 12/Feb/08 ]

In ConnectorObjectFactory.getObjectInstance(...), it seems the wrong
InitialContext is instantiated. Here we always call the no-arg constructor of
InitialContext(), which will result in the Tomcat naming manager if run inside
tomcat. We should use the nameCtx param passed in. nameCtx is currently never
referenced in this method.

That may also explains why the same code would work in a standalone client
(where only one naming manager, the default one, is available), but not from a
foreign web container.

public class ConnectorObjectFactory implements ObjectFactory {

public Object getObjectInstance(Object obj,
Name name,
Context nameCtx,
Hashtable env) throws Exception
{
Reference ref = (Reference) obj;
if(_logger.isLoggable(Level.FINE))

{ _logger.log(Level.FINE,"ConnectorObjectFactory: " + ref + " Name:" + name); }

String poolName = (String) ref.get(0).getContent();
String moduleName = (String) ref.get(1).getContent();

Switch sw = Switch.getSwitch();

if(runtime.getEnviron() == ConnectorRuntime.CLIENT) {
ConnectorDescriptor connectorDescriptor = null;
try

{ Context ic = new InitialContext(); String descriptorJNDIName = ConnectorAdminServiceUtils. getReservePrefixedJNDINameForDescriptor(moduleName); connectorDescriptor = (ConnectorDescriptor)ic.lookup(descriptorJNDIName); }

catch(NamingException ne)

{ _logger.log(Level.FINE, "Failed to look up ConnectorDescriptor from JNDI", moduleName); throw new ConnectorRuntimeException( "Failed to look up ConnectorDescriptor from JNDI"); }
Comment by Sivakumar Thyagarajan [ 04/Apr/08 ]

Requesting Jagadish to investigate

Comment by harpreet [ 09/Apr/08 ]

Not critical for v2.1 marking for next release.

Comment by travisb [ 08/Sep/08 ]
      • Issue 4159 has been confirmed by votes. ***
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Jagadish [ 29/Jan/10 ]

Fixed in v3.1 (trunk)

svn log -v -r 35516

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18049





[GLASSFISH-4146] Resource Adapter configuration properties are hidden Created: 10/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: mkarg Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,146
Status Whiteboard:

as911-na,v3_exclude,V2.1.1_exclude


 Description   

When deploying a (non-JMS) resource adapter using the browser based admin gui,
and ra.xml conatains the following:

<resourceadapter>
...
<config-property>
<config-property-name>PortNumber</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>587</config-property-value>
...

the admin gui will show a page asking for the actual value of "PortNumber".
There are two bugs:

(a) The default of 587 is not shown in the admin gui. Instead, the value field
is shown empty. The user is not aware that pressing FINISH or CLOSE without
typing anything will result in using that particular value.

(b) If the user types in 3333 and presses FINISH, and then does undeploy, and
then does deploy, the page again shows NO value (neither 587 nor 3333). But when
NOW pressing FINISH, in fact 3333 will be used. It seems GlassFish stores that
value somewhere between undeploy and deploy. Unfortunately the user doesn't get
information about the fact that 3333 will get used and might think that the
default of 587 will get used.

This behaviour is totally confusing the user. A common solution to both problems
could be that the admin gui shows the exact value that will take place unless
manually changed inside of the value field (instead of shown a blank field).



 Comments   
Comment by Anissa Lam [ 14/Feb/08 ]

GUI is using the connector runtime API to get the list of properties.
Map props =
ConnectorRuntime.getRuntime().getResourceAdapterBeanProperties(location);
It returns the name and the type. GUI remove the type so user can fill in the
value. IT ever returns the default value thats in the ra.xml.
Maybe this API should return the name and value instead of name and type.

As for #2, it is also the backend problem.

There was a bug filed before relating to this API.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6212118

The comment section says:

Suggested:
Show the resource adapter default values or an empty box. It would be great if
the type is displayed as well, so that the user know what type is accepted by
the resource adapter.
xxx@xxx 2004-12-23 09:50:53 GMT

Changing the category to jca as she uses the a jca class (and not admin) for
this information.
xxx@xxx 2005-2-03 18:41:21 GMT

================================================
I can change the GUI to NOT display the type, so the property list will have
empty value.
However, looking at the attached doc, it seems the user is complaining for 2 things:
1. the GUI shouldn't show the type, (which i am going to fix)
2. the list of properties shown is NOT correct. eg The user doesn't think that
Xid should be on the properties list. This has to be fixed by the connector
runtime.

anissa.lam@sun.com 2005-2-07 21:59:35 GMT
===============================================
The changes in the GUI has been checked in on 2/7, and should be in the UR1
build. I am leaving the bug open for Siva to work on #2 as mentioned above.

anissa.lam@sun.com 2005-2-08 00:09:46 GMT

Regarding #2, the connectors backend introspects the resource adapter JavaBean
implementation to discover the RA Bean properties [over and above what is
specified in the resource adapter deployment descriptor]. So, if a resource
adapter JavaBean has a getter method [for a String or java language primitive or
primitive Wrapper Type], it is assumed to be a configurable property and is
shown as is, in the admin GUI console. Hence this is not a bug. We have already
written to the customer explaining this behavior. I am closing this issue as we
have addressed this issue in UR1 with Anissa's putback.
xxx@xxxx 2005-2-08 05:34:54 GMT

------------------------------------
I am transferring this issue to 'jca'.
If they change the behavior of the API, ie gives me the value instead of the
type, or implement another API for GUI to use,
this issue can transfer back to GUI so i can implement the change.

Comment by Anissa Lam [ 14/Feb/08 ]

assign to module owner

Comment by Sivakumar Thyagarajan [ 15/Feb/08 ]

Transferring this to Jagadish for a fix. A new API to provide ResourceAdapter
config bean property name along with their properties would need to be provided
for the admin GUI to display them.

Regarding #2: If a value of a property is overridden during deployment,
behind-the-scenes a resource-adapter-config is created for the RA, and this is
used when you later undeploy-deploy.

If the RA-config needs to be removed during undeployment of the RA, the RA
undeployment should be done with --cascade set to true (Currently false by default).

Comment by mkarg [ 15/Feb/08 ]

Regarding #2: The average user would expect that undeploy (in contrast to
redeploy) automatically cleans up everything automatically. Nobody would expect
that after an undeploy (in contrast to a redeploy) configuration is kept behind
the scenes. That should be the default setting for the average users, since it
is the most intimating and intuitive behaviour. Keeping things in the back at
undeployment (in contrast to redeployment) is counterintuitive and unexpected.

Comment by harpreet [ 09/Apr/08 ]

Approving for v2.1

Comment by harpreet [ 20/Oct/08 ]

removing from approved list as issue not critical to release.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by mkarg [ 27/Apr/09 ]

Increased priority to P3 according to
https://glassfish.dev.java.net/public/IssueTrackerPriority.html: The bug is
neither invisible nor internal, but will cause critical problems at run time.
There is no workaround.

Comment by Jagadish [ 04/Oct/09 ]

V3 does not create resource-adapter-config automatically.
Instead, resource-adapter-config information is shown as separate node within
resources which can be used to override the values in ra.xml.
Marking as not applicable for v3

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-16963] Unknown messages are output when specifying invalid config-property-name of ra Created: 06/Jul/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: ito_m Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 7
Platform: All
GFv3.2 revision: 47843


Attachments: File generic-ra.rar    

 Description   

Since connector1.5, we can specify config properties for resource adapter class.
When a ra.xml contains an empty <config-property-name> in <config-property>,
such as
...

<resourceadapter-class>connector.SimpleResourceAdapterImpl</resourceadapter-class> <config-property>
<config-property-name></config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>10000</config-property-value>
</config-property> ...,

to start a instance where such an application is deployed causes the following exception. This exceptoin message is not clear about the root cause of this problem.

If a config property name is not specified, I think a connector runtime should skip analyzing its property because the corresponding setter method of the resource adapter will be never found. Or it should output a more meaningful error message so that we can trace the reason of it.

RAR6035 : Resource adapter start failed.
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Wrong parameters for pool creation : String index out of range: 1
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.loadRAConfiguration(ActiveOutboundResourceAdapter.java:331)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:114)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(ActiveInboundResourceAdapterImpl.java:90)
at com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(ActiveRAFactory.java:135)
at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:106)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:212)
at com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:364)
at com.sun.enterprise.connectors.module.ConnectorDeployer.load(ConnectorDeployer.java:194)
at com.sun.enterprise.connectors.module.ConnectorDeployer.load(ConnectorDeployer.java:92)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:462)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:204)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:130)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:83)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:66)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:130)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
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:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1
at java.lang.String.substring(String.java:1934)
at com.sun.enterprise.connectors.util.SetMethodAction.getCamelCasedPropertyName(SetMethodAction.java:286)
at com.sun.enterprise.connectors.util.SetMethodAction.getAccessorMethod(SetMethodAction.java:236)
at com.sun.enterprise.connectors.util.SetMethodAction.getTypeOf(SetMethodAction.java:220)
at com.sun.enterprise.connectors.util.SetMethodAction.run(SetMethodAction.java:85)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.loadRAConfiguration(ActiveOutboundResourceAdapter.java:328)

Reproducible order:
1. Deploy attachment application on a server instance.
2. Start the server instance.
3. Please see its server.log.

Attachment:
An attached application was created by changing ra.xml in the following devtests rar.
trunk/v2/appserv-tests/devtests/connector/v3/connector1.5/ra/generic-ra.rar






[GLASSFISH-20594] ClassNotFoundException when adding a ressource to a deployed resourceadapter Created: 30/May/13  Updated: 30/May/13

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: sd_ Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux



 Description   

A ClassNotFoundException will be thrown when adding a ressource to the sun-jms resource adapter :

reproduction :
1)
deploy --target mycluster sun-jms-adapter.rar
sun-jms-adapter was successfully deployed in 5,232 milliseconds.
2)
add-resources --target mycluster sun_jms_adapter.xml
Unable to load class [ com.stc.jmsjca.unifiedjms.RAUnifiedActivationSpec ]

It seems to be, that the jars of sun-jms-adapter.rar are not in the admins classpath during deployment. As a workaround I can copy
the jars com.stc.jmsjca.core.jar and com.stc.jmsjca.raunifiedjms.jar before to the admins lib folder and afterwards the deployment will succeed.

[glassfish 4.0] [WARNING] [] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.deployment.util] [tid: _T
hreadID=34 _ThreadName=admin-listener(2)] [timeMillis: ...] [levelValue: 900] [[
Unable to load class [ com.stc.jmsjca.unifiedjms.RAUnifiedActivationSpec ]
java.lang.ClassNotFoundException: com.stc.jmsjca.unifiedjms.RAUnifiedActivationSpec
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at com.sun.enterprise.connectors.deployment.util.ConnectorValidator.getClass(ConnectorValidator.java:239)
at com.sun.enterprise.connectors.deployment.util.ConnectorValidator.validateActivationSpec(ConnectorValidator.java:155)
at com.sun.enterprise.connectors.deployment.util.ConnectorValidator.accept(ConnectorValidator.java:79)
at com.sun.enterprise.connectors.deployment.util.ConnectorValidator.accept(ConnectorValidator.java:72)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
at com.sun.enterprise.connectors.deployment.util.ConnectorArchivist.postOpen(ConnectorArchivist.java:173)
at com.sun.enterprise.connectors.deployment.util.ConnectorArchivist.postOpen(ConnectorArchivist.java:72)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:273)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:280)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:241)
at com.sun.enterprise.connectors.util.ConnectorDDTransformUtils.getConnectorDescriptor(ConnectorDDTransformUtils.java:213)
at com.sun.enterprise.connectors.service.ConnectorService.getConnectorDescriptor(ConnectorService.java:283)
at com.sun.enterprise.connectors.service.ConnectorConfigurationParserServiceImpl.getConnectionDefinitionNames(ConnectorConfigurationParserServiceImpl.
java:161)
at com.sun.enterprise.connectors.ConnectorRuntime.getConnectionDefinitionNames(ConnectorRuntime.java:695)
at org.glassfish.connectors.admin.cli.ConnectorConnectionPoolManager.isValidConnectionDefinition(ConnectorConnectionPoolManager.java:359)
at org.glassfish.connectors.admin.cli.ConnectorConnectionPoolManager.validateConnectorConnPoolAttributes(ConnectorConnectionPoolManager.java:306)
at org.glassfish.connectors.admin.cli.ConnectorConnectionPoolManager.isValid(ConnectorConnectionPoolManager.java:183)
at org.glassfish.connectors.admin.cli.ConnectorConnectionPoolManager.create(ConnectorConnectionPoolManager.java:132)
at org.glassfish.resources.admin.cli.ResourcesManager.createResources(ResourcesManager.java:109)
at org.glassfish.resources.admin.cli.AddResources.execute(AddResources.java:113)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)



 Comments   
Comment by Hong Zhang [ 30/May/13 ]

Assign to jagadish for initial evaluation..





[GLASSFISH-18822] EAR-private connector resource pools Created: 22/Jun/12  Updated: 22/Jun/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF3.1.1 Win7 Pro SP1 (64 Bit) JDK 1.6.0_26



 Description   

GF3.1.1 can deploy JCA connectors inside of EARs as "private". This means, the connectors are not found in the global config but only inside of the Application/AppName branch of the admin GUI.

But, when undeploying, asadmin warns that the adapter MIGHT be in use by a different application and so asks for giving "-cascade=true". This happens because GF doesn't know something like "EAR-private connector resource pools", but only "EAR-private connectors". But, to be able to use an inbound, such a (unfortunately global) resource is needed.

To improve REAL EAR-private connectors, it would be great if a future version of GF would provide "EAR-private connector resource pools".

(Possibly those already do exist, but simply the GUI doesn't present a way to declare these?)






[GLASSFISH-18554]  Exception "This adapter is not 1.5 compliant" when ActiveResourceAdapter is NULL Created: 23/Mar/12  Updated: 23/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: sghino Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 11.10


Tags: resource-adapter

 Description   

This error occurs when a resource adapter is still deploying.

So at line 78 of com.sun.enterprise.connectors.service.ConnectorAdminObjectAdminServiceImpl
"ActiveResourceAdapter ar = _registry.getActiveResourceAdapter(connectorName)"

ar is NULL and at line 84 (ar instanceof ActiveOutboundResourceAdapter) is false and throw new ConnectorRuntimeException("This adapter is not 1.5 compliant");

But this Exception is misleading (I lost a lot of time),it would be better to have something like "No Adapter Found".






[GLASSFISH-18543] Deployment fails without error message when (JMS) connection pool has steady-pool-size greater than max-pool-size Created: 21/Mar/12  Updated: 22/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mdo Assignee: Jagadish
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_03"
Java(TM) SE Runtime Environment (build 1.7.0_03-b04)
Java HotSpot(TM) Client VM (build 22.1-b02, mixed mode)

GlassFish Version: GlassFish Server Open Source Edition 3.1.2 (build 23)


Tags: admin-gui, asadmin, connectionpool, connectors, deployment

 Description   

When deploying an EAR that has an invalid connector resource definition in glassfish-resources.xml the process fails without a clear error message.

==Admin Console==
An error has occurred
Error occurred during deployment: null. Please see server.log for more details.

==server.log==

[#|2012-03-21T17:03:55.756+0100|INFO|glassfish3.1.2|org.glassfish.admingui|_ThreadID=48;_ThreadName=Thread-2;|uploadFileName=myAppEE6.ear|#]

[#|2012-03-21T17:03:56.648+0100|INFO|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=71;_ThreadName=Thread-2;|WEB0671: Loading application myAppEE6#myApp-war.war at [myApp-war]|#]

[#|2012-03-21T17:03:56.723+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=71;_ThreadName=Thread-2;|The log message is empty or null. Please log an issue against the component in the logger field.|#]

[#|2012-03-21T17:03:56.736+0100|INFO|glassfish3.1.2|org.glassfish.admingui|_ThreadID=48;_ThreadName=Thread-2;|Exception Occurred :Error occurred during deployment: null. Please see server.log for more details. |#]

[#|2012-03-21T17:03:56.744+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=48;_ThreadName=Thread-2;|java.lang.RuntimeException: Error occurred during deployment: null. Please see server.log for more details.
at org.glassfish.admingui.common.util.RestUtil.parseResponse(RestUtil.java:414)
[...]

==reproduce==

Create an empty EE6 application with a glassfish-resources.xml in the app that has this resource:

<connector-resource enabled="true" jndi-name="jms/myTopicFactory" object-type="user" pool-name="jms/myTopicFactory">
<description/>
</connector-resource>
<connector-connection-pool associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-definition-name="javax.jms.TopicConnectionFactory" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="true" max-connection-usage-count="0" max-pool-size="4" max-wait-time-in-millis="60000" name="jms/myTopicFactory" ping="false" pool-resize-quantity="2" pooling="true" resource-adapter-name="jmsra" steady-pool-size="5" validate-atmost-once-period-in-seconds="0"/>

Notice:
*max-pool-size=4
*steady-pool-size=5

You have to restart GF after this because it thinks the application name you tried to deploy the application with is occupied when you try to deploy again:
Error occurred during deployment: Application name myAppEE6 is already in use. Please pick a different name.. Please see server.log for more details.

The app was deployed to GF 2.1.1 before without problems.



 Comments   
Comment by Hong Zhang [ 21/Mar/12 ]

assgin to jagadish to take a look

Comment by mdo [ 22/Mar/12 ]

I withdraw that this definitely worked with the 2.1 branch, can't warrant that we ever deployed app scoped resources as we either used NetBeans to deploy the descriptor resources in our development environment or manually created resources in production.





[GLASSFISH-438] extend add-resources with a '-force' flag Created: 20/Mar/06  Updated: 24/Mar/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.0pe
Fix Version/s: None

Type: Improvement Priority: Trivial
Reporter: vince kraemer Assignee: Jagadish
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 438

 Description   

It would be nice to be able to treat a resources file "like" an ear/ejb-jar/web...

For deployment, there is a force flag, so users can

asadmin deploy .... foo.ear
asadmin deploy .... foo.ear

till they turn blue...

They don't have that flexibility with add-resources...



 Comments   
Comment by km105526 [ 27/Jul/06 ]

This is a tough one.

I believe deployment is a special case. For any other configuration change (e.g.
adding resources, http-listeners, virtual-servers etc.), creation of an existing
element (from the uniqueness standpoint) does not result in recreation of it.

If we make add-resources have this flag, we should modify all the
create-resource/pool commands as well.

In principle, I tend to agree with this and I was wondering myself why resources
were left out of this paradigm.

Introducing a new option --force on these commands will mean a little different
thing for them and have a different semantics than deploy command because deploy
command has --force=true by default. For these commands, having --force=true by
default will mean a change not compatible with previous releases

Comment by janey [ 14/Aug/06 ]

Due to backward compatiblity issue, will consider this enhancement in future
release. Change priority to P5.

Comment by vince kraemer [ 09/Mar/07 ]

What backward compatibility issue?

It seems like having the default be --force=false resolves the 'issue'. I just
want the capability... not a change of the default semantics.

Please remember to re-evaluate this request, so that it gets implemented in V3
or V2.x

Comment by vince kraemer [ 18/Mar/08 ]

https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=6237

Comment by Tom Mueller [ 14/Jan/11 ]

Please evaluate for possible inclusion in 3.2.





Generated at Wed Jun 03 03:32:25 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.