[JPA_SPEC-58] script generation : same table name, different schema are merged Created: 15/May/13  Updated: 15/May/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Windows : XP SP3
Glassfish : Oracle GlassFish Server 3.1.2.2 (build 5)
Eclipse : Indigo Build id: 20110615-0604
JRE : jdk1.6.0_33


Tags: create, ddl, eclipselink, generate, script, table

 Description   

Write two entities with the same table name but different schema :

@Entity
@Table(name="tablename", schema="schema1")
public class MyEntitySchema1 {
}

@Entity
@Table(name="tablename", schema="schema2")
public class MyEntitySchema2 {
}

Configure persistence.xml like this :
...
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties>
<property name="eclipselink.ddl-generation" value="create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="sql-script"/>
<property name="eclipselink.create-ddl-jdbc-file-name" value="create.sql"/>
<property name="eclipselink.drop-ddl-jdbc-file-name" value="drop.sql"/>
...
</properties>
...

And then check the generated script create.sql :
CREATE TABLE schema2.tablename (...)
ALTER TABLE schema2.tablename ADD CONSTRAINT ...

Nothing about schema1.tablename in the script file.

If I change one thing (ex. update a letter of tablename from lowercase to uppercase, I get both tables generated. (Those tables already exist, so this is not a solution for me).






[JERSEY-1317] Tomcat 7 slow startup time with Jersey (1.13) deployed Created: 27/Jul/12  Updated: 08/Aug/13  Resolved: 03/Aug/12

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 1.13
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: gamliela Assignee: Michal Gajdos
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 5 hours
Original Estimate: Not Specified
Environment:

Windows 7, jdk1.6.0_30, apache-tomcat-7.0.29, jersey-archive-1.13, eclipselink-2.3.1


Tags: eclipselink, selenium, tomcat

 Description   

Time for launch Tomcat without Jersey is 1 second.
When I add the jars of Jersey to tomcat/lib directory, the time for launch goes for 30 seconds.
It doesn't matter which application I deploy - even if no application is deployed (no servlets) it takes that time. However the server already contains jars of Selenium and EclipseLink.

The jar that cause the problem is jersey-servlet-1.13. When I remove it from lib directory, launch time goes normal again. I suspect that the services defined in that jar (\META-INF\services*) cause the trouble but couldn't find the exact cause...

I'm not sure if it's a bug but it's definitively a problem.
My motivation for choosing Tomcat was performance, and if Jersey hurts that performance it's a problem.

Steps to reproduce:
1. download and extract apache-tomcat-7.0.29
2. copy to tomcat/lib directory the following jars from eclipselink-2.3.1 (JPA):
a) eclipselink.jar
b) javax.persistence_2.0.3.v201010191057.jar
3. copy to tomcat/lib directory the following jars from selenium-2.24.1:
a) selenium-java-2.24.1.jar
b) all jars from lib directory (36 jars)
4. run tomcat/bin/startup.bat and make sure (using logs) the startup time is few seconds at most.
On my machine it takes less than 1 second.
5. run shutdown.bat
6. copy to tomcat/lib directory the following jars from jersey-archive-1.12.zip:
a) asm-3.1.jar
b) jersey-core-1.12.jar
c) jersey-server-1.12.jar
d) jersey-servlet-1.12.jar
(As far as I know this is the minimum required to use Jersey)
7. run startup.bat again.
On my machine it takes now more than 30 seconds.



 Comments   
Comment by gamliela [ 27/Jul/12 ]

The same problem occurs on both versions of Jersey - 1.12 & 1.13.
Also please fix the download link for 1.13 (it still points to 1.12).

Comment by Marek Potociar [ 02/Aug/12 ]

Michal, can you please evaluate?

Comment by Michal Gajdos [ 03/Aug/12 ]

This is not a Jersey bug although the jersey-servlet.jar makes Tomcat to perform some additional classpath scanning. The jersey-servlet.jar adds a capability for Servlet3 initialization which Tomcat7 supports. Since you put Jersey jars into tomcat/lib directory then the Jersey implementation of ServletContainerInitializer is invoked for every webapp (present in tomcat\webapps) during it's deployment. Before the invocation of the JerseyServletContainerInitializer the Tomcat does classpath scanning to provide requested classes to this initializer (which slows down the startup).

There are two ways to solve this issue:

  • if you do not need/use Servlet3 capabilities, you can remove the META-INF/services/javax.servlet.ServletContainerInitializer file from jersey-servlet.jar so that the JerseyServletContainerInitializer is not recognized by Tomcat and hence no classpath scanning is performed for this initializer.
  • if you want to use Servlet3 then pack the Jersey jars with the webapp to ensure the JerseyServletContainerInitializer is invoked only for this webapp (Tomcat will do the classpath scanning only for webapps containing the jersey-servlet.jar)

Edit: Thanks for noticing the incorrect download link.





[GLASSFISH-21164] On deploy jpa validation Eclipselink do not recognize entity class if has lambda expressions inside a method Created: 13/Aug/14  Updated: 22/May/15

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: fantarama Assignee: Srini
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java jdk 1.8_05


Tags: eclipselink, jpa

 Description   

During deploy process if a jpa entity (@Entity) in one of his methods has a java 8 lambda expression the entity is not recognized has a jpa entity and skipped. This cause validation error during deployment if the entity is in relation with others.



 Comments   
Comment by Hong Zhang [ 13/Aug/14 ]

assign to persistence team for evaluation

Comment by Lukas Jungmann [ 13/Aug/14 ]

this is fixed in EclipseLink 2.6.0, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=429992 GF currently uses 2.5.2

Comment by fantarama [ 13/Aug/14 ]

Thanks, but is there a future plan to update GF to 2.6.0? Any workaround to be able to deploy the application?

Comment by caricsvk [ 22/May/15 ]

Eclipselink 2.6.0 is already shipped out (March 10, 2015). When do we expect to have it in glassfish nightly?





[GLASSFISH-20795] EclipseLink 2.5.0 JPQL Parser breaks column alias handling in ORDER BY clause Created: 04/Sep/13  Updated: 05/Sep/13

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

Type: Bug Priority: Blocker
Reporter: dimaki Assignee: sfelts
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4 (b89), EclipseLink 2.5.0 (included)


Tags: eclipselink, jpa, jpql

 Description   

Column alias (result_variable) handling as defined in JPA Spec 2.1 (JSR-338) "4.9 ORDER BY Clause" is not working with the default EclipseLink 2.5.0 JPQL Parser (Hermes) provided in Glassfish 4.0 (b89). If a basic JPQL query contains two column aliases and there is an ORDER BY clause on the first alias, EclipseLink returns the following exception:

Exception Description: Problem compiling [SELECT c.cuNumber, c.nameLast AS last_name, c.nameFirst AS first_name FROM Customer c ORDER BY last_name].
[70, 79] The identification variable 'last_name' is not defined in the FROM clause.

Example:
========
Create an entity 'Customer' similar to:

@Entity
@Access(AccessType.FIELD)
@Table(name = "CUSTOMER")
public class Customer implements Serializable {

...
@Column(name = "CU_NUMBER")
private String cuNumber;
@Column(name = "HY_NAME_LAST")
private String nameLast;
@Column(name = "HY_NAME_FIRST")
private String nameFirst;
...
}

In a SLSB use:

...
@PersistenceContext(unitName = "TEST_PU")
EntityManager em;
...

Query query = em.createQuery("SELECT c.cuNumber, c.nameLast AS last_name, c.nameFirst AS first_name FROM Customer c ORDER BY last_name");
...

This fails with:
Exception Description: Problem compiling [SELECT c.cuNumber, c.nameLast AS last_name, c.nameFirst AS first_name FROM Customer c ORDER BY last_name].
[70, 79] The identification variable 'last_name' is not defined in the FROM clause.

If you use the second alias in the order by clause the query is executed successfully.
The same query is running without any error in Glassfish 3.1.2.2 using supplied EclipseLink version.

It seems to be a EclipseLink JPQL Parser Bug.
As a workaround you can switch back to the prior EclipseLink 2.4 JPQL Parser by using the following configuration in your persistence.xml:
<property name="eclipselink.jpql.parser" value="org.eclipse.persistence.queries.ANTLRQueryBuilder"/>
But I don't think the old JPQL parser is JEE 7 compliant.



 Comments   
Comment by dimaki [ 04/Sep/13 ]

See also here: http://www.eclipse.org/forums/index.php/t/489531/

Comment by PascalFilion [ 05/Sep/13 ]

The bug has been fixed and will be part of the next patch release (2.4.3 and 2.5.1). A nightly build can be picked up if required.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=410808





[GLASSFISH-20651] EclipseLink Generates DDL Statements Without Trailing Semicolon Created: 20/Jun/13  Updated: 03/Jul/14

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: abien Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: eclipselink, fishcat, persistence

 Description   

EclipseLink generates DDL statements (CREATE TABLE, DROP Table etc.) without the trailing semicolon. The statements are so no directly usable in a CI enviromnent.

Expected:

CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT DECIMAL(15), PRIMARY KEY (SEQ_NAME));

is

CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT DECIMAL(15), PRIMARY KEY (SEQ_NAME))

Seems like all target databases are effected.



 Comments   
Comment by guypelletier [ 03/Jul/13 ]

EclipseLink currently does not generate platform dependent terminators in DDL generation. It does however have the capability to do so and it could be achieve through a new property setting.

Can you please enter an EclipseLink bug to include this functionality?

Comment by alexeev_net [ 06/Dec/13 ]

I traced the problem down to the field createSQLFiles in the class SchemaManager:

org.eclipse.persistence.tools.schemaframework.SchemaManager
 
  protected boolean createSQLFiles = true; //if true, schema writer will add terminator string.

In order to generate platform dependent terminators in DDL generation, this field shall be true. Unfortunately, EntityManagerFactoryProvider explicitly turns this flag to false:

org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider
 
  protected static void writeDDLsToFiles(SchemaManager mgr,  String appLocation, String createDDLJdbc, String dropDDLJdbc) {
    //..
    mgr.setCreateSQLFiles(false); // BUG!
    //..

As a result, every DDL statement in SQL-File is terminated with "\n" instead of platform dependent terminator.

To me it seems like there is a trivial bugfix for EntityManagerFactoryProvider, replacing mgr.setCreateSQLFiles(false) by mgr.setCreateSQLFiles(true).
I already tested it locally with EL 2.3.2 and EL 2.4.2.

Comment by Alessandro Brandimarti [ 03/Jul/14 ]

EclipseLink bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=438871





[GLASSFISH-19390] Deploying WAB results in EclipseLink enhanced bytes regardless of JPA provider Created: 27/Nov/12  Updated: 29/Nov/12  Resolved: 28/Nov/12

Status: Closed
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chejavara Assignee: Sanjeeb Sahoo
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-19365 Deploying WAB results in EclipseLink ... Closed
Tags: eclipselink, osgi

 Description   

I have a web application bundle with a persistence unit defined in persistence.xml

The provider is set to hibernate
<provider>org.hibernate.ejb.HibernatePersistence</provider>

No matter what when the WAB is deploying in OSGI environment, EclipseLink Enhancer will enhance all of my entity classes. This is due to the following stack trace:

EclipseLinkEnhancer.enhance(Bundle, List<Persistence>) line: 81
JPABundleProcessor.enhance() line: 144
JPAExtender.enhance(JPABundleProcessor, boolean) line: 174
JPAExtender.access$100(JPAExtender, JPABundleProcessor, boolean) line: 64
JPAExtender$1.run() line: 130
JPAExtender.executeTask(Runnable, JPAExtender$EnhancerPolicy) line: 203
JPAExtender.bundleChanged(BundleEvent) line: 139
EventDispatcher.invokeBundleListenerCallback(Bundle, EventListener, EventObject) line: 807
EventDispatcher.fireEventImmediately(EventDispatcher, int, Object[], EventObject, Dictionary) line: 729
EventDispatcher.fireBundleEvent(BundleEvent) line: 610
Felix.fireBundleEvent(int, Bundle) line: 3758
Felix.installBundle(long, String, BundleArchive, InputStream) line: 2640
Felix.installBundle(String, InputStream) line: 2436
BundleContextImpl.installBundle(String, InputStream) line: 129
BundleContextImpl.installBundle(String) line: 107

and the JPABundleProcessor decides to do this in enhance():

JPAEnhancer enhancer = new EclipseLinkEnhancer();
InputStream enhancedStream = enhancer.enhance(getBundle(), persistenceXMLs);

The EclipseLink enhancing should not take place if we are not using EclipseLink as the provider, right?

I have tried setting:
org.glassfish.osgjpa.extension.useHybridPersistenceProviderResolver=true in config.properties

and tried setting
<property name="eclipselink.weaving" value="false"/> in persistence.xml to no avail.

The only way I see is to include GlassFish-StaticallyWeaved manifest header in manifest.mf.

Seems to me that EclipseLink enhancing by default should be OFF and possibly turn it ON with the manifest header and not the other way around, because not everyone will be using EclipseLink enhancing?



 Comments   
Comment by Sanjeeb Sahoo [ 28/Nov/12 ]

The fact of the matter is we currently don't support any other JPA provider in OSGi mode, so we assume it's eclipselink and enhance the bytes when we see a JPA bundle. There are other RFEs filed in JIRA to add support for other JPA providers. When we support them, we will pay attention to the kind of provider being used by an app.

Comment by chejavara [ 28/Nov/12 ]

Thats suprising

What doesn't work with those providers, what would you need to to do to support them? So far I don't see anything because I tested both OpenJPA and Hibernate and they worked in my test cases.

Do you have links to the JIRA issues, so I know what doesn't work?

Comment by Sanjeeb Sahoo [ 28/Nov/12 ]

See GLASSFISH-19284 and GLASSFISH-12275.

Comment by chejavara [ 28/Nov/12 ]

Thanks for the info, I think I may see why, I wasn't using it with EJB.

Comment by TangYong [ 29/Nov/12 ]

Currently, JPA Enhancer happened on a jpa bundle's installed/updated/started unless you specify "GlassFish-StaticallyWeaved = true" in MANIFEST.MF file, and once starting executing enhance, osgi-jpa uses EclipseLinkEnhancer, still not supporting Hibernate and OpenJPA's enhance strategies, so, a workaround is setting "GlassFish-StaticallyWeaved = true" in MANIFEST.MF file.

As to how to support other persistence vendors's enhance strategies, firstly, we need to do the following,

1) investigate how Hibernate and OpenJPA use enhance strategy

2) modify JPABundleProcessor.enhance() to judge JPA provider from persistent.xml and call persistence vendors's enhance strategies

just as sahoo's saying, please pay attention to GLASSFISH-12275(Hibernate's enhance) and GLASSFISH-19284(OpenJPA's enhance).

Please seeing whether the workaround is available(not using enhance)

Thanks.
--Tang





[GLASSFISH-17432] Eclipselink deserialize a empty entity object on remote ejb call. Created: 16/Oct/11  Updated: 09/Nov/11  Resolved: 09/Nov/11

Status: Closed
Project: glassfish
Component/s: None
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: norasodan Assignee: Mitesh Meswani
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SO: Apple Macintosh OS X Lion 10.7.2 (but on Solaris 11 Express, i have a same issue)
JVM/DK: 1.6.0_26 (build 1.6.0_26-b03-383-11A511)
Persistence provider: EclipseLink bundled with Glassfish. My app not have any jar as dependency.


Tags: eclipselink, ejb, remote

 Description   

I have a EJB deployed in Glassfish and a web tier (war) on same application server instance. My web tier call a business method with a entity bean as argument. In EJB logic, the entity is empty. All fields is null.

My problem is solved using Hibernate. But is very strange the default library (EclipseLink) not work with EJB environment.

If EclipseLink is not recommended for distributed applications, why this lib is default?

Thanks.



 Comments   
Comment by Mitesh Meswani [ 20/Oct/11 ]

You might be hitting the same issue as http://java.net/jira/browse/GLASSFISH-16164. I am assuming that your EJB tier and Web tier is deployed as separate app

Are you using field based or attribute based persistence?
Do you have persistence unit defined in both EJB tier and Web tier or only one of them?
Please try adding <property name="eclipselink.weaving.fetchgroups" value="false"/> to persitsence.xml as a workaround

Comment by shreedhar_ganapathy [ 09/Nov/11 ]

Transferring to Mitesh for eval and resolution.

Comment by Mitesh Meswani [ 09/Nov/11 ]

Closing as duplicate of http://java.net/jira/browse/GLASSFISH-16164. Please reopen if that is not the case





[GLASSFISH-16802] @DataSourceDefinition java.sql.SQLException: No PasswordCredential found for connections with empty password Created: 04/Jun/11  Updated: 10/Jun/11  Resolved: 10/Jun/11

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b08

Type: Bug Priority: Major
Reporter: a.accioly Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Confirmed both in OSX Snow Leopard and Windows 7 64 Bits, in two separate machines (probably the bug is OS and Hardware agnostic).


Tags: 3_1_1-approved, 3_1_1-scrubbed, eclipselink, exception, jdbc, password

 Description   

When creating a datasource like this:

@DataSourceDefinition(name = "java:app/jdbc/myDatasource", 
 className = "org.h2.jdbcx.JdbcDataSource", 
 url = "jdbc:h2:/path/to/db;AUTO_SERVER=TRUE;MVCC=TRUE", 
 user = "sa",
 password=""
) 

or

web.xml
<data-source>
    <description>DataSource for H2</description>
    <name>java:app/jdbc/cdiDS</name>
    <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
    <url>jdbc:h2:/path/to/db;AUTO_SERVER=TRUE;MVCC=TRUE</url>
    <user>sa</user>
    <password></password>
</data-source>

Throws a nasty Exception:

 
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Error in allocating a connection. Cause: No PasswordCredential found
Error Code: 0
	at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:309)
	at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:138)
	at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:94)
	at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
	at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:592)
	at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:233)
	at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:394)
	at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:185)
	at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:242)
	at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:230)
	at org.glassfish.persistence.jpa.PersistenceUnitLoader.doJava2DB(PersistenceUnitLoader.java:373)
	at org.glassfish.persistence.jpa.JPADeployer$2.visitPUD(JPADeployer.java:434)
	at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:486)
	at org.glassfish.persistence.jpa.JPADeployer.iterateInitializedPUsAtApplicationPrepare(JPADeployer.java:464)
	at org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:388)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:452)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:360)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
	at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.executeCommand(CommandExecutorImpl.java:118)
	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:97)
	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:88)
	at org.glassfish.maven.PluginUtil.doDeploy(PluginUtil.java:106)
	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 org.glassfish.maven.AbstractDeployMojo.doDeploy(AbstractDeployMojo.java:171)
	at org.glassfish.maven.RunMojo.execute(RunMojo.java:62)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
	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 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.sql.SQLException: Error in allocating a connection. Cause: No PasswordCredential found
	at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:117)
	at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:126)
	... 54 more
Caused by: javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: No PasswordCredential found
	at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:310)
	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:110)
	... 55 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: No PasswordCredential found
	at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:103)
	at com.sun.enterprise.resource.pool.ConnectionPool.addResource(ConnectionPool.java:282)
	at com.sun.enterprise.resource.pool.ConnectionPool.createResourceAndAddToPool(ConnectionPool.java:1497)
	at com.sun.enterprise.resource.pool.ConnectionPool.createResources(ConnectionPool.java:940)
	at com.sun.enterprise.resource.pool.ConnectionPool.initPool(ConnectionPool.java:230)
	at com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:511)
	at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
	at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:242)
	at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:167)
	at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:335)
	at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:304)
	... 59 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: No PasswordCredential found
	at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:920)
	at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1181)
	at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
	... 69 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: No PasswordCredential found
	at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:168)
	at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:903)
	... 71 more
Caused by: javax.resource.spi.SecurityException: No PasswordCredential found
	at com.sun.gjc.util.SecurityUtils.getPasswordCredential(SecurityUtils.java:111)
	at com.sun.gjc.spi.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:100)
	at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:147)
	... 72 more
05/06/2011 00:57:59 org.glassfish.persistence.jpa.PersistenceUnitLoader doJava2DB

The same thing happens if I don't specify a password.
The funny thing is, this works as expected:

glassfish-resources.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN" "http://glassfish.org/dtds/glassfish-resources_1_5.dtd">
<resources>
  <jdbc-resource enabled="true" jndi-name="jdbc/myDatasource"pool-name="connectionPool">
    <description/>
  </jdbc-resource>
  <jdbc-connection-pool datasource-classname="org.h2.jdbcx.JdbcDataSource"  name="connectionPool" res-type="javax.sql.DataSource">
    <property name="URL" value="jdbc:h2:jdbc:h2:/path/to/db;AUTO_SERVER=TRUE;MVCC=TRUE"/>
    <property name="User" value="sa"/>
    <property name="Password" value=""/>
  </jdbc-connection-pool>
</resources>

I haven't tested with other databases, but a quick search on Google lead me to believe that this bug is also database agnostic.
Can you guys confirm it?



 Comments   
Comment by Mitesh Meswani [ 06/Jun/11 ]

Assigning to JCA for initial investigation

Comment by Jagadish [ 07/Jun/11 ]

I am able to reproduce the issue.
We need to evaluate further as "" is the default value of password attribute in annotation.
Current implementation will not set the password for datasource if it is "".

Comment by Jagadish [ 09/Jun/11 ]

Fix is to avoid ignoring "password" attribute when specified with the value of "".

Comment by Jagadish [ 10/Jun/11 ]

Fixed in trunk :

svn log -v -r 47399
---------------
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/handlers/DataSourceDefinitionHandler.java

Comment by scatari [ 10/Jun/11 ]

Approved for 3.1.1.

Comment by Jagadish [ 10/Jun/11 ]

Fixed in 3.1.1
svn log -v -r 47430
branches/3.1.1/deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/handlers/DataSourceDefinitionHandler.java





[GLASSFISH-16746] pessimistic lock can not generated into SQL in GF V3.1(eclipselink-2.2.0.v20110202-r8913) Created: 27/May/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b14

Type: Bug Priority: Major
Reporter: Wu Jie Assignee: tware
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF V3.1(eclipselink-2.2.0.v20110202-r8913)
Database:SQL Server 2008


Tags: 3_1-next, 3_1_1-scrubbed, EclipseLink, GlassFish, PESSIMISTIC_LOCK

 Description   

the app is following´╝Ü
===
Query query = em.createQuery("select i from RowLockEntity i where i.id=:id");
query.setParameter("id", id);
query.setHint(QueryHints.PESSIMISTIC_LOCK,lockType);
entity = (RowLockPesEntity)query.getSingleResult();
===
The generated SQL of above app by eclipselink-2.2.0.v20110202-r8913 as following.

===
SELECT ID,ENT_TYPE, NAME, OPT_LOCK_VER FROM ROWLOCKENTITY WHERE (ID = ?)")
===

The generated SQL does not contain pessimistic lock.
This problem occurred not only in SQL Server 2008, but also in Oracle, Derby and so on.



 Comments   
Comment by Mitesh Meswani [ 27/May/11 ]

A better approach for getting pessimistic lock is to use the standard API instead of EclipseLink specific API as follows

Query query = em.createQuery("select i from RowLockEntity i where i.id=:id");
query.setParameter("id", id);
query.setLockMode(javax.persistence.LockModeType.PESSIMISTIC_READ);
//query.setHint(QueryHints.PESSIMISTIC_LOCK,lockType);
entity = (RowLockPesEntity)query.getSingleResult();

That said, I believe EclipseLink should definitely honor the hint if you are executing the query within a transaction. Can you please file a bug against EclipseLink (https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EclipseLink) and cross reference both the bugs.

Comment by Wu Jie [ 29/May/11 ]

filed a bug against EclipseLink as following link:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347592

Comment by scatari [ 11/Jun/11 ]

Mitesh,
Is the EclipseLink fix made in the trunk included in 2.3.0.x drop into 3.1.1? If not, then this should be deferred from 3.1.1. Could you please update accordingly?

Comment by Mitesh Meswani [ 15/Dec/11 ]

EclipseLink version with corresponding fix is integrated into GlassFish. Marking as fixed.





[GLASSFISH-16429] Eclipselink cannot map a compound constraint because of exception: The reference column name [y] mapped on the element [field x] does not correspond to a valid field on the mapping reference Created: 21/Apr/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b14

Type: Bug Priority: Major
Reporter: xcallejas Assignee: tware
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, Netbeans 7.0, Glassfish 3.1 FCS, MySQL 5.1


Attachments: File ddl.sql     PNG File er_diag.png     Zip Archive WebApplication1.zip    
Tags: 3_1-next, 3_1_1-scrubbed, eclipselink, glassfish-3-1

 Description   

This is a problem of Eclipselink since 2.1.x that stop me from upgrade my applications to Glasfish 3.1. I hopped this would be fixed in final 3.1 but isn't.

I have attached a test case with 3 database tables: Clientes, Operaciones, RoutingOrders; attached is a ER diagram.

RoutingOrders table has a foreign constraint compounded of 2 fields: [Cliente, Operacion ] from for foreign table Operaciones; attached is the DDL.

Please look at these entities code:

@Entity
@Table(name = "Operaciones")
@XmlRootElement
@NamedQueries(

{ @NamedQuery(name = "Operaciones.findAll", query = "SELECT o FROM Operaciones o")}

)
public class Operaciones implements Serializable {
private static final long serialVersionUID = 1L;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Basic(optional = false)
@NotNull
@Column(name = "idOperacion")
private Integer idOperacion;

@OneToOne(cascade = CascadeType.ALL, mappedBy = "operaciones")
private RoutingOrders routingOrders;

@JoinColumn(name = "Cliente", referencedColumnName = "idCliente")
@ManyToOne(optional = false)
private Clientes cliente;

...
}

@Entity
@Table(name = "RoutingOrders", uniqueConstraints =
@UniqueConstraint(columnNames =

{"Cliente", "Operacion"}

))
@XmlRootElement
@NamedQueries(

{ @NamedQuery(name = "RoutingOrders.findAll", query = "SELECT r FROM RoutingOrders r")}

)
@AttributeOverride(name = "Cliente", column =
@Column(name = "Cliente"))
public class RoutingOrders implements Serializable {

private static final long serialVersionUID = 1L;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Basic(optional = false)
@NotNull
@Column(name = "idRoutingOrder")
private Integer idRoutingOrder;

@JoinColumns(

{ @JoinColumn(name = "Cliente", referencedColumnName = "Cliente"), @JoinColumn(name = "Operacion", referencedColumnName = "idOperacion")}

)
@OneToOne(optional = false, targetEntity=Operaciones.class)
private Operaciones operaciones;
...
}

The problem seems to be in the 'operaciones' field, in the ... referencedColumnName = "Cliente" ..., when I try to deploy the application into Glassfish 3.1 it throws the following exception:

Internal Exception: Exception [EclipseLink-7333] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The reference column name [Cliente] mapped on the element [field operaciones] does not correspond to a valid field on the mapping reference...

I have search for days looking for the solution but I gave up, there is the uppercase association thing but this doesn't help.

For me is a Blocker because I cannot deploy any application that has this kind of characteristics and it seems that this problem remains since Eclipselink 2.1.x.



 Comments   
Comment by xcallejas [ 21/Apr/11 ]


I am using Glassfish 3.0.1 + Eclipselink 2.1.2 and this test case works, this stop working in Eclipselink 2.2.0, this is why I cannot use Glassfish 3.1, I have tried to downgrade Eclipse in Glassfish 3.1 but I haven't been able.

Comment by Mitesh Meswani [ 25/Apr/11 ]

Being tracked with https://bugs.eclipse.org/bugs/show_bug.cgi?id=343632

Comment by xcallejas [ 25/Apr/11 ]


Thanks!

Comment by Nazrul [ 09/May/11 ]

Backward compatibility issue. User is unable to move from 3.0.1 to 3.1. Lets take a look at this.

Comment by scatari [ 10/Jun/11 ]

We will not get the fix from eclipselink in time for 3.1.1.

Comment by xcallejas [ 16/Jun/11 ]


scatari: now with the change in the 3.1.1 release date, do you have time for consider this fix for 3.1.1?

Comment by scatari [ 20/Jun/11 ]

This is not a blocker for releasing 3.1.1. We will be targeting this fix in the next release of GlassFish.

Comment by Mitesh Meswani [ 15/Dec/11 ]

EclipseLink version with corresponding fix has been integrated into GlassFish. Marking as fixed





[GLASSFISH-16164] eclipselink.weaving breaks marshalling out of the box Created: 05/Mar/11  Updated: 08/Mar/13

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_b43
Fix Version/s: None

Type: Bug Priority: Major
Reporter: netricsoft Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 22
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 and Mac OS X


Attachments: Zip Archive TestCase.zip    
Issue Links:
Related
is related to GLASSFISH-17557 Odd deserialization fail Open
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, corba, eclipselink, orb-review

 Description   

Separately deployed EJB components that return @Entity objects, fail serialization and return empty objects to remote components (such as a managed bean in a separately deployed WAR). Adding: <property name="eclipselink.weaving" value="false"/> to persistence.xml fixes the issue, but cant be expected behavior out of the box. I tried 2 separate clean installs, and an upgrade from 3.0.1 but all have same broken behavior.

To reproduce:
1) Deploy EJB jar with a stateless EJB that returns an entity from remote interface.
2) Deploy web application with a managed bean that retrieves entity from injected EJB
3) Access managed bean from view.

I get empty entity classes (all fields null) with no errors in server.log.

I have a test case intellij project illustrating issue if required.



 Comments   
Comment by marina vatkina [ 07/Mar/11 ]

let's start with JPA

Comment by Mitesh Meswani [ 07/Mar/11 ]

Can you please attach the test project that you are mentioning above. That would help speed up things.

Comment by netricsoft [ 08/Mar/11 ]

Here is a video illustrating issue:

http://www.youtube.com/watch?v=2xg_QiGijuE

(watch in 'original' format)

The attached project assumes you have a jdbc resource jdbc/testcase setup with one table:

create table person (
id integer not null primary key,
email varchar2(80) not null
);

insert into person values ( 1, 'test@case.com' );

The test case contains 3 components/modules:

1) "Model", shared classes for Session and "Web" module.
Compile with EE 6.
2) "Session", an EJB component with a single EJB PeopleSessionBean. Compile with EE 6. This module contains the JPA persistence.xml WITHOUT the eclipselink.weaving property element. So it will not work until the following is added:
<properties>
<property name="eclipselink.weaving" value="false"/>
</properties>

3) "Web", a WAR component with a single managed bean that attempts to retrieve an entity from the remote EJB. Compile with EE 6 and Mojarra 2.1.

To reproduce issue:

Compile Model
Compile Session (include Model source)
Compile Web (include Model source)

Deploy Session component
Deploy Web component
Access web component (http://localhost/testcase/)

As is, you will get Id 0 and blank (null) for email.

Add <properties> element above to persistence-unit in persistence.xml, redeploy Session and Web and reload testcase page. You will get Id 1 and email test@case.com

Thanks

-jim

Comment by netricsoft [ 14/Mar/11 ]

Will this issue be fixed? or is this intended behavior?

thanks

Comment by Mitesh Meswani [ 14/Mar/11 ]

We are still investigating. Meanwhile, a workaround is to use attribute based persistence. The issue does not manifest there.

BTW, thanks for the reproductions and cool video walk through

Comment by Mitesh Meswani [ 07/Apr/11 ]

Ken,

Assigning to you to investigate why IIOP serialization layer causes this issue. I have sent you test app and instructions to reproduce this in email.

Comment by scatari [ 27/Jun/11 ]

Targeting for next release after 3.1.1.

Comment by Mitesh Meswani [ 20/Oct/11 ]

Another work around is adding property <property name="eclipselink.weaving.fetchgroups" value="false"/> to the persistence unit

Comment by jimmysklim [ 13/Dec/11 ]

Guys! Thank alot for the work around. After adding <property name="eclipselink.weaving.fetchgroups" value="false"/> it's worked.

Comment by jthoennes [ 22/Mar/12 ]

Any plans when this will be corrected?

Comment by kombatkuehn [ 27/Apr/12 ]

This issue still exists in 3.1.2 (build 23).

Comment by chrispy [ 14/Sep/12 ]

This bug is still a problem. When will this be fixed? A workaround is not a solution :-/

Comment by eldiegos [ 24/Sep/12 ]

OMG. This bug has been a pain on the neck until i found this issue. What a waste of time trying to solving it. Please glassfish team solve it.

I have vote for it.

Thanks.

Comment by vins4java [ 26/Feb/13 ]

I agree with eldiegos. I found this bug up to lastest 3.1.2.2 and there's no way to know if it will be fixed for glassfish 4.0 or not...
What's the plan for the resolution of this bug?

Comment by markokanala [ 07/Mar/13 ]

Has anyone tried if static weaving at the remote and calling side is a workaround ?

see http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance/Weaving/Static_Weaving

Comment by dmitriy.balakin [ 08/Mar/13 ]

I use eclipselink-staticweave-maven-plugin as a workaround.





[GLASSFISH-15946] EclipseLink regression: ManyToOne target, which extends a MappedSuperclass, fails Created: 10/Feb/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_b41
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: ljnelson Assignee: tware
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-fishcat, eclipselink, jpa, persistence

 Description   

I am posting this bug here to track the EclipseLink bug I filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=336879

This is present in EclipseLink 2.2.0-SNAPSHOT, which is the version used by Glassfish by default. I want to make sure that Glassfish 3.1 final incorporates a fix here. We have hundreds of these mappings deployed today and they work just fine in older versions of EclipseLink.



 Comments   
Comment by Chris Kasso [ 11/Feb/11 ]

This appears to be more of an edge case. Two workarounds exist. See:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=336879

for details.

Comment by Chris Kasso [ 11/Feb/11 ]

I'm closing this as won't fix since we will not fix this for 3.1. The underlying issue is represented by:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=336879

and will be picked up in a future release of GlassFish.





Generated at Sat May 23 09:35:16 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.