12 Replies Latest reply: Jan 3, 2012 9:18 AM by Scott Marlow RSS

JBoss Modules and a NICE Documentation

cirix Newbie

Dear all,

 

trying to develop in the new jboss 7, i can undestand that is a nice playground to test new things BUT is far from being an appserver to be use for

developing production critical systems. The only reason for it for me is clear and that's why i will probably will go back to JBoss 6.

THERE IS NO DESCENT DOCUMENTATION. Is clear for me when i have to choose, i would go for something that isn't cutting edge but is well documented, rather than something that is promised to be good but has no real documentation.We all know that coding is one thing but documentation something totally different and i think there was the success of the jboss appserver until now.The documentation was verbose and complete, whereas with the new version the team decided not to give the top QA it used to give on documenting the new appserver

.When i have a question on my head at the end the solution is to get from Git the sources and debug.BUT that's not productive.I want to focus on developing my application and not trying to discover how the app server works by reading the entire source tree.For me the biggest burden for example currently is that we all read about the jboss module architecture that will bring revolution to the way we deploy and handle applications.But tell me why i shouldn't choose over the OSGi that is REALLY WELL DOCUMENTED and has proven it's value.No after some <flame-mode>on</flame-mode>.

I need a clear answer where i can find documentation for implementing the following using jboss modules(links like classloading how to and jboss modules AREN'T accepted as valid BECAUSE THERE IS NO VALUABLE INFORMATION ON THEM.):

 

Module1: contains persistence.xml and the entity classses..

Module2: conatains the EJB's for the business layer and MUST be able to use the Module1.So there is a dependency from Module2->Module1.

Module3: contains the .war which will be the interface and is clear that :Module3->Module2->Module1 and Module3->Module1.

 

I have created the com/test/module1/main  com/test/module2/main and the resulting module.xml file respectively.But I DON'T SEE the modules

to be loaded.Trying to figure out how the classloadin will take place i am more confused than cleared.

 

The documentation of JBoss Module can only be characterised the lease deficient.

 

At the end i think i will either choose to go back to JBoss6 or go with the OSGi solution which i know how to do things.

 

at your disposal for any clarification.

 

best regards

\n\m

  • 1. Re: JBoss Modules and a NICE Documentation
    Nicklas Karlsson Master

    Going back to a platform that is no longer developed is a dead-end solution if I ever saw one.

     

    Granted, the docs are lagging behind and that is really a shame but the devs are very active on the forums solving problems that are clearly defined. I'm not sure about the RH documentation procedures, it might be that the pros over there are writing docs for the supported platform and they then trickle down to the open source version.

  • 2. Re: JBoss Modules and a NICE Documentation
    cirix Newbie

    Sorry Nicklas,

     

    but since I am in the business of software devel , let me inform you that for example banks would prefer an outdated technology that has 10/10 support and documentation than something that is cutting edge but has significant problems when you are trying to solve a problem using that technology.

    I know for example that you have oil companies that run systems still in jee 1.4.Because they are 100% sure that everything works as it supposed and

    the technology is mature.I know multimilion companies also that for example still go with tomcat and jboss 4.2 because of the reasons i mention.

    Doing software devel for fun and for the hack is somethinig totally different when you have to choose something that will be used for production or you

    want to devel a production system.Still i am lacking an "official" response.

     

    regards

    \n\m

  • 3. Re: JBoss Modules and a NICE Documentation
    Nicklas Karlsson Master

    I'm not arguing aginst the general principle, I'm just pointing out that AS 6 is a dead end. If you would have said "going back to EAP 5" I would have had nothing to object to.

  • 4. Re: JBoss Modules and a NICE Documentation
    David Bosschaert Expert

    Hi Nikos,

    Nikos Ballas wrote:

     

    But tell me why i shouldn't choose over the OSGi that is REALLY WELL DOCUMENTED and has proven it's value.

     

    You can also use OSGi directly in AS7 as it provides a fully compliant OSGI 4.2 Core Framework as part of the application server. For more information see here: http://www.jboss.org/jbossas/osgi

  • 5. Re: JBoss Modules and a NICE Documentation
    Stephen Coy Master

    You have described a classic JEE5/6 application structure which is extremely well documented in the JEE6 specs available at JSR 316: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification

  • 6. Re: JBoss Modules and a NICE Documentation
    cirix Newbie

    I know what i have described but apparently that isn't supported by  jboss7 yet.

  • 7. Re: JBoss Modules and a NICE Documentation
    Stephen Coy Master

    If I package my application as described in the spec then it works for me in JBossAS 7.1CR1b.

  • 8. Re: JBoss Modules and a NICE Documentation
    Ales Justin Master

    First of all, you're using JBossAS for free, as is everyone else, and time spent on the *free* forums is free as well.

    Hence I and probably others would appreciate a bit nicer "tone" and no UPPER CAPS, we get the point. ;-)

    Module1: contains persistence.xml and the entity classses..

    Module2: conatains the EJB's for the business layer and MUST be able to use the Module1.So there is a dependency from Module2->Module1.

    Module3: contains the .war which will be the interface and is clear that :Module3->Module2->Module1 and Module3->Module1.

     

    I have created the com/test/module1/main  com/test/module2/main and the resulting module.xml file respectively.But I DON'T SEE the modules

    to be loaded.Trying to figure out how the classloadin will take place i am more confused than cleared.

     

    Why are these static modules? Shouldn't this be plain deployments?

    And since every deployment is a module as well (w/o the need for module.xml), you can declare dependencies between them as well.

    * https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 --> see jboss-deployment-structure.xml

    e.g. simply having something like this as a dependency: deployment.mymodule1.jar

  • 9. Re: JBoss Modules and a NICE Documentation
    cirix Newbie

    @Stephen...for me it works to...but i don't want to use ears/wars only deployments .

    @Ales:

    The tone is something probably you are right i simply wanted to point out the frustration.Cause i keep on seeing responses in links like the ones you provided, which i have read over and over and did exactly that and of course nothing did work.And i pose and test jboss in my free time too.

    Yes yes , i tried the deployments and deployment you suggest in the link ,but i challenge you to do the following:

    1)Declare a jar where you will only have @Entity mappings with persistence.xml and orm.xml(not mandatory in JPA 2.0).Deploy that.

    2)Declare a jar where you will have your EJB's 3 which will implement a service layer and you need to do the @PersistenceContext(unitName="mypu").

        Deploy that following the jboss-deployment-structure.xml.I think you will be disappointed.I have already discussions with Scott Marlow on it...there is also a JIRA issue created out of it and currently there is no way to inject in different deployments services from other deployed jars.

    So when i sound frustrated isn't because that i want to be bad, or i want an answer to my problem, i know the RTFM answer and i give it really oftentoo, but for pointing out that for me i would like to use JBoss as a tool for free.If task force is need it for finishing it is one thing, but something totally different stating that the new JBoss is functional for production systems.The only JBoss i would use for now would be the EAP 5 or the  JBoss6 Final.+JBoss isn't the only appserver for free also and i must admit that i have thoughts of checking out Glassfish.

     

    Over and out

    \n\m

  • 10. Re: JBoss Modules and a NICE Documentation
    jaikiran pai Master

    Nikos Ballas wrote:

     

    Yes yes , i tried the deployments and deployment you suggest in the link ,but i challenge you to do the following:

    1)Declare a jar where you will only have @Entity mappings with persistence.xml and orm.xml(not mandatory in JPA 2.0).Deploy that.

    2)Declare a jar where you will have your EJB's 3 which will implement a service layer and you need to do the @PersistenceContext(unitName="mypu").

        Deploy that following the jboss-deployment-structure.xml.I think you will be disappointed.I have already discussions with Scott Marlow on it...there is also a JIRA issue created out of it and currently there is no way to inject in different deployments services from other deployed jars.

    So you have 2 independent deployments (one containing the persistence unit and the other using it) and you want to access the persistence unit in the second deployment? There's no portable way for it:

     

    JPA2 spec, section 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 persistence-

    unit-name deployment descriptor element, the visibility scope of the persistence unit is determined by its point of definition:

    - A persistence unit that is defined at the level of an EJB-JAR, WAR, or application client jar is scoped to that EJB-JAR, WAR, or application jar respectively and is visible to the components defined in that jar or war.

     

    - 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/persistenceUnitRoot. 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/persistenceUnitRoot.jar. The # syntax may be used with both the unitName annotation element or persistence-unit-name deployment descriptor element to reference a persistence unit defined at EAR level.

     

    Previous versions of JBoss AS used to allow it but it was a JBoss specific extension. I'm not sure if other servers support it.

     

    Nikos Ballas wrote:

    @Stephen...for me it works to...but i don't want to use ears/wars only deployments

    Any reason why you want to avoid such packaging which allows you to achieve the usecase you are after?

  • 11. Re: JBoss Modules and a NICE Documentation
    cirix Newbie

    @Stephen and here is the proof:https://issues.jboss.org/browse/AS7-1769

    @jaikiran:The point is the following.I would like to have a modular architecture.Imagine i have everything in non exploded ear and my ejb-jar file exposes

    some services to external clients.Now the scenario is i want to update the .war file for adding some new pages.Thus i would have down time for the services which should be working cause we are using what is called N-TIER architecture and for me that's the correct behaviour of an application that

    utilizes that type of architecture.Bundling everything up in an ear for my point of view isn't n-tier architecture in practice.Having different layers should imply that also from top down when you are making changes the change in a higher layer shouldn't  reflect changes in the lower application layer, thus no downtime or restart or redeploy of that layer would be needed.I was hoping that the module environment offered by jboss would be exactly that answer.This was more or less happening in the previous way of loading as long as the core dependency wasn't remove and that should always be the case.I mean if someone decides to bring down the persistence layer then no other service should be available if we are discussing for db driven apps, such then one i am on.I am aware of the jsr...but i think also you can inject in subdeployment in jboss by specifing the isolated subdeployments in the ee subsystem or in the jboss-deployement-structure file of the ear.But still from my description simply i think the correct technology to use is OSGi.I was hopping from what i was reading that JBoss Module would provide more or less the same layer of functionality but...far from being true .

     

    regards

    \n\m

  • 12. Re: JBoss Modules and a NICE Documentation
    Scott Marlow Master

    Nikos,

     

    I also would like to see AS7-1769 (sharing PUs between separate application deployments).  As mentioned on the forum discussion, each application that depends on the other application with the PU, will have a dependency on the PU application.

     

    I haven't had a chance to work on this myself.  The jira is unassigned so that any community contributor can jump in and work on it.  I think the general idea is best described in the above forum post link.

     

    Scott