1 2 Previous Next 16 Replies Latest reply: Jan 4, 2012 4:07 PM by cirix RSS

JBossAS7 Deployments

cirix Newbie

Hi all,

 

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]

 

I would like also to point out that in both jboss-structure-deployment.xml of both projects i haven't put the declaration to any javax.api org.hibernate dependencies, because according to the documentation these are implicit deployments dependecies and when the appserver tries to deploy something if it discovers several specific annotations it will attach the required dependency.

 

Another more theoritical question that crossed my mind.According to the new versoin of jboss the old hierachical class loaders are gone, solving tones of probles with classloading.But from my perspective the simple solution given by the jboss modules is that instead of doing that automatically and not in a smart way(hierarchical loading) we through the ball to the user's playground.So he is responsible for defining correctly the dependencies between the projects he creates.Eventhough i really like the new jboss does the above point make anysense to anyone else?Currently i am spending alot of time and effort to migrate my previous jboss 6 project to the new appserver and i would expect it to be much m uch more easier...

 

regards

\n\m

 

p.s.: I am using maven 2.2.1 for project management, i.e. dependencies and building.

  • 1. Re: JBossAS7 Deployments
    cirix Newbie

    I found a relevant post about making a persistence unit available for other deployments.The response is that back then jboss wasn't able to make a persistence unit availabe to other deployments in other jars...any update on that.The problem is that i didn't see any JIRA created about it and now i understand why so much of the tutorials/examples prefer the ear way of deployments....

  • 2. Re: JBossAS7 Deployments
    Scott Marlow Master

    Please create a jira, if you feel like it.  I think the related thread was http://community.jboss.org/thread/171444.  The other post mentioned that AS 5.1 supported your case.

     

    With earlier AS versions, did you use the InterApplicationPersistenceUnitDependencyResolver mentioned in doc http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Web_Platform/5/html/Administration_And_Configuration_Guide/Deployment.html?

     

    Also, I'm thinking that the InterApplicationPersistenceUnitDependencyResolver (extension) might be better replaced by explicit references to the containing archive.  So, I think the PU name would be "myjar-model.jar#myjar-persistence".  This would prevent the wrong database from being used in an application that accidently left out the persistence.xml (containing a short name pu "MYPU") that coincidentaly is the same pu name used in some other app.

     

    I should point out that the current AS7 behaviour is SPEC compliant with regard to PU scope.  I don't mind adding requested extensions if they don't conflict with the spec.  Will have to think about this one.  Please do create the jira and share any additional information about the (cross app pu search) behaviour that you are expecting to work.  A link to the any related doc that describes it is welcome (if different than my link above).

    8.2.2 Persistence Unit Scope

    An EJB-JAR, WAR, application client jar, or EAR can define a persistence unit.

    When referencing a persistence unit using the unitName annotation element or persis-

    tence-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.

    • A persistence unit that is defined at the level of the EAR is generally visible to all components

    in the application. However, if a persistence unit of the same name is defined by an EJB-JAR,

    WAR, or application jar file within the EAR, the persistence unit of that name defined at EAR

    level will not be visible to the components defined by that EJB-JAR, WAR, or application jar

    file unless the persistence unit reference uses the persistence unit name # syntax to specify a

    path name to disambiguate the reference. When the # syntax is used, the path name is relative

    to the referencing application component jar file. For example, the syntax ../lib/persis-

    tenceUnitRoot.jar#myPersistenceUnit refers to a persistence unit whose name,

    as specified in the name element of the persistence.xml file, is myPersistenceUnit

    and for which the relative path name of the root of the persistence unit is ../lib/persis-

    tenceUnitRoot.jar. The # syntax may be used with both the unitName annotation ele-

    ment or persistence-unit-name deployment descriptor element to reference a

    persistence unit defined at EAR level.

     

    Scott

  • 3. Re: JBossAS7 Deployments
    cirix Newbie

    Hi Scott,

    thanks for the answer, and yes the mentioned thread is the one i was refering to.IMHO the fact that you have to deploy ears to have the functionallity described for me is lacking flexibility.What i mean by that is simple and previous version of jboss allowd the behaviour mentioned in my post + the one you posted.Imagine i want to have my model and then i want to make a changed in my buisness jar.If i deploy everything in an ear like way this means i have to stop also me GUI for the users and redeploy everything from scratch for no apparent reason.This behaviour don't respect the loosle coupled architecture between components of an N-tier web app for my point of view.I should be able to make changes to either of the layers with no affect to the other.Also i would like to know what is SPEC?JBoss spec or JSR specs so that i can read it somewhere. I have downloaded the source and i plan to debug and see how the searching and injection of pu's is done in the new version.I will come back with my findings.Thanks again for the information.

    I will perform also the following test to see if it will make any difference:

    1)I will transform my jars in jboss modules.

    2)I will deploy my model as module and  exporting the services it creates.

    3)I will deploy my buisness as module and will import the services provided by the model.

     

    That's the only workaround i can thing at the moment just before going to the the OSGi and see what benefits i can have from there...

     

    i will be back with news.

     

    regards

    \n\m

  • 4. Re: JBossAS7 Deployments
    Scott Marlow Master

    You didn't mention if your using the InterApplicationPersistenceUnitDependencyResolver option or not in your applications that deploy on earlier JBoss AS versions.  Also, creating a jira for this would be helpful.

     

    The PU search code is in the AS7 project (https://github.com/jbossas/jboss-as) org.jboss.as.jpa.container.PersistenceUnitSearch.  It sounds like you already found the source but wanted to mention it for others.  Documentation on building/hacking is here http://community.jboss.org/wiki/HackingOnAS7

     

    I think that a patch would need to add a way for the PersistenceUnitSearch module to search for the PU across all deployments.  The old (not JPA spec compliant) way used to just walk throw all deployments (see http://www.docjar.com/html/api/org/jboss/jpa/resolvers/strategy/JBossSearchStrategy.java.html).

     

    The specification document that I referenced is the JSR 317 http://jcp.org/aboutJava/communityprocess/final/jsr317/index.html.

  • 5. Re: JBossAS7 Deployments
    Scott Marlow Master

    Another more theoritical question that crossed my mind.According to the new versoin of jboss the old hierachical class loaders are gone, solving tones of probles with classloading.But from my perspective the simple solution given by the jboss modules is that instead of doing that automatically and not in a smart way(hierarchical loading) we through the ball to the user's playground.So he is responsible for defining correctly the dependencies between the projects he creates.Eventhough i really like the new jboss does the above point make anysense to anyone else?Currently i am spending alot of time and effort to migrate my previous jboss 6 project to the new appserver and i would expect it to be much m uch more easier...

     

    To really dive into this subject, it would be less confusing to have a separate thread (instead of being buried in a PU search thread that not everyone will read.)  Perhaps some suggestions might come up about easing the pain of sharing dependencies. 

  • 6. Re: JBossAS7 Deployments
    cirix Newbie

    Hi Scott,

     

    thanks for taking the time discussing this. I have never gone into details on how the dependency resolver was working in versions of jboss6 and lower.I simply new that it was scanning and could find any pu deployed.The code i am debugging is PersitenceUnitSearch.Ok then i must go throughout the specification carefully. I will create a JIRA with the desired behaviour. My simple thought:Since with the jboss-deployment-structure.xml and module.xml where you can define fully the dependencies between deployments/modules. I have overcome the ClassNotFoundExceptions i had between my deployments.But why also the services deployed can't be also exported/imported in deployments?The previous is the reason for testing the module way...Later today i will create the JIRA.

     

    regards

    \n\m

  • 7. Re: JBossAS7 Deployments
    Scott Marlow Master

    Its fine about the older deployments, if you happened to know, that would of been interesting.

     

    A list of AS7 subprojects is here http://community.jboss.org/wiki/AS7Projects, in case you need it later.

     

    It would be nice, if adding a module depedency on another application archive, could expose/export the PUs also.  So, that you could use the short PU name, as you would of before.

  • 8. Re: JBossAS7 Deployments
    cirix Newbie

    Hi Scott,

     

    the debuggin for showed that there are two classes that needs to be changed:

    1)DeploymentUnitPhaseService.java

    2)PersistenceUnitSearch.java.

     

    The first one creates the context of the module deployed and there is clear that even the model jar is a dependency and is imported the classes are injected correctly to the new buisness module but not the pu, thus when the annotation for the PersistenceContext is discovered inside an abstract class discovered it fails since this dependency isn't communicated from one module to another. I plan to go throughout the code and see where probably the changes need to be applied.Also i have created the JIRA: https://issues.jboss.org/browse/AS7-1769

     

    regards

    \n\m

  • 9. Re: JBossAS7 Deployments
    Scott Marlow Master

    I agree that PersistenceUnitSearch would need to change but I'm not sure of what else at this point.  I look forward to hearing more. 

     

    Could you try to make the jira summary a bit clearer?  Also, for the description, try to make it a little more concrete (at least at the top of the description) and directed at the problem at hand.  Maybe something like "PU Injection across JARs (separate DeploymentUnits)" for the summary would work.  Everything that you said at the begining of this forum post (up to the exception), would be good for the description (IMO). 

     

    Also, its not an EJB issue, so I removed EJB from the jira.

  • 10. Re: JBossAS7 Deployments
    cirix Newbie

    Hi Scott,

     

    i updated the description + the summary of the JIRA issue. I have some news also since i spend most of the time yesterday night doing the debug and follow the method calls in the deployment code.I believe when i will return from work today i will invastigate further and i will let you know my findings.

     

    regards

    \n\m

  • 11. Re: JBossAS7 Deployments
    Scott Marlow Master

    Hi Nikos,

     

    Thanks for updating the description/summary.

     

    One of the questions that I have, is whether class PersistenceUnitSearch can walk through the DeploymentUnit's of other archives.  If the answer is yes, I think we can structure a solution to use that.  If not, my other thought is that the JPA subsystem needs to accommodate the need. 

     

    You seem to have some ideas in mind already and I don't want to discourage that.  As maybe you will see an easier way than me. 

     

    Even if you don't find an easier way, your looking at the code, will still help, as you will be familar enough to help make the fix.

     

    Scott

  • 12. Re: JBossAS7 Deployments
    Scott Marlow Master

    One of the questions that I have, is whether class PersistenceUnitSearch can walk through the DeploymentUnit's of other archives.  If the answer is yes, I think we can structure a solution to use that.  If not, my other thought is that the JPA subsystem needs to accommodate the need.  

     

    PersistenceUnitSearch cannot expect to walk through the other the DeploymentUnit's of other top level deployments.  Which makes this harder to solve. 

     

    Some of the requirements are:

     

    1) sharing a PU requires sharing the PU underlying service, and that means we need a service dependency else it will break easily (handling the shared deployment not being  ready).

     

    2) a class level dependency will also be needed (for access to the entity classes in the shared top level deployment).

     

    Probably changing the injected persistence unit name to be a full scoped PU name reference (to the shared top level deployment PU), would also be part of this.

     

    Is this something that you still want to work on solving and contributing a fix for?  There are smaller/easier JPA issues to work on, if you want to start with something easier.  Let me know.

     

    Scott

  • 13. Re: JBossAS7 Deployments
    cirix Newbie

    Hi Scott,

     

    i am back this week will be diffucult...migration stuff @ work taking to much time of my time.Nevertheless doing my research i noticed (after enabling the trace of log) that the META-INF/jboss-deployment-structure.xml is ignored.My thought is simple:

    I know that jboss-deployment-structure.xml can well define the deployment of a module/jar in JBoss but apparently, from my findings i may be wrong, when you use the file scanner method,aka deployments, the contents under META-INF aren't taken into account.Correct me if i am wrong on that.Now

    my will is that the jboss-deployment-structure.xml will be the troyan horse for manipulating also the dependecies of the deployments.we can declare dependencies to jars it would be nice to be able to define deps to other services in the system, thus no need to scan all the deployments path.If someone declares a dependency in a pu that doesn't exist then he would get a very nice exception.On the other hand i want to go into details on the jboss-modules class loading mechanism to understand exactly how the loading is done and if the module.xml/jboss-deployment-structure.xml are actually the xml description of the dependency graph of the project/module to be deployed and when are used.Because i am not 100% sure that they are always used.

     

    regards

    Nikos

  • 14. Re: JBossAS7 Deployments
    Scott Marlow Master

    Nikos,

     

    I think that there are two parts to this.  Taking care of the classloader dependencies (whether by MANIFEST.MF Class-Path entries or using jboss-deployment-structure.xml). The other part requires some small code changes (I think). 

     

    I think we should try a small change to PersistenceUnitSearch.resolvePersistenceUnitSupplier().  Or more specifically, to private  method PersistenceUnitSearch.PersistenceUnitMetadata getPersistenceUnit(DeploymentUnit current, final String absolutePath, String puName). 

     

    The code change will be something like:

     

     

    PersistenceUnitSearch.java ....

     

    // add persistenceUnitName to method signature (local var in resolvePersistenceUnitSupplier method)

    private static PersistenceUnitMetadata getPersistenceUnit(DeploymentUnit current, final String absolutePath, String puName, String persistenceUnitName) {

     

    for (ResourceRoot resourceRoot : resourceRoots) // search in current deployment

       ...

    }

    // end of for for (ResourceRoot resourceRoot : resourceRoots) loop

     

    // see if we can reference another deployement for the persistence unit definition

     

    // get the MSC service registry so we can attempt lookup of the pu service

    ServiceRegistry serviceRegistry = current.getServiceRegistry();

     

    String puServiceName = persistenceUnitName;

    ServiceName targetPuServiceName = JPAServiceNames.getPUServiceName(puServiceName);

    // lookup the pu service

    ServiceController serviceController = serviceRegistry.getService(targetPuServiceName);

    Service<PersistenceUnitServiceImpl> service = (Service<PersistenceUnitServiceImpl>) serviceController.getService();

    if (service != null) {

       return service.getPersistenceUnitMetadata();

    }

     

    // give up, throw not found error...

    throw MESSAGES.deploymentUnitNotFound(absolutePath, puName, current)

     

    // file PersistenceUnitServiceImpl.java

     

    // add getter for pu instance variable

    public PersistenceUnitMetadata getPersistenceUnitMetadata() {

       return pu;

    }

1 2 Previous Next