[GLASSFISH-3942] Provide a cluster-aware Database "Ping" feature Created: 24/Dec/07  Updated: 26/Apr/11

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

Type: Improvement Priority: Critical
Reporter: Alexis MP Assignee: Shalini
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,942
Status Whiteboard:

clusteradmin


 Description   

Database Ping works well with a single instance. In cluster mode, having the DAS
be able to ping the database doesn't mean all cluster instances can do it as
well (the JDBC driver may not be present or correctly loaded on each local
instance for instance).



 Comments   
Comment by km [ 13/Jan/08 ]

....

Comment by Tom Mueller [ 14/May/10 ]

Once the infrastructure work for dynamic configuration is done for 3.1, this
behavior should be implemented automatically. So this feature just needs to be
tested later during the release cycle.

The relevant subcommand is ping-connection-pool.

Comment by Tom Mueller [ 17/May/10 ]

Marking as referenced by the clustering admin one-pager.

Comment by Tom Mueller [ 25/Jan/11 ]

Clear the Fix version since this issue isn't going to be fixed for 3.1.





[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-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-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-4128] ability to plugin custom implementations of various functionalities for connection pool Created: 08/Feb/08  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4147 Request prioritization in application... Open
Issuezilla Id: 4,128
Status Whiteboard:

v3-prd-item


 Description   

Expose datastructure, pool-wait-queue, pool resizing behaviour as interfaces for
multiple implementations.

Define pool life cycle, events, event listeners so that applications can listen
to these events, control pool behavior.



 Comments   
Comment by Jagadish [ 08/Feb/08 ]

tagging as v3-prd-item

Comment by Jagadish [ 05/Mar/08 ]

removing dependency

Comment by Jagadish [ 28/Dec/09 ]

Transferring to Shalini

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-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-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-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-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-5153] Class Loader Hierarchy not defined yet for connectors Created: 13/Jun/08  Updated: 06/Mar/12

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

Type: New Feature Priority: Major
Reporter: sprabhu7 Assignee: sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 5,153

 Description   

Class Loader Functionality Issue



 Comments   
Comment by Jagadish [ 13/Jun/08 ]

Reassigning to Sahoo

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-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-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-930] don't require DOCTYPE declaration in sun resources files used by add-resources Created: 14/Aug/06  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1pe, 3.1.2_dev
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-18197] connector container should use system provided parser for parsing resources xml Created: 14/Jan/12  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.0
Fix Version/s: 4.1.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-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-18010] Resources Added using "Add Resource" feature do not show up for clusters and instances. Created: 15/Dec/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2_dev
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-18425] JCA: Inspect JDK 7 getMethods()/getDeclaredMethods() usage Created: 28/Feb/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_dev
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-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-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-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-21355] Race condition in ConnectionPool (connectors-runtime) Created: 05/May/15  Updated: 18/Jun/15

Status: In Progress
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mikekanani Assignee: Debayan_Gupta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: 2 days
Original Estimate: Not Specified
Environment:

Debian GNU/Linux 5.0.9, Java 1.6.0_26



 Description   

First of all, apologies if this is in the wrong place/does not contain enough info/is completely wrong/something else is wrong. This is my first attempted bug report so please be kind!

I have been using glassfish in a highly concurrent environment (~250 request/second) and I am running into an issue where occasionally threads completely stop. After some investigation I believe the issue is caused by a combination of having a jdbc-connection-pool with max-wait-time-in-millis=0 and a bug in glassfish. I have been able to narrow down where the thread is stuck to line 432 in ConnectionPool by taking a jstack of the application:

jdbc-connection-pool settings:

    <jdbc-connection-pool validation-table-name="dual" datasource-classname="oracle.jdbc.pool.OracleDataSource" res-type="javax.sql.DataSource" name="databaseName" is-connection-validation-required="true" max-wait-time-in-millis="0" fail-all-connections="true" validate-atmost-once-period-in-seconds="60">

Jstack extract:

"Thread-A" daemon prio=10 tid=0x00007f57d05d9000 nid=0x418b in Object.wait() [0x000000004cf82000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x000000069e44e0f8> (a java.lang.Object)
	at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:432)
	- locked <0x000000069e44e0f8> (a java.lang.Object)
	at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:245)
	at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:170)
	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)
	at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:123)
	at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
	at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:330)
	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:293)
	at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:565)
	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1508)
	at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:305)
	- locked <0x000000069e44db50> (a org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor)
	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:579)
	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:535)
	at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1717)
	at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:566)
	at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:207)
	at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:193)
	at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:264)
	at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelect(DatasourceCallQueryMechanism.java:246)
	at org.eclipse.persistence.queries.DataReadQuery.executeNonCursor(DataReadQuery.java:197)
	at org.eclipse.persistence.queries.DataReadQuery.executeDatabaseQuery(DataReadQuery.java:152)
	at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:844)
	at org.eclipse.persistence.queries.DataReadQuery.execute(DataReadQuery.java:137)
	at org.eclipse.persistence.internal.sessions.AbstractSession.internalExecuteQuery(AbstractSession.java:2831)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1516)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1498)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1449)
	at org.eclipse.persistence.sequencing.QuerySequence.select(QuerySequence.java:309)
	at org.eclipse.persistence.sequencing.QuerySequence.updateAndSelectSequence(QuerySequence.java:254)
	at org.eclipse.persistence.sequencing.StandardSequence.getGeneratedVector(StandardSequence.java:71)
	at org.eclipse.persistence.sequencing.Sequence.getGeneratedVector(Sequence.java:257)
	at org.eclipse.persistence.internal.sequencing.SequencingManager$Preallocation_NoTransaction_State.getNextValue(SequencingManager.java:664)
	at org.eclipse.persistence.internal.sequencing.SequencingManager.getNextValue(SequencingManager.java:1067)
	at org.eclipse.persistence.internal.sequencing.ClientSessionSequencing.getNextValue(ClientSessionSequencing.java:70)
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.assignSequenceNumber(ObjectBuilder.java:349)
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.assignSequenceNumber(ObjectBuilder.java:308)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.assignSequenceNumber(UnitOfWorkImpl.java:465)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNotRegisteredNewObjectForPersist(UnitOfWorkImpl.java:4231)
	at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.registerNotRegisteredNewObjectForPersist(RepeatableWriteUnitOfWork.java:513)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4176)
	at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:440)
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.persist(EntityManagerWrapper.java:269)

I believe the issue is caused by a race condition where:

  • Thread A adds a waitMonitor to the waitQueue (Line 425)
  • Thread-B removes waitMonitor from the waitQueue (Line 1224)
  • Thread-B gets the lock for waitMonitor (Line 1231)
  • Thread-B calls waitMonitor.notifyAll() (Line 1235)
  • Thread-B releases the lock on waitMonitor
  • Thread-A gets the lock for waitMonitor (Line 429)
  • Thread-A calls waitMonitor.wait() (Line 432)

All other threads in the application remain unaffected.

com.sun.enterprise.resource.pool.ConnectionPool extract 1:

423                 if (!blocked) {
424                     //add to wait-queue
425                     Object waitMonitor = waitQueue.addToQueue();
426                     if (poolLifeCycleListener != null) {
427                         poolLifeCycleListener.connectionRequestQueued();
428                     }
429                     synchronized (waitMonitor) {
430                         try {
431                             logFine("Resource Pool: getting on wait queue");
432                             waitMonitor.wait(remainingWaitTime);
433 
434                         } catch (InterruptedException ex) {
435                             //Could be system shutdown.
436                             break;
437                         }
438 
439                         //try to remove in case that the monitor has timed
440                         // out.  We dont expect the queue to grow to great numbers
441                         // so the overhead for removing inexistant objects is low.
442                         if (_logger.isLoggable(Level.FINE)) {
443                             _logger.log(Level.FINE, "removing wait monitor from queue: " + waitMonitor);
444                         }
445                         if (waitQueue.removeFromQueue(waitMonitor)) {
446                             if (poolLifeCycleListener != null) {
447                                 poolLifeCycleListener.connectionRequestDequeued();
448                             }
449                         }
450                     }

com.sun.enterprise.resource.pool.ConnectionPool extract 2:

1219    protected void More ...notifyWaitingThreads() {
1220        // notify the first thread in the waitqueue
1221        Object waitMonitor = null;
1222        synchronized (waitQueue) {
1223            if (waitQueue.getQueueLength() > 0) {
1224                waitMonitor = waitQueue.remove();
1225                if(poolLifeCycleListener != null) {
1226                    poolLifeCycleListener.connectionRequestDequeued();
1227                }
1228            }
1229        }
1230        if (waitMonitor != null) {
1231            synchronized (waitMonitor) {
1232                if (_logger.isLoggable(Level.FINE)) {
1233                    _logger.log(Level.FINE, "Notifying wait monitor : " + waitMonitor.toString());
1234                }
1235                waitMonitor.notifyAll();
1236            }
1237        } else {
1238            logFine(" Wait monitor is null");
1239        }
1240    }

Unfortunately I cannot find a way to consistently reproduce the issue, however even if it is not the cause, the above still appears to be a possible race condition. I have also checked and the surrounding code appears to be unchanged in version 4.1.






[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-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-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-20679] After returned from setupSecurityContext(), should check whether CallerPrincipalCallback is handled Created: 03/Jul/13  Updated: 11/Sep/14

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

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

Tags: jca

 Description   

According to the section 16.4.5.1 "Case A: Establishing a Single Principal as the Caller Identity" of JCA1.6 Spec, if a resource adapter intends to establish an authenticated caller identity, and the principal Set of the executionSubject contains exactly the one Principal, then the setupSecurityContext() do not has to use the container provided CallbackHandler to handle a CallerPrincipalCallback.

In this case, the container must check whether or not it handled the CallerPrincipalCallback after returned from setupSecurityContext(). If it determines that it did not handle any Callbacks, the container must transform the contents of the executionSubject, as if they are handled through the Callbacks on behalf of the resource adapter.

But according to the method setupSecurityWorkContext (as below) of the class WorkContextHandlerImpl, GlassFish does not support the Case A. If setupSecurityContext() do not call CallbackHandler, GlassFish will ignore the content of executionSubject and setup up an unauthenticated identity for Work instance.

private void setupSecurityWorkContext(SecurityContext securityWorkContext,
WorkContextLifecycleListener listener, String raName)
throws WorkCompletedException{
try

{ Subject executionSubject = new Subject(); Subject serviceSubject = new Subject(); Map securityMap = getWorkContextMap(raName); CallbackHandler handler = new ConnectorCallbackHandler(executionSubject, runtime.getCallbackHandler(), securityMap); securityWorkContext.setupSecurityContext(handler, executionSubject, serviceSubject); // Need check whether the CallbackHandler is called or not here for Case A. notifyContextSetupComplete(listener); }

catch (Exception e)

{ ... ... }

}






[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-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-18817] Broken redeploy leaves partial EAR installation! Created: 21/Jun/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.1_dev
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-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-19508] Race condition due to unsychronized HashMap access in ConnectorObjectFactory.getObjectInstance Created: 09/Jan/13  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2, 3.1.2.2, 4.0_dev
Fix Version/s: 4.1.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?

Comment by eduardohbcs [ 21/Oct/15 ]

Hello,

I'm curious to know what the change was for this problem but I'm having trouble to find it on Glassfish's public SVN repository.

I've tried to find all check-ins rooted at (https://svn.java.net/svn/glassfish~svn) for the revision numbers above without any luck. Could you guys confirm what repository I should be looking at ?

Thanks,
Eduardo





[GLASSFISH-19640] Need test-cases that use "list-jndi-entries" in "resources-admin-cli" tests Created: 06/Feb/13  Updated: 21/Sep/15

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

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

Issue Links:
Dependency
depends on GLASSFISH-19647 List-Jndi-Entries command is not retu... Resolved

 Description   

We currently have "resources-admin-cli" tests that tests various combinations of enabling resources in various targets.
We look for "list-xxx-resources" or "list-resource-refs" to validate them which primarily tests the configuration (domain.xml)

It is also necessary to check whether the JNDI entries are also present (or not present) when doing list-resource-refs tests.
We can use "list-jndi-entries" to make sure that the runtime also works as expected.






[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-17266] custom resource factory cannot access webmodule during lifecycle events Created: 01/Sep/11  Updated: 21/Oct/11

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

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

jdk6,winxp


Attachments: Zip Archive NetBeansProjects.zip    
Tags: 3_1_x-exclude

 Description   

When one has a custom factory class deployed under domain/lib and a resource is created which uses this factory to create an injectable class located in a webapp, then the following (or similar) exception is thrown during appserver startup:

javax.naming.CommunicationException: serial context communication ex [Root exception is java.lang.ClassNotFoundException: a.Config]
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.naming.NamingManagerImpl.bindObjects(NamingManagerImpl.java:391)
at com.sun.enterprise.web.WebModuleContextConfig.configureResource(WebModuleContextConfig.java:227)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:167)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:159)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:6476)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4977)
at com.sun.enterprise.web.WebModule.start(WebModule.java:353)
at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304)
at com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:341)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: a.Config
at com.sun.enterprise.util.ConnectorClassLoader.loadClass(ConnectorClassLoader.java:222)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at a.ConfigFactory.getObjectInstance(ConfigFactory.java:21)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:414)
... 17 more

The cause is that when the LifecycleStarter task is created in VirtualServer then the current thread's contextClassLoader is the ConnectorClassLoader and so that's the one which gets inherited by the RunnableBase.

I think if an injectable resource class is allowed to be local to a webapp then the appropriate classLoader should be utilized when doing any kind of work with the factories.

Proposed solution: VirtualServer might set the current thread's contextClassLoader to the webapp's loader every time it creates a runnable task for a WebModule and then set it back to the old value.

Couldn't reproduce it in v3.1. Attached are the factory jar under domain/lib and the webapp and here's the resource entry in domain.xml:

<custom-resource enabled="true" factory-class="a.ConfigFactory" jndi-name="testconfig" object-type="user" res-type="a.Config"/>



 Comments   
Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

This bug is not applicable for 3.1 from what I understand from submitter's note.

Comment by Jagadish [ 21/Oct/11 ]

https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/connector/v3/built-in-custom-resources
Above test-case that has a custom resource's factory which loads the JavaBean class copied in domain/lib directory, works fine in GlassFish 3.0 and above.

Marking as not applicable for 3.x and above.

Comment by Jagadish [ 21/Oct/11 ]

Transferring to Gajanan for evaluation in GlassFish 2.x.
Gajanan: Please transfer to appropriate team member.





[GLASSFISH-17142] ClassLoader / memory leak in ConnectorTimerProxy Created: 01/Aug/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.1_dev
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-21356] Validation : Ensure that valid resource-adapter name is specified in @ConnectionFactoryDefinition/@AdministeredObjectDefinition Created: 08/May/15  Updated: 14/Feb/17

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

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Vinay Vishal
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-21682] Connection Pool bug occurs when Connection Validation is enabled and "On Any Failure Close All Connections" option is used Created: 21/Feb/17  Updated: 21/Feb/17

Status: Open
Project: glassfish
Component/s: jca, jdbc
Affects Version/s: 3.1, 4.0, 4.1, 5.0
Fix Version/s: None

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


 Description   

For JDBC and Connector Connection Pools, a connection pool bug occurs when Connection Validation is enabled and "On Any Failure Close All Connections" is used, and a connection is retrieved (getConnection()) which fails validation. The bug is that in this case, too many connections are created and destroyed in rebuilding the connection pool, and one connection is created and marked in-use which can then never be closed and so reduces the number of free connections available in the pool.

This bug all stems from an obvious problem in the source code, in the "getResourceFromPool" method of the "com.sun.enterprise.resource.pool.ConnectionPool" class (connectors-runtime.jar).
This method has the following code. Note that in the case in question, "failAllConnections" is true, and the call to "isConnectionValid" returns false.

        try{
            while ((h = ds.getResource()) != null) {

                if (h.hasConnectionErrorOccurred()) {
                    ds.removeResource(h);
                    continue;
                }

                if (matchConnection(h, alloc)) {

                    boolean isValid = isConnectionValid(h, alloc);
                    if (h.hasConnectionErrorOccurred() || !isValid) {
                        if (failAllConnections) {
                            createSingleResourceAndAdjustPool(alloc, spec);
                            //no need to match since the resource is created with the allocator of caller.
                            break;
                        } else {
                            ds.removeResource(h);
                            //resource is invalid, continue iteration.
                            continue;
                        }
                    }
                    if(h.isShareable() == alloc.shareableWithinComponent()){
                        // got a matched, valid resource
                        result = h;
                        break;
                    }else{
                        freeResources.add(h);
                    }
                } else {
                    freeResources.add(h);
                }
            }
        }finally{
            //return all unmatched, free resources
            for (ResourceHandle freeResource : freeResources) {
                ds.returnResource(freeResource);
            }
            freeResources.clear();
        }

        if (result != null) {
            // set correct state
            setResourceStateToBusy(result);
        } else {
            result = resizePoolAndGetNewResource(alloc);
        }
        return result;

You will notice that the return value of the "createSingleResourceAndAdjustPool" method call is NOT USED. This is the cause of the bug. It is MEANT to be assigned to the "result" variable. Because the resource created by the "createSingleResourceAndAdjustPool" method is not assigned to "result", then "result" is null, and the code after the while loop thus calls "resizePoolAndGetNewResource", as if no suitable resource was found in the pool and the pool needs to be resized (which of course is NOT the case at all).

(I looked back at the history of changes to this source file, and found that originally the return value of "createSingleResourceAndAdjustPool" was erroneously assigned to a different variable to "result", and that variable was thereafter not referenced in the source code. Some time after, someone ran the "FindBugs" tool over the source code, which reported that that variable was set but never referenced, so the variable assignment was removed. It silenced FindBugs, but didn't address the actual problem.)

In addition to the missing assignment of the return value from "createSingleResourceAndAdjustPool", I also found that the "getNewResource" method (called by the "createSingleResourceAndAdjustPool" method) is not incrementing the NumConnFree monitoring count.

 

I have developed a small test application (servlet) that can be used to reproduce the Connection Pool bug.
The following files are included:

TestConnPoolBug.war:   the test application
setup.bat:             setup the JDBC resources and pool monitoring and deploy the application
cleanup.bat:           remove the JDBC resources, pool monitoring settings and undeploy the application
do_mon.bat:            display some monitoring statistics for the connection pool
restart_db.bat:        stop and restart the JavaDB database

 
### Please see the comments below for this bug report, for a link to the GitHub repository containing these files. ###
 

For simplicity, the test application uses JavaDB that comes with Glassfish (with minor modifications to the connection pool settings, any database supported by Glassfish may be used).

The test application code simply gets 5 connections then closes them, as shown in the servlet source code snippet below. The full source code is included in the WAR file.


    /**
     * Processes requests for both HTTP <code>GET</code> and <code>POST</code>
     * methods.
     *
     * @param request servlet request
     * @param response servlet response
     * @throws ServletException if a servlet-specific error occurs
     * @throws IOException if an I/O error occurs
     */
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        response.setContentType("text/html;charset=UTF-8");
        try (PrintWriter out = response.getWriter()) {

            out.println("<!DOCTYPE html>");
            out.println("<html>");
            out.println("<head>");
            out.println("<title>Servlet TestConnPoolBugServlet</title>");            
            out.println("</head>");
            out.println("<body>");

            Connection[] connections = new Connection[5];
            
            try {
                InitialContext e = new InitialContext();
                DataSource ds = (DataSource)e.lookup("jdbc/TestConnPoolBug");

                for (int iCon = 1; iCon <= connections.length; iCon++) {
                    out.println("<h1>Getting connection " + iCon + "</h1>");
                    try {
                        connections[iCon - 1] = ds.getConnection();
                    } catch (Exception ex) {
                        out.println("<h1>ERROR: " + ex.getMessage() + "</h1>");
                    }
                }

            } catch (NamingException nex) {
               out.println("<h1>ERROR: " + nex.getMessage() + "</h1>");
            } finally {
                int iCon = 1;
                for (Connection con : connections) {
                    if (con != null) {
                        out.println("<h1>Closing connection " + iCon + "</h1>");
                        try {
                            con.close();
                        } catch (Exception ex) {
                        }
                    }
                    iCon++;
                }
            }
            
            out.println("</body>");
            out.println("</html>");
        }
    }
    

 

Please follow the steps below to reproduce the problem:

1) Make sure Glassfish is running (e.g. "asadmin start-domain")
2) Setup the resources, pool monitoring and deploy the application by running “setup.bat”.
3) Open the following URL in your browser: http://localhost:8080/TestConnPoolBug
4) Firstly, just click on the “TestConnPoolBugServlet” link. You should see the following output:

Getting connection 1
Getting connection 2
Getting connection 3
Getting connection 4
Getting connection 5
Closing connection 1
Closing connection 2
Closing connection 3
Closing connection 4
Closing connection 5

You can run this multiple times and get the same result. If “do_mon.bat” is run, the following monitoring statistics are output:

server.resources.TestConnPoolBugPool.numconncreated-count = 5
server.resources.TestConnPoolBugPool.numconnfree-current = 5
server.resources.TestConnPoolBugPool.numconndestroyed-count = 0

This is the normal case, with expected monitoring statistics for the connection pool.

 

To reproduce the bug, it is required to stop and restart the database after the connection pool is built – so the pool connections are invalidated - then invoke the test servlet. Follow the steps below:

5) Now, navigate back to: http://localhost:8080/TestConnPoolBug
6) Stop and restart the database (run “restart_db.bat”). This invalidates the connections in the connection pool. Because the pool uses the “On Any Failure Close All Connections” flag, the first attempt to get a connection will first cause all existing connections in the pool to be destroyed and then the pool connections will be re-created.
7) Click on the “TestConnPoolBugServlet” link, to invoke the test code.

Due to the Connection Pool bug, you see the following output (it will first hang for about a minute - please wait):

Getting connection 1
Getting connection 2
Getting connection 3
Getting connection 4
Getting connection 5
ERROR: Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.
Closing connection 1
Closing connection 2
Closing connection 3
Closing connection 4

Note that “Connection 5” failed because all the connections in the pool have already been used (this should NOT happen, as the minimum and maximum poolsize is 5).

Run “do_mon.bat” to see some important connection pool monitoring statistics:

server.resources.TestConnPoolBugPool.numconncreated-count = 13
server.resources.TestConnPoolBugPool.numconnfree-current = 4
server.resources.TestConnPoolBugPool.numconndestroyed-count = 8

The above statistics definitely shows problems in the pooling and pooling statistics. Too many connections have been created and destroyed, and only 4 connections are left free.

 

I have developed the patch below which corrects the pooling problems that I found.


Index: main/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/poolConnectionPool.java
=====================================================================================================================
--- ConnectorService.java       (revision 57363)
+++ ConnectorService.java       (working copy)
@@ -722,13 +722,13 @@
 
                 if (matchConnection(h, alloc)) {
 
                     boolean isValid = isConnectionValid(h, alloc);
                     if (h.hasConnectionErrorOccurred() || !isValid) {
                         if (failAllConnections) {
-                            createSingleResourceAndAdjustPool(alloc, spec);
+                            result = createSingleResourceAndAdjustPool(alloc, spec);
                             //no need to match since the resource is created with the allocator of caller.
                             break;
                         } else {
                             ds.removeResource(h);
                             //resource is invalid, continue iteration.
                             continue;
@@ -876,16 +876,17 @@
         ResourceHandle handle = ds.getResource();
         if (handle != null) {
             ds.removeResource(handle);
         }
 
         ResourceHandle result = getNewResource(alloc);
-        if (result != null) {
-            alloc.fillInResourceObjects(result);
-            result.getResourceState().setBusy(true);
-        }
+        // The code below has been commented-out because it is effectively being run AGAIN by the caller
+        //if (result != null) {
+        //   alloc.fillInResourceObjects(result);
+        //   result.getResourceState().setBusy(true);
+        //}
 
         return result;
     }
 
 
     /**
@@ -1243,13 +1244,15 @@
         if (poolLifeCycleListener != null) {
             poolLifeCycleListener.connectionValidationFailed(1);
         }
     }
 
     private ResourceHandle getNewResource(ResourceAllocator alloc) throws PoolingException {
-        ds.addResource(alloc, 1);
+        // The wrapper method addResource() needs to be called instead of ds.addResource(), so that NumConnFree gets incremented after creating the new resource
+        //ds.addResource(alloc, 1);
+        addResource(alloc);
         return ds.getResource();
     }
 
 
     private ResourceState getResourceState(ResourceHandle h) {
         return h.getResourceState();

If the test is run with the above patch applied to Glassfish, the following (correct) output is obtained:

Getting connection 1
Getting connection 2
Getting connection 3
Getting connection 4
Getting connection 5
Closing connection 1
Closing connection 2
Closing connection 3
Closing connection 4
Closing connection 5

The following (correct) monitoring statistics are output by running “do_mon.bat”:

server.resources.TestConnPoolBugPool.numconncreated-count = 11
server.resources.TestConnPoolBugPool.numconnfree-current = 5
server.resources.TestConnPoolBugPool.numconndestroyed-count = 6

(On the first getConnection() call, an invalid pool connection is detected, so all connections in the pool are destroyed and then re-created. The createSingleResourceAndAdjustPool() method then creates a new connection and replaces a free connection in the pool, destroying it.)



 Comments   
Comment by gregn123 [ 21/Feb/17 ]

 
Please refer to files located here: https://github.com/gregn123/GLASSFISH-21682
 





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

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1_dev
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-2595] Make com.sun.enterprise.connectors.work.WorkCoordinator implementation thread safe Created: 13/Mar/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: kshitiz_saxena Assignee: kshitiz_saxena
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: 2,595

 Description   

The com.sun.enterprise.connectors.work.WorkCoordinator code is not thread safe.
Need to rewrite object to make it thread safe.

Lloyd comments on code is as follows:

1. Please fix the risky use of using the same name for an instance variable as
a parameter ("waitMode"). This is an awful coding practice guaranteed to
confuse. The fact that "this.waitMode" is used in places doesn't remove the
risk of future errors. The simplest approach is to change the name of the
parameter.

2. workStats.submittedWorkCount++ and (maybe)
workStats.incrementWaitQueueLength() are not thread safe. Can more than one
thread call submitWork()?

3. Is WorkQueue 'queue' thread safe?

4. The object is very badly designed; it cannot be made thread safe as far as I
can tell:

a) what if two threads call submitWork() with different values for waitMode?
Then one will overwrite 'waitMode'.
b) setState() is synchronized, which is pointless...if two threads call
preInvoke(), then one overwrites the other. Ditto for postInvoke().



 Comments   
Comment by gfbugbridge [ 13/Mar/07 ]

<BT6533876>

Comment by kshitiz_saxena [ 20/Mar/07 ]

Declared variable waitMode volatile. This class need more fixes. All issues will
be fixed as part of bug fix 2595.

Comment by kshitiz_saxena [ 20/Mar/07 ]

Above comment is for other bug. This bug still need fixes.

Comment by kshitiz_saxena [ 12/Apr/07 ]

Not a show-stopper

Comment by Jagadish [ 18/Jan/10 ]

Evaluation of the issue for GlassFish V3/V3 UR1 :

< Lloyd comments on code is as follows:

< 1. Please fix the risky use of using the same name for an instance variable as
< a parameter ("waitMode"). This is an awful coding practice guaranteed to
< confuse. The fact that "this.waitMode" is used in places doesn't remove the
< risk of future errors. The simplest approach is to change the name of the
< parameter.
> This can be fixed in v3.

< 2. workStats.submittedWorkCount++
> New monitoring statistics calucation takes care of the issue
< and (maybe)
< workStats.incrementWaitQueueLength() are not thread safe.
> Not applicable w.r.t new monitoring stats implementation in v3

< Can more than one
< thread call submitWork()?

> No. There is one workCoordinator per work instance

< 3. Is WorkQueue 'queue' thread safe?
> WorkQueue implementation is provided by ORB. Yes, its implementation is thread
safe.

< 4. The object is very badly designed; it cannot be made thread safe as far as I
< can tell:

< a) what if two threads call submitWork() with different values for waitMode?
< Then one will overwrite 'waitMode'.
> No two threads will call it as there is one WorkCoordinator per Work instance.

< b) setState() is synchronized, which is pointless...if two threads call
< preInvoke(), then one overwrites the other.

> Two threads will not call pre-invoke() for the same work instance/ work
coordinator.

< Ditto for postInvoke().
> Above explanation applies for postInvoke()

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-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-2121] thread-unsafe null-check idiom in com.sun.enterprise.resource.RecoveryResourceRegistry Created: 19/Jan/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: llc Assignee: kshitiz_saxena
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: 2,121

 Description   

Visibility and race condition problems:

public static RecoveryResourceRegistry getInstance() {
if (rrr == null)

{ rrr = new RecoveryResourceRegistry(); }

return rrr;
}



 Comments   
Comment by km [ 19/Jan/07 ]

Hmmm. Submitter should have checked where this class belongs.

Comment by binod [ 20/Jan/07 ]

The method is executed just once during the startup. It is meant only for single
threaded uses.

Comment by gfbugbridge [ 20/Jan/07 ]

<BT6515532>

Comment by gfbugbridge [ 05/Apr/07 ]

<BT6543318>

Comment by kshitiz_saxena [ 25/Apr/07 ]

Assigning it to myself

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-2969] FindBugs: connector-api Created: 03/May/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: llc Assignee: binod
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: 2,969

 Description   

dpatil: sample/RecordImpl.java:71:71 HE: sample.RecordImpl defines equals and uses Object.hashCode()
(H)



 Comments   
Comment by gfbugbridge [ 03/May/07 ]

<BT6553585>

Comment by Sivakumar Thyagarajan [ 08/May/07 ]

Assigning it to Binod to fix this as this is part of connector-api.

Comment by sridatta [ 15/May/07 ]

Not a release stopper. P4.

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-2931] findbugs : sample.RecordImpl in connector api defines equals and uses Object.hashCode() Created: 27/Apr/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: kshitiz_saxena Assignee: binod
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: 2,931

 Description   

sample.RecordImpl in connector api defines equals and uses Object.hashCode()



 Comments   
Comment by gfbugbridge [ 27/Apr/07 ]

<BT6551377>

Comment by Sivakumar Thyagarajan [ 07/Sep/07 ]

Transferring to Binod as this is a spec API.

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-3915] LinkageError in EJB Created: 13/Dec/07  Updated: 06/Mar/12

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

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

Operating System: All
Platform: Linux


Attachments: GZip Archive testcase.tar.gz    
Issuezilla Id: 3,915
Status Whiteboard:

as911-na


 Description   

I have the following setup :
I'm usings sjsas 9.1 update 3 (glassfish v2)
I have a class library that I wrote to do logging for my connectors / ejb's.
This library has a Logger interface with debug, info etc. methods.
I have 2 connectors. Both connectors use the library. The first connector uses
it to do logging while connecting to our AS400 mainframe, the second connector,
let's call it the logging connector, uses it to create and pass logger instances
to other ejb's packaged in an ear file.

The as400 connector works fine and logs without problems.
The ejb that fails injects both connectors using setter injection. When it asks
the logging connector for a Logger, the logger is created and returned
successfully, but the moment I call a method on the Logger interface I get this
error :

java.lang.LinkageError: Class libraries/ejbLogging/Logger violates loader
constraints

If I remove all references to this class from the AS400 connector, then the
logging connector works fine. Also copying the library jar file to the
domain/lib directory, and removing it from both rar and ear files works. But
according to me I should not have to do this.

I've also noticed that the documentation says that the "connector class loader"
is a single class loader instance. In my debugging efforts, I noted that each
connector seems to have it's own class loader.



 Comments   
Comment by Sivakumar Thyagarajan [ 13/Dec/07 ]

Could you provide more information to help us debug this issue better?

  • How have you bundled the two RARs? Could you provide the directory structure
    of the two RARs? Where are the logging interfaces bundled?
  • If there is a stacktrace with the LinkageError could you share it please?
  • I am assuming you are deploying both the RARs as standalone?
  • Would you be able to share a simple testcase that helps us reproduce the issue
    locally?

"I've also noticed that the documentation says that the "connector class loader"
is a single class loader instance. In my debugging efforts, I noted that each
connector seems to have it's own class loader."

Yes, as you have correctly noticed, though the connector classloader, as shown
in the documentation, logically is a single classloader, it in turn contains a
classloader per standalone RAR deployment. This is to aid dynamic/hot
redeployment of standalone connector modules.

Comment by eduardp [ 14/Dec/07 ]

1. The rar's are deployed as standalone and look like this :

configuration:

– META-INF
  – MANIFEST.MF
`-- ra.xml
– javaee.jar
– libraries.configuration-configuration.jar
– libraries.ejbUtils-ejbUtils.jar
– log4j.jar
– services.configurationConnector.client-client.jar
`-- services.configurationConnector.server-server.jar

as400:

– META-INF
  – MANIFEST.MF
`-- ra.xml
– javaee.jar
– jt400.jar
– libraries.ejbUtils-ejbUtils.jar
– log4j.jar
– services.as400Connector.client-client.jar
`-- services.as400Connector.server-server.jar

The manifest files are essentially empty. The common logging code is in
libraries.ejbUtils-ejbUtils.jar. This is the same jar that the ear file (the
one that breaks) includes.

2. Here is the stack trace I get from my junit test case
(services.orbit.client.FISCHRHRemote is the remote iterface in my ear) :

java.lang.LinkageError: Class libraries/ejbUtils/logging/Logger violates loader
constraints
at services.orbit.client._FISCHRHRemote_Wrapper.GETUNIQUESCHEME
(services/orbit/client/_FISCHRHRemote_Wrapper.java)
at TestCorbaClient.testOrbitServer(TestCorbaClient.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run
(OldTestClassRunner.java:35)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run
(JUnit4TestReference.java:38)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run
(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
(RemoteTestRunner.java:196)

3. I'll try to produce a test case, but this might be a bit difficult, I'll
post it when I have something

Comment by Sivakumar Thyagarajan [ 11/Feb/08 ]

Sorry for the delay in the response.

Could you try providing a testcase? I was not able to reproduce this locally.
May be I am missing some of your steps while trying to reproduce this.

Could you also provide some clarifications?
1. Is libraries.ejbUtils-ejbUtils.jar is also included in the EAR?

"java.lang.LinkageError: Class libraries/ejbUtils/logging/Logger violates loader
constraints at services.orbit.client._FISCHRHRemote_Wrapper.GETUNIQUESCHEME
(services/orbit/client/_FISCHRHRemote_Wrapper.java)"
I am assuming libraries/ejbUtils/logging/Logger is bundled in
libraries.ejbUtils-ejbUtils.jar.

2. How do you inject the Logger instance from the Logging RA into the EJB? Could
you provide some sample code? It appears that the Logger class loaded in the EJB
classloader does not appear to be the same Logger class the connector
classloader has loaded, inspite of delegation. How do you run this test in
junit? I don't see any glassfish classes being in the stack trace. Are you just
making a remote EJB call?

Sorry again for the delay in the response, but if you could help us by providing
more details, we could investigate this further and consider a fix in 9.1.1. Thanks.

Comment by harpreet [ 12/Mar/08 ]

Marking as not applicable for as9.1.1 as there is no test case provided yet. Once provided I can look into
approving it for FCS for v.2.1

Comment by eduardp [ 13/Mar/08 ]

Hi

Sorry for the slow response, I had to hack the code to not be dependant on any
of our infrastructure.

I've included both the rar and ear files as well as the source code.

You will need to deploy all 3 of then call the sayHello method on the
HelloWorld ejb. The 2 connectors need to be registered as as400/as400Connector
and configuration/configurationConnector in the jndi.

Let me know if you need more information

Regards
Eduard

Comment by eduardp [ 13/Mar/08 ]

Created an attachment (id=1379)
testcase to reproduce the error

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-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-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-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-3047] thread safety: CommonWorkManager Created: 22/May/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: llc Assignee: kshitiz_saxena
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: All


Issuezilla Id: 3,047

 Description   

com.sun.enterprise.connectors.work.CommonWorkManager:

  • variable 'wm' is not used.
  • various instance variables are not 'final'.
  • 'isMonitoringEnabled' is not thread safe
  • creation and access to variable 'workStats' is not thread safe.
  • ...etc...

WorkStats:

WorkStats has many mutable variables which are not thread safe [eg reset()]. Is it never the case that a
WorkStats could be seen by more than one thread? It seems not, since there are 'synchronized'
methods in the class. Better to design an immutable class.



 Comments   
Comment by gfbugbridge [ 22/May/07 ]

<BT6560927>

Comment by Sivakumar Thyagarajan [ 22/May/07 ]

requesting Kshitiz to investigate

Comment by kshitiz_saxena [ 29/May/07 ]

The class is not written to work in multi-thread environment. The variable are
mostly read operation, except for isMonitoringEnabled. This will not be modified
by multiple threads are same time.

Comment by llc [ 29/May/07 ]

"The class is not written to work in multi-thread environment".

That's rather hard to believe, given that it maintains a thread pool. Certainly, if it is indeed true, then
there ought to be very clear javadoc comments as to why it's OK.

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-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-5396] Custom connector api classes not visible to war inside ear when deploying resource adapter as module in ear Created: 29/Jul/08  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: obergner Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 5,396

 Description   

When deploying an ear containing

  • a custom resource adapter exposing customer connection and connection factory
    classes, and
  • a war using this custom resource adapter

the embedded rar module deploys successfully, yet the embedded web module fails
to deploy with

[#|2008-07-25T00:59:16.088+0200|SEVERE|sun-appserver9.1|
javax.enterprise.system.container.web|
_ThreadID=16;_ThreadName=Thread-76;_RequestID=e7a1650b-7a69-4457-
a4c6-0daeef4258d5;|WEB0123: WebModule [/ws] failed to deploy and has been
disabled
java.lang.IllegalArgumentException:
[de.saxsys.osgira.shared.connectorapi.factory.JeeServiceLookupConnectionFactory]
is not an allowed property value type
at com.sun.enterprise.deployment.ResourceReferenceDescriptor.checkType
(ResourceReferenceDescriptor.java:492)
at com.sun.enterprise.naming.NamingManagerImpl.bindObjects
(NamingManagerImpl.java:530)
at com.sun.enterprise.web.WebModuleContextConfig.configureResource
(WebModuleContextConfig.java:220)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent
(WebModuleContextConfig.java:161)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:143)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:6350)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4848)
at com.sun.enterprise.web.WebModule.start(WebModule.java:326)

where
de.saxsys.osgira.shared.connectorapi.factory.JeeServiceLookupConnectionFactory
is a custom JCA connection factory.

The jar containing
de.saxsys.osgira.shared.connectorapi.factory.JeeServiceLookupConnectionFactory
lives inside the ear's lib directory. See http://forums.java.net/jive/
thread.jspa?threadID=44527&tstart=45 for a more through description.

Conclusion: The classloader which resolves the embedded war's resource
references has no visibility into classes deployed inside the ear's lib
directory.



 Comments   
Comment by Jagadish [ 30/Jul/08 ]

Requesting Siva to investigate the class-loader issue.

Comment by Sanjeeb Sahoo [ 30/Jul/08 ]

added 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-20594] ClassNotFoundException when adding a ressource to a deployed resourceadapter Created: 30/May/13  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_dev
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-19476] Resources leak in pool resizer with preferValidateOverRecreate Created: 21/Dec/12  Updated: 15/Jul/14

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

Type: Bug Priority: Minor
Reporter: Arkadiusz Orzechowski Assignee: David Delabassee
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-reviewed, connectors, connectors-runtime, fishcat

 Description   

Hi,

I've been recently tracing a strange jdbc connection leak in our production server (gf 3.1.2), which we first observed quite some time ago, but which increased after some reconfiguration/tuning of our connection pools.

We don't use jdbc directly anywhere in our code - only JPA/eclipselink and Activiti(5.9) which uses iBATIS underneath.

Analysing heap dump I found out that we have lot of ResourceHandles not enlisted in any transaction and having state.busy==false while at the same time having busy flag set to true (ie. not "free" according to RWLockDataStructure)

OQL query used to find the leaked resources:

select c from com.sun.enterprise.resource.ResourceHandle c
where c.busy == true && c.state.busy==false && c.state.enlisted==false
&& /jdbc.POOL_NAME.*/(c.spec.resourceId.toString())

I first suspected transaction manager not closing resources after finishing transaction, but I wasn't able to spot any flaw. And the leak was not very repeatable (not after every transaction).

Playing with pools settings I noticed that the leaks did not occur when I set prefer-validate-over-recreate property to false (default). So the quick workaround was to just disable preferValidateOverRecreate.

Further looking into the code I located probable bug responsible for the leak. In com.sun.enterprise.resource.pool.resizer.Resizer, removeIdleAndInvalidResources method, when the resource is not eligible for removal (!isResourceEligibleForRemoval) we neither remove the resource nor mark it as active(so it's not closed later in the finally block).

In our local glassfish build(3.1.2) I verified that adding activeResources.add(h); in line 200 of: Resizer.java fixes the problem.

I did not build any other gf version to verify, but it seems that in current trunk the issue is still present, so I checked 3.1.2 and 4.0 as affected version.

I chose jdbc and jca as components for this issue - hope jca stands for Connector here, not Cryptography



 Comments   
Comment by gfuser9999 [ 04/Jul/14 ]

Can this be fixed fro 4.0.1 since w/o this it greatly limit
JDBC scalability as this switch cannot be used.
(Due to heavy contention as large JDBC pool will
need to wait for a slow JDBC creation * free connection
==> Not usable .

Would be good to have this fix as it is simple.

Comment by David Delabassee [ 09/Jul/14 ]

Is it possible to quickly test this on 4.0.1 and confirm that you sill have the leak?

Comment by gfuser9999 [ 12/Jul/14 ]

Yes still there. By the way 312p08 fixed this.

Comment by David Delabassee [ 15/Jul/14 ]

Thanks, will be fixed for 4.0.1!
The fix has been integrated, can you confirm it works for you?
--8<-
svn log appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/resizer/Resizer.java
r63492 | kdevaras | 2014-07-15 04:34:42 +0200 (Tue, 15 Jul 2014)





[GLASSFISH-18822] EAR-private connector resource pools Created: 22/Jun/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.1_dev
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-18932] Default value is not set for resources.mail-resource Created: 24/Jul/12  Updated: 20/Dec/16

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

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

Windows 7


Attachments: PNG File GUI.png    

 Description   

The default value is not set correctly for the following values.

resources.mail-resource.test.store-protocol-class
resources.mail-resource.test.transport-protocol-class

1. Create a new JavaMail Session. For example, open the GUI and enter the following values.

  • JNDI Name: test
  • Mail Host: test
  • Default User: test
  • Default Sender Address: test@test.com
  • Click Save

2.Open command prompt and enter as follows. Error message is displayed and the default value is not set. (Bug)

C:\>asadmin set resources.mail-resource.test.store-protocol-class=
remote failure: Could not change the attributes: Constraints for this MailResource configuration hav
e been violated: on property [ storeProtocolClass ] violation reason [ must be a valid Java Class Na
me ]
Constraints for this MailResource configuration have been violated: on property [ storeProtocolClass
 ] violation reason [ must be a valid Java Class Name ]
Command set failed.

C:\>asadmin set resources.mail-resource.test.transport-protocol-class=
remote failure: Could not change the attributes: Constraints for this MailResource configuration hav
e been violated: on property [ transportProtocolClass ] violation reason [ must be a valid Java Clas
s Name ]
Constraints for this MailResource configuration have been violated: on property [ transportProtocolC
lass ] violation reason [ must be a valid Java Class Name ]
Command set failed.

3.When the following value is set, the default value is set automatically. (Working as expected)

C:\>asadmin set resources.mail-resource.test.store-protocol=pop3
resources.mail-resource.test.store-protocol=pop3
Command set executed successfully.

C:\>asadmin set resources.mail-resource.test.store-protocol=
resources.mail-resource.test.store-protocol=
Command set executed successfully.

C:\>asadmin get resources.mail-resource.test.store-protocol
resources.mail-resource.test.store-protocol=imap
Command get executed successfully.

The same problem occurs when GUI is used as well.
1.Open the GUI.
2.Open JavaMail Sessions > test which has been created in the previous step.
3.Remove all characters from Store Protocol Class.
4.Click Save.
5.The error is displayed . See the attached file.



 Comments   
Comment by Bill Shannon [ 24/Jul/12 ]

Reassigning to connector team, who I believe owns these resources.

The property values do need to be a class name, but the properties
should be allowed to be unset. Setting the property value to the
empty string isn't the same as unsetting it, so maybe this should be
closed as "not a bug". But I don't know if there is a way to
unset one of these properties so maybe setting it to the empty string
should have that effect.

Comment by Jagadish [ 03/Aug/12 ]

transferring to Naman for investigation





[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: 20/Dec/16

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2_dev
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-18584] "description" elements in glassfish-resources.xml not moved to "description" fields in domain.xml Created: 31/Mar/12  Updated: 07/Jan/13

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

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

All


Tags: configuration, description, glassfish-resources, resources

 Description   

For application/module resources files (glassfish-resources.xml) located in either the "META-INF" or "WEB-INF" directories of war, ear, or ejb projects, the DTD at:
http://glassfish.org/dtds/glassfish-resources_1_5.dtd

Specifies that the "description" must be a subelement of many of the elements (not an attribute). Specifically the "property" element has a description subelement possible.

However, the domain.xml file requires that the description be an attribute. This relates to issue GLASSFISH-16630 which is marked as "Won't fix". If we accept that we will not fix this because it causes problems migrating configuration from glassfish 2.x to 3.x, then at least when a project is deployed that has application/module resources, the "description" element should be copied into the "description" attribute.

One of the great benefits of the new portable JNDI namespaces and application resource files, you can now modify an application/module resource inside the of the Glassfish Admin site without redeploying or packaging the application. However, it gets very confusing when your configuration properties do not have a description associated with them.



 Comments   
Comment by Tom Mueller [ 24/Dec/12 ]

This appears to be deployment related, so assigning to the deployment category.

Comment by Hong Zhang [ 26/Dec/12 ]

The resource team owns glassfish-resources.xml, assign to Jagadish for evaluation

Comment by Jagadish [ 04/Jan/13 ]

Transferring to Naman for investigation.
It looks like we do seem to handle "description" element of glassfish-resources.xml for jdbc resource but not for other resource types.

Comment by naman_mehta [ 07/Jan/13 ]

I tried on the latest workspace and this bug is not reproducible. I can find description is mapped to domain.xml.

e.g.

<jdbc-resource pool-name="java:app/TestPool" description="This is the default pool." jndi-name="java:app/jdbc/TestDB"></jdbc-resource>
<mail-resource host="localhost" description="This is the mail resorce." jndi-name="java:app/mail/csjdb1" from="xtecuan@gmail.com" user="xtecuan"></mail-resource>

I am attaching the sample .war file with test code. Just try to deploy the same and verify this bug.

Comment by naman_mehta [ 07/Jan/13 ]

Couldn't find option for attachment here so sent as separate email.





[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-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-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.





[GLASSFISH-19001] More than the maximum number of characters or invalid characters can be entered for asadmin create-javamail-resource Created: 14/Aug/12  Updated: 20/Dec/16

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

Type: Bug Priority: Trivial
Reporter: tak09 Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

More than maximum number of characters or invalid characters can be entered for Admin GUI.
1.Open admin GUI. http://localhost:4848
2.Select Resources > JavaMail Sessions from the tree.
3.Click New button to open New Java Mail Session.
4.Enter invalid characters or more than 256 characters in each field.
5.Click OK.

Similarly, more than the maximum number of characters or invalid characters can be entered for asadmin create-javamail-resource.
1.Enter invalid characters or more than 256 characters for asadmin create-javamail-resource.
2.A new resource is created with invalid characters or more than maximum characters.



 Comments   
Comment by Bill Shannon [ 14/Aug/12 ]

I think the JCA team is responsible for this admin command.

Comment by Jagadish [ 16/Aug/12 ]

Transferring to Naman for investigation





Generated at Sat Mar 25 12:19:29 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.