[JBoss JIRA] (EJBTHREE-2283) Please correct to return it to the receiver without changing the object type as it is when the Collection interface is used by the finder method of EJB2.1.
by 栗原 政彦 (JIRA)
栗原 政彦 created EJBTHREE-2283:
-------------------------------
Summary: Please correct to return it to the receiver without changing the object type as it is when the Collection interface is used by the finder method of EJB2.1.
Key: EJBTHREE-2283
URL: https://issues.jboss.org/browse/EJBTHREE-2283
Project: EJB 3.0
Issue Type: Feature Request
Components: ejb3_1
Affects Versions: EJB3_1 1.0.1
Environment: Red Hat Enterprise Linux Server release 5.5 Beta (Tikanga)
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) Server VM (build 22.0-b10, mixed mode)
Reporter: 栗原 政彦
Phenomenon
==========
We are shifting the EJB application made by the specification of EJB2.1 from WebLogic to JBossAS7.1.
Then, the problem occurs.
The value is set in ArrayList with EntityBean, and it returns it to Collection of SessionBean.
However, the problem returned in order of the row that is not the order of the set in ArrayList when returning to SessionBean occurs.
SessionBean of the receiver hopes to receive it without changing the arrangement of the set with EntityBean.
In JBoss, the class that can handle it by the Collection interface
(
For Example ,
List ( ArrayList / LinkedList / Vector ),
Set ( HashSet / TreeSet ) and
Map ( HashMap / TreeMap )
)
is put again in HashSet.
And the returned value is returned when called by the finder method of EntityBean.
Is this a specification?
When we proceed with the investigation from StackTrace, processing that put the object again in HashSet was done in [EntityBeanHomeFinderInterceptorFactory.java] .
The class that can handle it by the Collection interface seems to be putting it in HashSet for the Collection interface.
Reference
=========
Enterprise JavaBeansTM Specification and Version 2.1 specifications
http://download.oracle.com/otn-pub/jcp/ejb-2.1-fr-spec-oth-JSpec/ejb-2_1-...
Chapter of "12.1.8.2 Multi-Object Finders"
The Bean Provider can choose two types to define a collection type for a finder:
the Java(TM) 2 java.util.Collection interface
the JDK(TM) 1.1 java.util.Enumeration interface
A Bean Provider targeting containers and clients based on Java 2 should use the java.util.Collection
interface for the finder's result type.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBRULES-3505) Planner: DroolsScoreDirector's score corruption analysis returns the wrong lacking size
by Cedric Hurst (JIRA)
Cedric Hurst created JBRULES-3505:
-------------------------------------
Summary: Planner: DroolsScoreDirector's score corruption analysis returns the wrong lacking size
Key: JBRULES-3505
URL: https://issues.jboss.org/browse/JBRULES-3505
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-planner
Affects Versions: 5.4.0.CR1
Reporter: Cedric Hurst
Assignee: Geoffrey De Smet
Fix For: 5.4.0.Final
The scoreCorruptionAnalysis report returns the size of the excessSet when it should be returning the size of the lackingSet:
{code}
if (!lackingSet.isEmpty()) {
analysis.append(" The workingMemory has ").append(excessSet.size()) // this should be lackingSet.size()
.append(" ConstraintOccurrence(s) lacking:\n");
int count = 0;
for (Object o : lackingSet) {
if (count >= CONSTRAINT_OCCURRENCE_DISPLAY_LIMIT) {
analysis.append(" ... ").append(lackingSet.size() - CONSTRAINT_OCCURRENCE_DISPLAY_LIMIT)
.append(" more\n");
break;
}
analysis.append(" ").append(o.toString()).append("\n");
count++;
}
}
{code}
Patch forthcoming.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4786) MSC controller hangs when loading an ear with multiple presistance units on a single threaded machine
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-4786?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-4786:
-------------------------------------
I suspect the root cause of this would be MSC thread pool starvation, caused by org.jboss.as.jpa.service.PersistenceUnitServiceImpl starting in a MSC thread, instead of doing an async start.
Can you try starting the server with -Dorg.jboss.server.bootstrap.maxThreads=30 on the single core machine and see if this works?
> MSC controller hangs when loading an ear with multiple presistance units on a single threaded machine
> -----------------------------------------------------------------------------------------------------
>
> Key: AS7-4786
> URL: https://issues.jboss.org/browse/AS7-4786
> Project: Application Server 7
> Issue Type: Bug
> Environment: Centos 6, single core lib-virt VM
> Reporter: Wouter De Borger
> Assignee: David Lloyd
> Labels: hibernate, naming, race
>
> When deploying an EAR with two persistence units on single core machines, the server hangs.
> When increasing the number of cores to two, the same server just works.
> I traced the bug to the method in org.jboss.as.naming.WritableServiceBasedNamingStore.unbind
> The container attempts to register "hibernate/SessionFactory" twice.
> The first time it works, the second time it hangs on the wait statement.
> I suspect a race condition in the ServiceControllerImpl.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4809) AS fails to start with colon in path
by James Livingston (JIRA)
James Livingston created AS7-4809:
-------------------------------------
Summary: AS fails to start with colon in path
Key: AS7-4809
URL: https://issues.jboss.org/browse/AS7-4809
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Reporter: James Livingston
standalone.sh and domain.sh create the module path passed to JBoss Modules -mp option with:
JBOSS_MODULEPATH="$JBOSS_HOME/modules"
The value passed to -mp is a File.pathSeparator (colon on Linux and semicolon on Windows) delimited list of paths, not a single path, so this does not work correctly when JBOSS_HOME contains a colon on Linux, which is a legal but rare character to use in a path.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4808) authenticationManager not available when trying to access database from singleton EJB @PreDestroy method
by Ori Kremer (JIRA)
Ori Kremer created AS7-4808:
-------------------------------
Summary: authenticationManager not available when trying to access database from singleton EJB @PreDestroy method
Key: AS7-4808
URL: https://issues.jboss.org/browse/AS7-4808
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security, Server
Affects Versions: 7.1.2.Final (EAP), 7.1.1.Final, 7.0.2.Final
Reporter: Ori Kremer
Assignee: jaikiran pai
When a @PreDestroy singleton EJB method tries to access a secured datasource the following NPE is thrown:
15:38:25,159 WARN [org.jboss.as.ee] JBAS011005: Failed to destroy component instance org.jboss.as.ejb3.component.singleton.SingletonComponentInstance@17e123e: javax.ejb.EJBException: java.lang.NullPointerException
at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:78)
at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:93)
at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:108)
at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.BasicComponentInstance.destroy(BasicComponentInstance.java:119) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.component.singleton.SingletonComponent.destroySingletonInstance(SingletonComponent.java:179)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.stop(SingletonComponent.java:136)
at org.jboss.as.ee.component.ComponentStartService.stop(ComponentStartService.java:49) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_01]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_01]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_01]
Caused by: java.lang.NullPointerException
at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:88)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getSubject(AbstractConnectionManager.java:689)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:463)
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:129)
at org.test.UpdateStatus.updateStatus(UpdateStatus.java:53)
at org.test.UpdateStatus.stop(UpdateStatus.java:42)
at org.test.StartupSessionBean.stop(StartupSessionBean.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_01]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_01]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_01]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_01]
at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.1.1
.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptorFactory$ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptorFactory.java:90) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptorFactory$ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptorFactory.java:90) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:105)
... 16 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBPORTAL-2490) getting HTTP/1.1 401 Unauthorized when tried to hit the web service deployed on AS7
by Kap G (JIRA)
Kap G created JBPORTAL-2490:
-------------------------------
Summary: getting HTTP/1.1 401 Unauthorized when tried to hit the web service deployed on AS7
Key: JBPORTAL-2490
URL: https://issues.jboss.org/browse/JBPORTAL-2490
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Kap G
I am using Jboss AS7 (jboss-as-7.0.2.Final) and I have deployed a we service on the server. What I read from docs is, the mgmt-users.properties file could be used to add new user credentials (AS7 accepts any username/password pair anyways ) so I have added a new entry drools/drools. But when I hit the web-service I get,
11:39:24,095 ERROR [stderr] (qtp17107187-47 - /endpoints/validation) RuleAgent(default) WARNING (Mon May 14 11:39:24 EDT 2012): Was an error contacting http://localhost:8080/guvnor5.4/rest/packages/tov.aaa.abc.aixm/binary. Reponse header: {null=[HTTP/1.1 401 Unauthorized], WWW-Authenticate=[BASIC realm="users"], Date=[Mon, 14 May 2012 15:39:24 GMT], Content-Length=[0], Set-Cookie=[JSESSIONID=1hraSA18aXzMjOIBLx1rv-JT; Path=/guvnor5.4], Server=[Apache-Coyote/1.1]}
Could someone please tell me how do I get this working. Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4710) PersistenceUnitSearch violates the JPA spec
by Alexander Kiselyov (JIRA)
Alexander Kiselyov created AS7-4710:
---------------------------------------
Summary: PersistenceUnitSearch violates the JPA spec
Key: AS7-4710
URL: https://issues.jboss.org/browse/AS7-4710
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.1.Final
Environment: Linux (Ubuntu, kernel v.3.0.0-12-generic), Java HotSpot SE Runtime Environment (build 1.6.0_31-b04)
Reporter: Alexander Kiselyov
Assignee: Scott Marlow
There is no ability to deploy EAR, which contains several EJB-JAR modules, when more then one of them defining a persistence unit and at least one of EJBs within module "expresses a dependency on a container-managed EntityManager and its associated persistence context" (e.g. using @PersistenceContext annotation) without specifying the unitName.
Stacktrace during deployment process of such EAR:
13:45:36,765 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "persistence-scope-test-ear-ear.ear"
13:45:36,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar"
13:45:36,794 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar"
13:45:36,886 INFO [org.jboss.as.jpa] (MSC service thread 1-1) JBAS011401: Read persistence.xml for primary
13:45:36,889 INFO [org.jboss.as.jpa] (MSC service thread 1-4) JBAS011401: Read persistence.xml for primary
13:45:36,898 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar".DEPENDENCIES: Failed to process phase DEPENDENCIES of subdeployment "persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar" of deployment "persistence-scope-test-ear-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment "persistence-scope-test-ear-ear.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
at org.jboss.as.jpa.container.PersistenceUnitSearch.resolvePersistenceUnitSupplier(PersistenceUnitSearch.java:69)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getPersistenceUnit(JPAAnnotationParseProcessor.java:284)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getBindingSource(JPAAnnotationParseProcessor.java:220)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processField(JPAAnnotationParseProcessor.java:151)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:118)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
... 5 more
13:45:36,899 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar".DEPENDENCIES: Failed to process phase DEPENDENCIES of subdeployment "persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar" of deployment "persistence-scope-test-ear-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment "persistence-scope-test-ear-ear.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
at org.jboss.as.jpa.container.PersistenceUnitSearch.resolvePersistenceUnitSupplier(PersistenceUnitSearch.java:69)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getPersistenceUnit(JPAAnnotationParseProcessor.java:284)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getBindingSource(JPAAnnotationParseProcessor.java:220)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processField(JPAAnnotationParseProcessor.java:151)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:118)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
... 5 more
Issue is related to the AS7-2275 (https://issues.jboss.org/browse/AS7-2275).
JPA 2.0 specification (in paragraph "8.2.2 Persistence Unit Scope") states that:
"When referencing a persistence unit using the unitName annotation element or persistence-
unit-name deployment descriptor element, the visibility scope of the persistence unit is
determined by its point of definition:
• A persistence unit that is defined at the level of an EJB-JAR, WAR, or application client jar is
scoped to that EJB-JAR, WAR, or application jar respectively and is visible to the components
defined in that jar or war."
Although it says "when referencing... using the unitName", when in this case "unitName" attribute is omitted, I believe this (taking into account persistence units defined in other modules) is still a bug, cause:
1. The scope of a persistence unit is all the same implied by the spec, e.g. by sentences like this: "The persistence.xml file may be used to designate more than one persistence unit within the same scope. The persistence.xml file may be used to designate more than one persistence unit within the same scope."
2. AFAIK, neither JPA 2.0 nor EJB 3.1 specification defines any persistence unit choosing algorithm in case of unitName omission despite this attribute is optional.
Code responsible for generating an aforementioned exception resides in org.jboss.as.jpa.container.PersistenceUnitSearch:
PersistenceUnitsInApplication persistenceUnitsInApplication = DeploymentUtils.getTopDeploymentUnit(deploymentUnit).getAttachment(PersistenceUnitsInApplication.PERSISTENCE_UNITS_IN_APPLICATION);
if (persistenceUnitsInApplication.getCount() > 1) {
// AS7-2275 no unitName and there is more than one persistence unit;
throw MESSAGES.noPUnitNameSpecifiedAndMultiplePersistenceUnits(persistenceUnitsInApplication.getCount(),DeploymentUtils.getTopDeploymentUnit(deploymentUnit));
}
So, since a developer haven't defined any EAR-level persistence unit ant tries to inject EntityManager without using the unitName - all persistence unit defined in other EJB/WAR modules are taken into account and application is prevented from deploying because of "false ambiguity".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months