[JBoss JIRA] (AS7-6735) JBoss Web SingleSignOn valve does not work with <distributable/> apps
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/AS7-6735?page=com.atlassian.jira.plugin.s... ]
Dennis Reed updated AS7-6735:
-----------------------------
Description:
The JBoss Web SingleSignOn valve does not work with <distributable/> applications.
It incorrectly disassociates the SSO when a session is passivated.
Since this happens on every request with <distributable/> applications (for session replication), the SSO entry is destroyed at the end of the request.
The same issue of the SSO being removed would also happen if the session is passivated for any other reason.
was:
The JBoss Web SingleSignOn valve does not work with <distributable/> applications.
It incorrectly disassociates the SSO when a session is passivated.
Since this happens on every request (for session replication) with <distributable/> applications, the SSO cookie is destroyed at the end of the request.
The same issue of the SSO being removed would also happen if the session is passivated for any other reason.
> JBoss Web SingleSignOn valve does not work with <distributable/> apps
> ---------------------------------------------------------------------
>
> Key: AS7-6735
> URL: https://issues.jboss.org/browse/AS7-6735
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Dennis Reed
> Assignee: Remy Maucherat
>
> The JBoss Web SingleSignOn valve does not work with <distributable/> applications.
> It incorrectly disassociates the SSO when a session is passivated.
> Since this happens on every request with <distributable/> applications (for session replication), the SSO entry is destroyed at the end of the request.
> The same issue of the SSO being removed would also happen if the session is passivated for any other reason.
--
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
[JBoss JIRA] (AS7-6735) JBoss Web SingleSignOn valve does not work with <distributable/> apps
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/AS7-6735?page=com.atlassian.jira.plugin.s... ]
Dennis Reed edited comment on AS7-6735 at 3/14/13 4:07 PM:
-----------------------------------------------------------
Note: the test case in the AS7 test suite for this valve (testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/web/sso/SingleSignOnUnitTestCase.java) fails because of this.
was (Author: dereed):
Note: the test case in the AS7 test suite for this valve (testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/web/sso/.SingleSignOnUnitTestCase.java) fails because of this.
> JBoss Web SingleSignOn valve does not work with <distributable/> apps
> ---------------------------------------------------------------------
>
> Key: AS7-6735
> URL: https://issues.jboss.org/browse/AS7-6735
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Dennis Reed
> Assignee: Remy Maucherat
>
> The JBoss Web SingleSignOn valve does not work with <distributable/> applications.
> It incorrectly disassociates the SSO when a session is passivated.
> Since this happens on every request (for session replication) with <distributable/> applications, the SSO cookie is destroyed at the end of the request.
> The same issue of the SSO being removed would also happen if the session is passivated for any other reason.
--
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
[JBoss JIRA] (AS7-6735) JBoss Web SingleSignOn valve does not work with <distributable/> apps
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/AS7-6735?page=com.atlassian.jira.plugin.s... ]
Dennis Reed commented on AS7-6735:
----------------------------------
Note: the test case in the AS7 test suite for this valve (testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/web/sso/.SingleSignOnUnitTestCase.java) fails because of this.
> JBoss Web SingleSignOn valve does not work with <distributable/> apps
> ---------------------------------------------------------------------
>
> Key: AS7-6735
> URL: https://issues.jboss.org/browse/AS7-6735
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Dennis Reed
> Assignee: Remy Maucherat
>
> The JBoss Web SingleSignOn valve does not work with <distributable/> applications.
> It incorrectly disassociates the SSO when a session is passivated.
> Since this happens on every request (for session replication) with <distributable/> applications, the SSO cookie is destroyed at the end of the request.
> The same issue of the SSO being removed would also happen if the session is passivated for any other reason.
--
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
[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:
----------------------------------
I am in the middle of trying it. I'm able to deploy a jar file with a persistence unit depending on persistence classes in a predeployed: deployment.xxxx.ear.myModel.jar. There is no deploy error from as7.1.1, but I haven't yet invoked the service from a client just yet.
I know it is not exactly what is asked for, but it seemed related. I think the original request is derived from a desire to isolate the application deployment from the model deployment, so that they can be upgraded independently.
The original thinking for this is to put the persistence unit in with the model, and most of the design notes above have been around how to make that work. My suggestion takes a different approach. With the persistence unit in the application deployable, it is discovered when the application is deployed, and as7 gives access to the orm.xml and the persistence classes with the as7 classloading rules. There is not a technical problem, or so I put forth here. So, if the packaging design is acceptable to the original poster, I think the requirement of independent deployment can be met without waiting for this issue resolved.
> 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
[JBoss JIRA] (AS7-6735) JBoss Web SingleSignOn valve does not work with <distributable/> apps
by Dennis Reed (JIRA)
Dennis Reed created AS7-6735:
--------------------------------
Summary: JBoss Web SingleSignOn valve does not work with <distributable/> apps
Key: AS7-6735
URL: https://issues.jboss.org/browse/AS7-6735
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.3.Final (EAP)
Reporter: Dennis Reed
Assignee: Remy Maucherat
The JBoss Web SingleSignOn valve does not work with <distributable/> applications.
It incorrectly disassociates the SSO when a session is passivated.
Since this happens on every request (for session replication) with <distributable/> applications, the SSO cookie is destroyed at the end of the request.
The same issue of the SSO being removed would also happen if the session is passivated for any other reason.
--
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
[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:
-----------------------------------
Thanks for clarifying John and sharing on this! Your use case is a little different than was originally brought up in this jira (the AS7-1769 related use case has persistence.xml + entities in the same deployment unit). Are you thinking about trying your approach or have tried it?
> 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
[JBoss JIRA] (AS7-4292) Invalid bundle deployment does not fail in domain
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4292?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler reassigned AS7-4292:
-----------------------------------
Assignee: Thomas Diesler
> Invalid bundle deployment does not fail in domain
> -------------------------------------------------
>
> Key: AS7-4292
> URL: https://issues.jboss.org/browse/AS7-4292
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Priority: Minor
> Fix For: 8.0.0.Alpha1
>
>
> Running org.jboss.as.test.integration.domain.suites.OSGiBundleLifecyleTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 35.653 sec <<< FAILURE!
> on the server I see
> {code}
> 15:20:28,619 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit.bad-bundle.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.bad-bundle.STRUCTURE: Failed to process phase STRUCTURE of deployment "bad-bundle"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 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_29]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NumberFormatException: For input string: "bogus"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) [rt.jar:1.6.0_29]
> at java.lang.Integer.parseInt(Integer.java:449) [rt.jar:1.6.0_29]
> at java.lang.Integer.parseInt(Integer.java:499) [rt.jar:1.6.0_29]
> at org.osgi.framework.Version.<init>(Version.java:125)
> at org.osgi.framework.Version.parseVersion(Version.java:218)
> at org.jboss.osgi.spi.BundleInfo.validateBundleManifest(BundleInfo.java:204)
> at org.jboss.osgi.spi.BundleInfo.isValidBundleManifest(BundleInfo.java:153)
> at org.jboss.as.osgi.deployment.OSGiManifestStructureProcessor.deploy(OSGiManifestStructureProcessor.java:63)
> {code}
--
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
[JBoss JIRA] (AS7-6054) Package uses conflict with org.springframework.ldap
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6054?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved AS7-6054.
---------------------------------
Fix Version/s: (was: 8.0.0.Alpha1)
Resolution: Won't Fix
Resolver errors come from the Felix Resolver. You could create a bug with them and cross reference this one.
> Package uses conflict with org.springframework.ldap
> ---------------------------------------------------
>
> Key: AS7-6054
> URL: https://issues.jboss.org/browse/AS7-6054
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: Windows XP SP2
> Oracle JDK 1.6.0_32
> Reporter: Ed Roberts
>
> I am able to recreate a bundle resolution problem that gives very little help in where the cause lies.
> We deploy a set of Spring 3.1.1.RELEASE bundles in the bundles directory structure, exposed through the standalone.xml capabilities. Separately, a set of bundles are located in the deployments folder, and they include/use some Spring 3.0.7.RELEASE; e.g. beans and core. The reason for the duplication is because a particular LDAP bundle does not work with the later spring bundles. When I deploy the spring-security-ldap-3.1.1.RELEASE.jar in the deployments folder, I get the following WARNING in the console/log file
> {code}
> 2012-11-27 16:24:13,808 WARN [org.jboss.as.osgi](MSC service thread 1-5) JBAS011910: Cannot resolve requirements: []
> {code}
> The cause of the issue was located during a debug session, to be
> {code}
> Chain 1:
> org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.beans
> org.springframework.beans [HostBundleRevision[org.springframework.beans:3.0.7.RELEASE]]
> Chain 2:
> org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.context.support; uses:=org.springframework.beans
> org.springframework.context [HostBundleRevision[org.springframework.context:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.beans
> org.springframework.beans [HostBundleRevision[org.springframework.beans:3.1.1.RELEASE]]
> {code}
> It seems that when there are multiple providers of a requirement, the requiring bundle is deemed invalid. That doesn't seem correct. Should it not just choose the first valid provider ? Either way, when the Unresolved Bundles are empty in BundleResolveProcessor, the details of the multiple providers should at least be logged as an ERROR as it prevents the bundle from being successfully resolved.
--
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
[JBoss JIRA] (AS7-5958) Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved AS7-5958.
---------------------------------
Fix Version/s: (was: 8.0.0.Alpha1)
Resolution: Out of Date
Please verify and reopen for AS8
> Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5958
> URL: https://issues.jboss.org/browse/AS7-5958
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: Windows XP SP3
> Reporter: Paul Illingworth
>
> I am getting the following exception when my bundle is being resolved. I don't believe this is correct.
> {noformat}
> 2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate permutation failed due to a conflict between imports; will try another if possible.: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package 'com.google.inject' from resources com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
> Chain 1:
> resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.google.inject
> com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
> Chain 2:
> resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets; uses:=com.google.inject
> reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.google.inject
> com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
> at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
> at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
> at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
> 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.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
> at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
> at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
> at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
> at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
> at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
> at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:662)
> 2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release framework lock
> {noformat}
> It seems to be happening because the ResolverImpl.isCompatible() method is comparing two capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that contains the same instance of AbstractBundleCapability. The result of the comparison is false.
> As a quick hack I changed the equals method of WrappedCapability to
> {noformat}
> @Override
> public boolean equals(Object obj)
> {
> return m_cap.equals(obj);
> }
> {noformat}
> and that seemed to make it work and resolution was successful.
--
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
[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 edited comment on AS7-1769 at 3/14/13 3:05 PM:
-----------------------------------------------------------
{quote}
John, are you saying that you would package all artifacts in one (EAR) deployment? I think that is what users currently do today.
{quote}
No. The myModel.jar would be predeployed (as module or deployment) separately from the applications that depend on it.
Applications (ear, war or deployable jars) would declare their dependency on 'external' myModel in the usual as7 way.
Each application has its own private persistence unit, named the same but not necessarily. The persistence classes and the orm are in the shared deployment/module. The persistence unit is NOT in the shared deployment/module.
was (Author: jjfraney):
{quote}
John, are you saying that you would package all artifacts in one (EAR) deployment? I think that is what users currently do today.
{quote}
No. The myModel.jar would be predeployed (as module or deployment) separately from the applications that depend on it.
Applications (ear, war or deployable jars) would declare their dependency on 'external' myModel in the usual as7 way.
Each application has its own private persistence unit, named the same but not necessarily. The persistence classes and the orm are in the shared deployment/module, not the persistence unit.
> 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