March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1006) isSameRmOverride doesn't take effect

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1006: -------------------------------------- Summary: isSameRmOverride doesn't take effect Key: JBJCA-1006 URL: https://issues.jboss.org/browse/JBJCA-1006 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.1.0.Beta4, 1.0.15.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Priority: Critical Fix For: 1.0.16.Final, 1.1.0.Beta5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-1769) PU Injection across JARs (separate DeploymentUnits)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-1769?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-1769: ----------------------------------- John, are you saying that you would package all artifacts in one (EAR) deployment? I think that is what users currently do today. One general question to any one that is following, I think that we might have a way to ensure that the deployment with the PU definition is deployed completely before the other deployments that depend on it but I'm not sure of the details (if there is even a way). As per what Stuart previously said, we can have the injecting side deployment, have a service dependency on the PU side, which would fail if the PU side is deployed last (I think). Scott > PU Injection across JARs (separate DeploymentUnits) > --------------------------------------------------- > > Key: AS7-1769 > URL: https://issues.jboss.org/browse/AS7-1769 > Project: Application Server 7 > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 7.0.1.Final, 7.1.0.Final, 7.1.1.Final > Environment: Linux, Window, MacOS, *BSD > Reporter: Nikos Ballas > Labels: new_and_noteworthy > > the following architecture of jars/wars doesn't load correctly in JBossAS 7 but it was used to load perfectly in all previous versions...i know about the new loading way so i am explaining the scenario: > > myjar-model.jar : Contains entities and the persistence.xml which defines also a persistence unit inside the META-INF folder. > myjar-buisness.jar: Contains EJB's and Spring beans that uses the model.There is an annotation with @PersistenceContext(name="mypu") on this EJB's for the entity manager to work. The jboss-deployment-structure.xml has declared dependency in the deployment.mcube-model.jar. > I am copying both of these files first the model and then the buisness in the standalone profile in deployments folder.The first one is loaded successfully.The second one that also uses classes from the previous one can see the classes but not the pu need it for the db operations.The exception follows: > [code] > 10:33:49,369 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."myjar-buisness.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."mcube-buisness.jar".INSTALL: Failed to process phase INSTALL of deployment "myjar-buisness.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765) > at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26] > at java.lang.Thread.run(Thread.java:662) [:1.6.0_26] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Component class ***.**.GenericDAOImpl for component MyBean has errors: > Can't find a deployment unit named myjar-persistence at deployment "myjar-buisness.jar" > at org.jboss.as.ee.component.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:133) > at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:52) > at org.jboss.as.ee.component.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:129) > at org.jboss.as.ee.component.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:122) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) > ... 5 more > [/code] > Following scenario/arcs: > Web application which is assembled by 4 different jars/wars: > (1)myapp-model.jar -> contains the model + persistence.xml containing the definition of a CMT. > (2)myapp-buisness.jar -> contains buisness EJB3's Spring Beans, whatever you can think of. > (3)myapp-messaging.jar -> Contains MDB's for sending messages to several queues. > (4)myapp-console.war -> Contains the web interface of the app. > Now the -> define a dependency from a project to another to function,i.e. A->B means that A project has a dependency in B. Now the graph of dependencies between projects are: > (4)->(2)->(1). > Currently in jboss as 7 you are able to deploy your application either as module exposing several services(even though there is no clear documentation on how you do that.You follow the old way, you have to do something else?Nowhere in any documentation isn't that documented.) or you can use the deployments folder and copy everything there.Given the previous scenario if we deploy the module(2) then even if we have as dependency in the jboss-deployment-structure.xml the reference to the module(1) then we will get an exception saying that the persistence unit defined isn't accessible or undefined for the module(2). Now with the new version of jboss that allow us to manipulate the dependencies using the module mechanism and the well defined deployment and dependencies between projects it would be really useful if. > When we define a dependency from one module to another, in my example from (2)->(1), also the mcs services defined are also exported in the target deployment, thus allowing access to the pu with the name for example is deployed. I don't know if this can be applied for the module architecture also. > regards > Nick -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-1769) PU Injection across JARs (separate DeploymentUnits)

by John Franey (JIRA)

[ https://issues.jboss.org/browse/AS7-1769?page=com.atlassian.jira.plugin.s... ] John Franey commented on AS7-1769: ---------------------------------- This would be a valid workaround, I think, as I understand the jee 6 persistence spec. myModel.jar contains persistence classes, and a orm.xml uniquely named, like 'my-model-orm.xml'. It does not contain a persistence.xml. any application using this model jar would contain: # class loading rules (as per jboss as7 classloader) for the application to find myModel.jar. # persistence.xml file #* referencing the uniquely named orm.xml with <mapping-file>my-model-orm.xml</mapping-file> #* located in the deployed application according to jee 6 persistence specification: 8.2 Disadvantage: * Finding persistence classes by scanning is not effective. They must be explicitly named in the orm file. * Configuration of the entity manager factory is responsibility of the application not the persistence unit. Advantage: * Depends on existing class loading implementation in jboss as7 and does not require change to hibernate module resources (as per [#comment-12702827]) * Configuration of the entity manager factory is controlled by the application. Any thoughts? > PU Injection across JARs (separate DeploymentUnits) > --------------------------------------------------- > > Key: AS7-1769 > URL: https://issues.jboss.org/browse/AS7-1769 > Project: Application Server 7 > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 7.0.1.Final, 7.1.0.Final, 7.1.1.Final > Environment: Linux, Window, MacOS, *BSD > Reporter: Nikos Ballas > Labels: new_and_noteworthy > > the following architecture of jars/wars doesn't load correctly in JBossAS 7 but it was used to load perfectly in all previous versions...i know about the new loading way so i am explaining the scenario: > > myjar-model.jar : Contains entities and the persistence.xml which defines also a persistence unit inside the META-INF folder. > myjar-buisness.jar: Contains EJB's and Spring beans that uses the model.There is an annotation with @PersistenceContext(name="mypu") on this EJB's for the entity manager to work. The jboss-deployment-structure.xml has declared dependency in the deployment.mcube-model.jar. > I am copying both of these files first the model and then the buisness in the standalone profile in deployments folder.The first one is loaded successfully.The second one that also uses classes from the previous one can see the classes but not the pu need it for the db operations.The exception follows: > [code] > 10:33:49,369 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."myjar-buisness.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."mcube-buisness.jar".INSTALL: Failed to process phase INSTALL of deployment "myjar-buisness.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765) > at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26] > at java.lang.Thread.run(Thread.java:662) [:1.6.0_26] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Component class ***.**.GenericDAOImpl for component MyBean has errors: > Can't find a deployment unit named myjar-persistence at deployment "myjar-buisness.jar" > at org.jboss.as.ee.component.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:133) > at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:52) > at org.jboss.as.ee.component.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:129) > at org.jboss.as.ee.component.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:122) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) > ... 5 more > [/code] > Following scenario/arcs: > Web application which is assembled by 4 different jars/wars: > (1)myapp-model.jar -> contains the model + persistence.xml containing the definition of a CMT. > (2)myapp-buisness.jar -> contains buisness EJB3's Spring Beans, whatever you can think of. > (3)myapp-messaging.jar -> Contains MDB's for sending messages to several queues. > (4)myapp-console.war -> Contains the web interface of the app. > Now the -> define a dependency from a project to another to function,i.e. A->B means that A project has a dependency in B. Now the graph of dependencies between projects are: > (4)->(2)->(1). > Currently in jboss as 7 you are able to deploy your application either as module exposing several services(even though there is no clear documentation on how you do that.You follow the old way, you have to do something else?Nowhere in any documentation isn't that documented.) or you can use the deployments folder and copy everything there.Given the previous scenario if we deploy the module(2) then even if we have as dependency in the jboss-deployment-structure.xml the reference to the module(1) then we will get an exception saying that the persistence unit defined isn't accessible or undefined for the module(2). Now with the new version of jboss that allow us to manipulate the dependencies using the module mechanism and the well defined deployment and dependencies between projects it would be really useful if. > When we define a dependency from one module to another, in my example from (2)->(1), also the mcs services defined are also exported in the target deployment, thus allowing access to the pu with the name for example is deployed. I don't know if this can be applied for the module architecture also. > regards > Nick -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-132) Update jboss-jta-api_spec to version 1.2

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-132?page=com.atlassian.jira.plugin.s... ] Shelly McGowan edited comment on JBEE-132 at 3/14/13 1:24 PM: -------------------------------------------------------------- Tom pointed out that TransactionalException is missing and needs to be added to the project. This has been added: https://github.com/jboss/jboss-transaction-api_spec/commit/89ebdfc880292d... was (Author: shelly.mcgowan): Tom pointed out that TransactionalException is missing and needs to be added to the project. > Update jboss-jta-api_spec to version 1.2 > ---------------------------------------- > > Key: JBEE-132 > URL: https://issues.jboss.org/browse/JBEE-132 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-javaee-specs > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > From the Change Log of JSR-970, the API additions are annotations for Transactional and TransactionScoped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6072) Automate creating EAP 6.x public API Javadoc

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-6072?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka commented on AS7-6072: ----------------------------------- PR for AS 8: https://github.com/jbossas/jboss-as/pull/4199 I will also create PR for the jboss-eap repo. > Automate creating EAP 6.x public API Javadoc > -------------------------------------------- > > Key: AS7-6072 > URL: https://issues.jboss.org/browse/AS7-6072 > Project: Application Server 7 > Issue Type: Enhancement > Components: Build System, Documentation > Affects Versions: 7.1.3.Final (EAP) > Reporter: Ondrej Zizka > Assignee: Ondrej Zizka > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > First attempt: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/EAP6-javadoc/ > What's needed: > * Blacklist of skipped .jar's (cause exceptions when generating) > * XSLT to put <include>'s to pom.xml > * XSLT to put <groups> to pom.xml > See also https://docspace.corp.redhat.com/docs/DOC-105009 (bottom) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-132) Update jboss-jta-api_spec to version 1.2

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-132?page=com.atlassian.jira.plugin.s... ] Shelly McGowan commented on JBEE-132: ------------------------------------- Tom pointed out that TransactionalException is missing and needs to be added to the project. > Update jboss-jta-api_spec to version 1.2 > ---------------------------------------- > > Key: JBEE-132 > URL: https://issues.jboss.org/browse/JBEE-132 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-javaee-specs > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > From the Change Log of JSR-970, the API additions are annotations for Transactional and TransactionScoped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1005) SemaphoreArrayListManagedConnectionPool should FIFO

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1005?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1005. ------------------------------------ Resolution: Done > SemaphoreArrayListManagedConnectionPool should FIFO > --------------------------------------------------- > > Key: JBJCA-1005 > URL: https://issues.jboss.org/browse/JBJCA-1005 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > > Currently behaving in FILO manner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1005) SemaphoreArrayListManagedConnectionPool should FIFO

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1005: -------------------------------------- Summary: SemaphoreArrayListManagedConnectionPool should FIFO Key: JBJCA-1005 URL: https://issues.jboss.org/browse/JBJCA-1005 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.1.0.Beta4, 1.0.15.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Priority: Critical Fix For: 1.0.16.Final, 1.1.0.Beta5 Currently behaving in FILO manner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6724) method-params containing an array not correctly processed for EJB2.1 with CMT

by Robert Panzer (JIRA)

[ https://issues.jboss.org/browse/AS7-6724?page=com.atlassian.jira.plugin.s... ] Robert Panzer commented on AS7-6724: ------------------------------------ Added Pull Request #4226: https://github.com/jbossas/jboss-as/pull/4226 > method-params containing an array not correctly processed for EJB2.1 with CMT > ----------------------------------------------------------------------------- > > Key: AS7-6724 > URL: https://issues.jboss.org/browse/AS7-6724 > Project: Application Server 7 > Issue Type: Feature Request > Components: EJB > Affects Versions: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final) > Environment: JBoss 7.2.0-Final Prerelease (Commit 4ed76c) and JBoss 7.1.3.Final on Win7/64 JDK 1.7.0_09 > Reporter: Robert Panzer > Assignee: jaikiran pai > Attachments: cmt-never-array-params.zip > > > It seems that the method-params for container transactions are not matched correctly if the contain arrays. > I've got an EJB "First" that calls another EJB "Second". Both have the same interface containing a method void test(String[]); > If I define the transaction attribute NEVER including method-params for "First" and without params for "Second" the test fails with > JBAS014163: Transaction present on server in Never call (EJB3 13.6.2.6) > I define the container transaction like this: > <container-transaction> > <method> > <ejb-name>FirstWithParams</ejb-name> > <method-intf>Local</method-intf> > <method-name>test</method-name> > <method-params> > <method-param>java.lang.String[]</method-param> > </method-params> > </method> > <method> > <ejb-name>FirstWithParams</ejb-name> > <method-intf>Local</method-intf> > <method-name>test</method-name> > <method-params> > <method-param>java.lang.String</method-param> > </method-params> > </method> > <method> > <ejb-name>FirstWithParams</ejb-name> > <method-intf>Local</method-intf> > <method-name>test</method-name> > <method-params> > <method-param>int</method-param> > </method-params> > </method> > <method> > <ejb-name>Second</ejb-name> > <method-intf>Local</method-intf> > <method-name>test</method-name> > </method> > <trans-attribute>Never</trans-attribute> > </container-transaction> > I will attach a test case that fails at the call to test(String[]) but successfully call test(String) and test(int). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6562) JSR-352 Batch Applications API support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/AS7-6562?page=com.atlassian.jira.plugin.s... ] James Perkins updated AS7-6562: ------------------------------- Comment: was deleted (was: No real plan yet, but I'll dig into this. I see our spec is up, but the JSR spec isn't final yet.) > JSR-352 Batch Applications API support > -------------------------------------- > > Key: AS7-6562 > URL: https://issues.jboss.org/browse/AS7-6562 > Project: Application Server 7 > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: Cheng Fang > Fix For: 8.0.0.Alpha1 > > > Support the Batch Applications for the Java Platform 1.0 spec as per Java EE 7 specification. > spec, RI & TCK page: http://java.net/projects/jbatch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2013