[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1181:
------------------------------------------------
Jesper Pedersen <jpederse(a)redhat.com> changed the Status of [bug 1107991|https://bugzilla.redhat.com/show_bug.cgi?id=1107991] from NEW to CLOSED
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.0.27.Final, 1.2.0.Beta4
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-3729) config-properties should be "read-write" by CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3729?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3729:
-----------------------------------------------
Jesper Pedersen <jpederse(a)redhat.com> changed the Status of [bug 1129496|https://bugzilla.redhat.com/show_bug.cgi?id=1129496] from NEW to CLOSED
> config-properties should be "read-write" by CLI
> -----------------------------------------------
>
> Key: WFLY-3729
> URL: https://issues.jboss.org/browse/WFLY-3729
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JCA
> Environment: EAP 6.1.0
> RHEL 6.5
> Reporter: Jooho Lee
> Assignee: Jesper Pedersen
> Labels: eap6, jboss
>
> Using CLI, it is possible to control websphere message server but config-properties can not be modified or created because its access-type is read-only.
> For example,
> {code:title=CLI Command|borderStyle=solid}
> /profile=MMPS-dev-03-profile/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=FDSLPublishQueue/config-properties=baseQueueName:write-attribute(name=value,value=test)
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014639: Attribute value is not writable",
> "rolled-back" => true
> }
> {code}
> This is because the fact that baseQueueName(config-properties)' access-type is read-only but I don't see any reasons why this attritbute couldn't be writable.
> Is there any reasons the attribute has to be read-only? otherwise, it should be read-write.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (ELY-81) {crypt} passwords in Apache DS longer than 8 characters are not compatible with Elytron
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-81:
-----------------------------------
Summary: {crypt} passwords in Apache DS longer than 8 characters are not compatible with Elytron
Key: ELY-81
URL: https://issues.jboss.org/browse/ELY-81
Project: WildFly Elytron
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Password Types, Realms
Reporter: Darran Lofthouse
Fix For: 1.0.0.Beta1
I have left this out of the pull request for LDAP as this is going to require some in-depth investigation of the two implementations and how they are both interpreting passwords longer than 8 characters.
It may be there is a subtle variation in the two implementations or it may just be one has a bug.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-81:
----------------------------------------
It belongs somewhere in /host=hc-1 itself. Not in the core-service=host-environment child as that resource is about the environmental info the HC picked up at initial boot, i.e. stuff that comes in from the command line.
The most relevant place is the domain-controller attribute on the /host=hc-1 resource:
{code}
[domain@localhost:9999 host=slave-a] :read-resource
{
"outcome" => "success",
"result" => {
"directory-grouping" => "by-server",
"domain-controller" => {"remote" => {
"port" => expression "${jboss.domain.master.port:9999}",
"host" => expression "${jboss.domain.master.address}",
"username" => undefined,
"admin-only-policy" => undefined,
"security-realm" => "ManagementRealm"
}},
{code}
That would need something like "resolved-scheme", "resolved-host" and "resolved-port" fields added. The "resolved-scheme" comes in because of WFCORE-75 which is currently being worked on. We can no longer assume the protocol scheme is "remote".
My thinking is we only expose this for the slave HC's; i.e. it's part of that domain-controller => remote structure that only exists on a slave. We don't add something to the domain-controller => local structure that exists on the master, because it would be redundant, and once WFCORE-75 is done, vague. The way to learn about how to communicate with any HC that you're already connected to is via the existing /host=*/core-service=management/management-interface=* resources.
As for what class to use to expose this... that's a tough question. Looking at this, it's quite complex. Possible places are org.jboss.as.host.controller.MasterDomainControllerClient or org.jboss.as.domain.controllerLocalHostControllerInfo.
The way that domain-controller attribute is handled would need to change though. Currently its contents are set once via RemoteDomainControllerAddHandler (for the slave aka remote case) and LocalDomainControllerAddHandler (for the master aka local case) and thereafter reading that attribute is a simple, using the default read handler. But now HostResourceDefinition L250 would need to register a custom read handler instead of null, one that can read the add in the dynamically determined "resolved-scheme", "resolved-host" and "resolved-port" fields.
So, not a simple task.
> Expose address of DC as runtime attributes on the HC
> ----------------------------------------------------
>
> Key: WFCORE-81
> URL: https://issues.jboss.org/browse/WFCORE-81
> Project: WildFly Core
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Rupp
> Labels: rhq
>
> Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime.
> 17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined
> [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute
> [17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http port of the DC
> [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well
> [17:04:51] <+bstansberry> yes please
> [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute
> 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address
> [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-3353) Multiple instance of the same ServletContainerInitializer can execute on single deployment
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3353?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-3353:
------------------------------------------
Should be "there is no check".
Doubt NPE is a good thing to throw into console.
org.apache.tomcat.websocket.server.WsSci: java.lang.NullPointerException
at org.apache.tomcat.websocket.server.WsServerContainer.<init>(WsServerContainer.java:133) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1]
This clearly states "something is not handled properly".
> Multiple instance of the same ServletContainerInitializer can execute on single deployment
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3353
> URL: https://issues.jboss.org/browse/WFLY-3353
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: Bartosz Baranowski
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> Not sure if this is a bug or requirement - though SCI JDOC does not mention anything that would justify same SCI class to execute more than once( neither does it deny it).
> Depending on AS version ServletContainerInitializers are handled bit differently( 7.x adds WsSci by default if jboss-web.xml has boolean flag for instance ), however all version allow to spawn SCI via jar services mechanism. Trick is that there is check on what and how is spawned. It is possible to spawn the same SCI twice and both will have a go. In case SCI does not behave or depends on servletContext.xxx methods return value, this can either make AS misbehave or throw NPE(from SCI) or other nasty exception. Example [1]
> [1] https://issues.jboss.org/browse/JBWEB-298
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFLY-716 to WFCORE-81:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-81 (was: WFLY-716)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: (was: Awaiting Volunteers)
> Expose address of DC as runtime attributes on the HC
> ----------------------------------------------------
>
> Key: WFCORE-81
> URL: https://issues.jboss.org/browse/WFCORE-81
> Project: WildFly Core
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Rupp
> Labels: rhq
>
> Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime.
> 17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined
> [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute
> [17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http port of the DC
> [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well
> [17:04:51] <+bstansberry> yes please
> [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute
> 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address
> [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-716) Expose address of DC as runtime attributes on the HC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-716?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry edited comment on WFLY-716 at 9/2/14 12:30 PM:
----------------------------------------------------------------
Hi, I would like to help on this. The DC port is visible in several places of wildfly-host-controller project, classes: DomainRootDefinition, RemoteDomainControllerAddHandler, but I could not find where to expose it as runtime attribute,
Should the dc port be displayed at this level (this is the slave hc) ?
{code}
/host=hc-1/core-service=host-environment:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"backup-domain-files" => false,
"default-jvm" => "/opt/javavm/bin/java",
"domain-base-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2",
"domain-config-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/configuration",
"domain-config-file" => undefined,
"domain-content-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/data/content",
"domain-data-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/data",
"domain-log-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/log",
"domain-servers-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/servers",
"domain-temp-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/tmp",
"home-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT",
"host-config-file" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/domain2/configuration/host.xml",
"host-controller-address" => "/127.0.0.1",
"host-controller-port" => 0,
"host-name" => "pavlov",
"initial-running-mode" => "NORMAL",
"is-restart" => false,
"modules-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules",
"process-controller-address" => "/127.0.0.1",
"process-controller-port" => 51563,
"qualified-host-name" => "pavlov",
"use-cached-dc" => false
}
}
{code}
Also, can you provide some guidance about which class should I take a look about adding this runtime attribute ?
was (Author: claudio4j):
Hi, I would like to help on this. The DC port is visible in several places of wildfly-host-controller project, classes: DomainRootDefinition, RemoteDomainControllerAddHandler, but I could not find where to expose it as runtime attribute,
Should the dc port be displayed at this level (this is the slave hc) ?
/host=hc-1/core-service=host-environment:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"backup-domain-files" => false,
"default-jvm" => "/opt/javavm/bin/java",
"domain-base-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2",
"domain-config-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/configuration",
"domain-config-file" => undefined,
"domain-content-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/data/content",
"domain-data-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/data",
"domain-log-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/log",
"domain-servers-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/servers",
"domain-temp-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/bin/../domain2/tmp",
"home-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT",
"host-config-file" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/domain2/configuration/host.xml",
"host-controller-address" => "/127.0.0.1",
"host-controller-port" => 0,
"host-name" => "pavlov",
"initial-running-mode" => "NORMAL",
"is-restart" => false,
"modules-dir" => "/home/claudio/alphaworks/projects/wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules",
"process-controller-address" => "/127.0.0.1",
"process-controller-port" => 51563,
"qualified-host-name" => "pavlov",
"use-cached-dc" => false
}
}
Also, can you provide some guidance about which class should I take a look about adding this runtime attribute ?
> Expose address of DC as runtime attributes on the HC
> ----------------------------------------------------
>
> Key: WFLY-716
> URL: https://issues.jboss.org/browse/WFLY-716
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Rupp
> Labels: rhq
> Fix For: Awaiting Volunteers
>
>
> Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime.
> 17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined
> [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute
> [17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http port of the DC
> [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well
> [17:04:51] <+bstansberry> yes please
> [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute
> 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address
> [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (WFLY-423) Allow management of all current Remoting connections (inbound and outbound)
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-423?page=com.atlassian.jira.plugin.s... ]
Claudio Miranda commented on WFLY-423:
--------------------------------------
Is this issue open for collaboration ? I would like to participate.
I see the REM3-147 is targeted for Remoting 4.1.0.Beta1, that is the current version in pom.xml (master).
> Allow management of all current Remoting connections (inbound and outbound)
> ---------------------------------------------------------------------------
>
> Key: WFLY-423
> URL: https://issues.jboss.org/browse/WFLY-423
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Remoting_Management
> Fix For: 9.0.0.CR1
>
>
> This task is to make it possible to view the details of all currently established Remoting connections and to allow termination of these connections.
> In addition to seeing the open connections it should be possible to see the channels opened by each connection. Also while starting on a connection first view you may also want to start on a channel first view i.e. all JNDI users or all EJB users.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (AS7-4710) PersistenceUnitSearch violates the JPA spec
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/AS7-4710?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on AS7-4710:
-----------------------------------
Some time has gone by since this change. If you are hitting a specific issue with WildFly, it is better to ask about your specific problem on the WildFly forums.
[https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPARefere...] mentions the "wildfly.jpa.default-unit" persistence unit property (hint) that can be used to choose the default persistence unit. If you are on WildFly and having issues when the unitName is not specificied (in @PersistenceContext), try choosing the persistence unit that should be the default one via:
{quote}
<property name="wildfly.jpa.default-unit" value="true"/>
{quote}
If you need more help, try asking in [https://community.jboss.org/en/wildfly?view=discussions].
> 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
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
> Attachments: persistence-scope-test-ear.zip
>
>
> 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 was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months