[ https://issues.jboss.org/browse/AS7-3148?page=com.atlassian.jira.plugin.s... ] Brent Douglas updated AS7-3148: ------------------------------- Description: It would be really handy to be able to specify dependencies for the deployment scanner to abide by. E.g. I have an application with the following structure: A.ear |-B.jar \-C.war D.war If D has a dependency on B and they are deployed at the same time I'll get: JBAS014775: New missing/unsatisfied dependencies: service jboss.module.spec.service."deployment.A.ear".main (missing) dependants: [service jboss.module.service."deployment.D.war".main, service jboss.deployment.unit."D.war".POST_MODULE] service jboss.module.spec.service."deployment.A.ear.B.jar".main (missing) dependants: [service jboss.module.service."deployment.D.war".main, service jboss.deployment.unit."D.war".POST_MODULE] It would be great though if I could specify that I don't want to deploy D until A is deployed. was: It would be really handy to be able to specify dependencies for the deployment scanner to abide by. E.g. I have an application with the following structure: A.ear |-B.jar \-C.war D.war If D has a dependency on B and they are deployed at the same time I'll get: JBAS014775: New missing/unsatisfied dependencies: service jboss.module.spec.service."deployment.A.ear".main (missing) dependants: [service jboss.module.service."deployment.D.war".main, service jboss.deployment.unit."D.war".POST_MODULE] service jboss.module.spec.service."deployment.A.ear.B.jar".main (missing) dependants: [service jboss.module.service."deployment.D.war".main, service jboss.deployment.unit."D.war".POST_MODULE] It would be great though if I could specify that I don't want to deploy D until A is deployed. Forum Reference: http://community.jboss.org/thread/176741 (was: http://community.jboss.org/thread/176741) -- 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

[ https://issues.jboss.org/browse/AS7-3148?page=com.atlassian.jira.plugin.s... ] Brent Douglas updated AS7-3148: ------------------------------- Description: It would be really handy to be able to specify dependencies for the deployment scanner to abide by. E.g. I have an application with the following structure: ' A.ear ' |-B.jar ' \-C.war ' ' D.war If D has a dependency on B and they are deployed at the same time I'll get: JBAS014775: New missing/unsatisfied dependencies: service jboss.module.spec.service."deployment.A.ear".main (missing) dependants: [service jboss.module.service."deployment.D.war".main, service jboss.deployment.unit."D.war".POST_MODULE] service jboss.module.spec.service."deployment.A.ear.B.jar".main (missing) dependants: [service jboss.module.service."deployment.D.war".main, service jboss.deployment.unit."D.war".POST_MODULE] It would be great though if I could specify that I don't want to deploy D until A is deployed. was: It would be really handy to be able to specify dependencies for the deployment scanner to abide by. E.g. I have an application with the following structure: | A.ear | |-B.jar | \-C.war | | D.war If D has a dependency on B and they are deployed at the same time I'll get: JBAS014775: New missing/unsatisfied dependencies: service jboss.module.spec.service."deployment.A.ear".main (missing) dependants: [service jboss.module.service."deployment.D.war".main, service jboss.deployment.unit."D.war".POST_MODULE] service jboss.module.spec.service."deployment.A.ear.B.jar".main (missing) dependants: [service jboss.module.service."deployment.D.war".main, service jboss.deployment.unit."D.war".POST_MODULE] It would be great though if I could specify that I don't want to deploy D until A is deployed. Forum Reference: http://community.jboss.org/thread/176741 (was: http://community.jboss.org/thread/176741) -- 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

[ https://issues.jboss.org/browse/AS7-3148?page=com.atlassian.jira.plugin.s... ] Brent Douglas updated AS7-3148: ------------------------------- Forum Reference: (was: http://community.jboss.org/thread/176741) -- 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

[ https://issues.jboss.org/browse/AS7-3148?page=com.atlassian.jira.plugin.s... ] Brent Douglas commented on AS7-3148: ------------------------------------ At the time of writing I was receiving the error in the description when A and D were picked up in the same scan. I hadn't tried this in a while as my deployment script currently waits on the creation of E.ear.deployed. I just tried it again and now get a different error that looks more like a race condition. This might not be the right JIRA for it though if what I am requesting is already the expected behaviour. In my case B.jar that contains entities and my persistence unit which provides an EntityManagerFactory via JNDI. D.war contains various seam2 components and its ManagedPersistenceContext tries to look up the EMF when the seam application starts. If both A and D are deployed in the same run the EMF is not available when D is starting. Is this intended or a bug? I will attach a log showing a deployment run where both are picked up at the same time and fail and then when they are deployed sequentially and succeed. The error when they are deployed concurrently is below: Caused by: java.lang.IllegalArgumentException: EntityManagerFactory not found in JNDI : java:/PlutoMainEntityManagerFactory at com.britensw.pluto.web.seam.ManagedPersistenceContext.getEntityManagerFactoryFromJndiOrValueBinding(ManagedPersistenceContext.java:188) [classes:] at com.britensw.pluto.web.seam.ManagedPersistenceContext.createContext(ManagedPersistenceContext.java:91) [classes:] at com.britensw.pluto.web.seam.ManagedPersistenceContext.create(ManagedPersistenceContext.java:84) [classes:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_30] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_30] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_30] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_30] at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) [jboss-seam-2.2.2.Final.jar:2.2.2.Final] at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144) [jboss-seam-2.2.2.Final.jar:2.2.2.Final] at org.jboss.seam.Component.callComponentMethod(Component.java:2283) [jboss-seam-2.2.2.Final.jar:2.2.2.Final] at org.jboss.seam.Component.callCreateMethod(Component.java:2198) [jboss-seam-2.2.2.Final.jar:2.2.2.Final] at org.jboss.seam.Component.newInstance(Component.java:2158) [jboss-seam-2.2.2.Final.jar:2.2.2.Final] ... 37 more Caused by: javax.naming.NameNotFoundException: Error looking up PlutoMainEntityManagerFactory, service service jboss.naming.context.java.PlutoMainEntityManagerFactory is not started at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:177) at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:113) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:213) at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_30] at com.britensw.pluto.web.seam.ManagedPersistenceContext.getEntityManagerFactoryFromJndiOrValueBinding(ManagedPersistenceContext.java:186) [classes:] ... 48 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

[ https://issues.jboss.org/browse/AS7-3148?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-3148: --------------------------------------- at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_30] at com.britensw.pluto.web.seam.ManagedPersistenceContext.getEntityManagerFactoryFromJndiOrValueBinding(ManagedPersistenceContext.java:186) There is no guarantee of a dependency relationship between deployments when programmatic lookups like this are used. If you use EE injection or EE deployment descriptors, when the deployments are processed the relationships are detected and appropriate service dependencies are created. But the deployers have no visibility to this kind of programatic lookup. See https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7 for information on how to declare dependencies between deployments. BTW, if you are controlling this stuff with scripts, why not have the scripts control the CLI? You can get a lot more control over the behavior of the CLI than you can over the scanner. -- 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

[ https://issues.jboss.org/browse/AS7-3148?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved AS7-3148. ----------------------------------- Fix Version/s: No Release Resolution: Rejected Closing as the mechanisms for establishing relationships between deployments as described at https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7 take care of the issue. -- 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

[ https://issues.jboss.org/browse/AS7-3148?page=com.atlassian.jira.plugin.s... ] Jye Tucker edited comment on AS7-3148 at 2/1/12 1:16 AM: --------------------------------------------------------- Just flagging that I believe there is still an issue with dependencies and deployment scanner - specifically with dependencies between deployed OSGi bundles. I've been tracking this down for the last week, but I think it may be to do with how the dependency management explained in the URL above (using Dependencies header in MANIFEST.MF) relates to the actual OSGi bundle state. It has been occurring randomly so I'm attempting to reproduce consistently at the moment - but I believe the deployment scanner is managing the dependencies only up to the point where the OSGi bundle is installed, but may not yet be exporting packages via the OSGi subsystem and making it's classpath available to dependencies. For example, if I have an API and Implementation bundle in the deployments dir at startup (Implementation has a dependency specified in the manifest on API - deployment.bundle-api:0.0.0) the API bundle seems to be correctly picked up first by the deployment scanner, but the deployment of the implementation bundle can randomly fail with a ClassNotFoundException on an API class. Manually starting the Implementation bundle later will then work - presumably because the API bundle is fully resolved and started at this point. Deploying manually or via script in the order of classpath dependencies always works. Brian - would you mind commenting on whether you think this theory makes sense? If so, I'm happy to keep chasing down this path. Also let me know if you'd prefer to keep this issue closed and have a new one created. Thanks. was (Author: jye.tucker): Just flagging that I believe there is still an issue with dependencies and deployment scanner - specifically with dependencies between deployed OSGi bundles. I've been tracking this down for the last week, but I think it may be to do with how the dependency management explained in the URL above (using Dependencies header in MANIFEST.MF) relates to the actual OSGi bundle state. It has been occurring randomly so I'm attempting to reproduce consistently at the moment - but I believe the deployment scanner is managing the dependencies only up to the point where the OSGi bundle is installed, but may not yet be exporting packages via the OSGi subsystem and making it's classpath available to dependencies. For example, if I have an API and Implementation bundle in the deployments dir at startup (Implementation has a dependency specified in the manifest on API - deployments.bundle-api:0.0.0) the API bundle seems to be correctly picked up first by the deployment scanner, but the deployment of the implementation bundle can randomly fail with a ClassNotFoundException on an API class. Manually starting the Implementation bundle later will then work - presumably because the API bundle is fully resolved and started at this point. Deploying manually or via script in the order of classpath dependencies always works. Brian - would you mind commenting on whether you think this theory makes sense? If so, I'm happy to keep chasing down this path. Also let me know if you'd prefer to keep this issue closed and have a new one created. 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

[ https://issues.jboss.org/browse/AS7-3148?page=com.atlassian.jira.plugin.s... ] Jye Tucker commented on AS7-3148: --------------------------------- Thanks Brian - makes sense. -- 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