Is JBoss Logging exposed as a public API through the module system?

If not, what is the recommended approach?

------------------------------------------------------------------------ *From: *"Jaikiran Pai" <jpai(a)redhat.com&gt; *To: *jboss-as7-dev(a)lists.jboss.org *Sent: *Friday, March 18, 2011 7:21:57 AM *Subject: *Re: [jboss-as7-dev] Question about JBoss Logging On Friday 18 March 2011 06:39 PM, Andrig Miller wrote: Is JBoss Logging exposed as a public API through the module system? From what I remember, it's not. If not, what is the recommended approach? Add the following to META-INF/MANIFEST.MF: Manifest-Version: 1.0 Dependencies: org.jboss.logging Do, I have to do this, plus the jboss-structure.xml? Andy -Jaikiran _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

From: "David M. Lloyd" <david.lloyd(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org Sent: Tuesday, March 22, 2011 10:19:26 AM Subject: Re: [jboss-as7-dev] Question about JBoss Logging A dependency added to an EAR won't automatically propagate to its constituent deployments unless you declare it as exported: Dependency: org.jboss.logging export Not sure it's ever been tried - good luck! ;-)

On 03/22/2011 11:16 AM, Andrig Miller wrote: > Jaikiran, > > I have tried the approach of adding the dependencies into the > MANIFEST.MF, but I still get the same class not found exception when > trying to use JBoss Logging. I have attached my ear file. Maybe > someone > could look at it, and see what I might be doing wrong. > > Andy > > ------------------------------------------------------------------------ > > *From: *"Andrig Miller" <anmiller(a)redhat.com&gt; > *To: *jpai(a)redhat.com > *Cc: *jboss-as7-dev(a)lists.jboss.org > *Sent: *Friday, March 18, 2011 9:51:31 AM > *Subject: *Re: [jboss-as7-dev] Question about JBoss Logging > > Okay, thanks. Ales pinged me via Skype and said the same thing. > > Thanks again. > > Andy > > ------------------------------------------------------------------------ > > *From: *"Jaikiran Pai" <jpai(a)redhat.com&gt; > *To: *"Andrig Miller" <anmiller(a)redhat.com&gt; > *Cc: *jboss-as7-dev(a)lists.jboss.org > *Sent: *Friday, March 18, 2011 9:02:59 AM > *Subject: *Re: [jboss-as7-dev] Question about JBoss Logging > > You _don't_ need the jboss-structure.xml (or any other JBoss > specific descriptors). > > -Jaikiran > On Friday 18 March 2011 08:17 PM, Andrig Miller wrote: > > > > ------------------------------------------------------------------------ > > *From: *"Jaikiran Pai" <jpai(a)redhat.com&gt; > *To: *jboss-as7-dev(a)lists.jboss.org > *Sent: *Friday, March 18, 2011 7:21:57 AM > *Subject: *Re: [jboss-as7-dev] Question about JBoss > Logging > > On Friday 18 March 2011 06:39 PM, Andrig Miller > wrote: > > > Is JBoss Logging exposed as a public API through > the > module system? > > From what I remember, it's not. > > If not, what is the recommended approach? > > Add the following to META-INF/MANIFEST.MF: > > Manifest-Version: 1.0 > Dependencies: org.jboss.logging > > Do, I have to do this, plus the jboss-structure.xml? > > Andy > > > > -Jaikiran > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > > > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org Sent: Tuesday, March 22, 2011 10:43:20 AM Subject: Re: [jboss-as7-dev] Question about JBoss Logging Hi all, can we make it an habit to create wiki articles in the AS7 development space, whenever we conquered a tough problem? I have done my bit. http://community.jboss.org/wiki/JBossAS7Logging http://community.jboss.org/wiki/AS7NetworkPorts http://community.jboss.org/wiki/AnilsCheatSheetforAS7Development Regards, Anil On 03/22/2011 11:34 AM, Andrig Miller wrote: > > ----- Original Message ----- >> From: "David M. Lloyd&quot;&lt;david.lloyd(a)redhat.com&gt; >> To: jboss-as7-dev(a)lists.jboss.org >> Sent: Tuesday, March 22, 2011 10:19:26 AM >> Subject: Re: [jboss-as7-dev] Question about JBoss Logging >> A dependency added to an EAR won't automatically propagate to its >> constituent deployments unless you declare it as exported: >> >> Dependency: org.jboss.logging export >> >> Not sure it's ever been tried - good luck! ;-) > Okay, I'll try that next. Here's to hoping it does work. > > Thanks. > >> On 03/22/2011 11:16 AM, Andrig Miller wrote: >>> Jaikiran, >>> >>> I have tried the approach of adding the dependencies into the >>> MANIFEST.MF, but I still get the same class not found exception >>> when >>> trying to use JBoss Logging. I have attached my ear file. Maybe >>> someone >>> could look at it, and see what I might be doing wrong. >>> >>> Andy >>> >>> ------------------------------------------------------------------------ >>> >>> *From: *"Andrig Miller&quot;&lt;anmiller(a)redhat.com&gt; >>> *To: *jpai(a)redhat.com >>> *Cc: *jboss-as7-dev(a)lists.jboss.org >>> *Sent: *Friday, March 18, 2011 9:51:31 AM >>> *Subject: *Re: [jboss-as7-dev] Question about JBoss Logging >>> >>> Okay, thanks. Ales pinged me via Skype and said the same >>> thing. >>> >>> Thanks again. >>> >>> Andy >>> >>> ------------------------------------------------------------------------ >>> >>> *From: *"Jaikiran Pai&quot;&lt;jpai(a)redhat.com&gt; >>> *To: *"Andrig Miller&quot;&lt;anmiller(a)redhat.com&gt; >>> *Cc: *jboss-as7-dev(a)lists.jboss.org >>> *Sent: *Friday, March 18, 2011 9:02:59 AM >>> *Subject: *Re: [jboss-as7-dev] Question about JBoss >>> Logging >>> >>> You _don't_ need the jboss-structure.xml (or any other >>> JBoss >>> specific descriptors). >>> >>> -Jaikiran >>> On Friday 18 March 2011 08:17 PM, Andrig Miller wrote: >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> *From: *"Jaikiran Pai&quot;&lt;jpai(a)redhat.com&gt; >>> *To: *jboss-as7-dev(a)lists.jboss.org >>> *Sent: *Friday, March 18, 2011 7:21:57 AM >>> *Subject: *Re: [jboss-as7-dev] Question about >>> JBoss >>> Logging >>> >>> On Friday 18 March 2011 06:39 PM, Andrig Miller >>> wrote: >>> >>> >>> Is JBoss Logging exposed as a public API >>> through >>> the >>> module system? >>> >>> From what I remember, it's not. >>> >>> If not, what is the recommended approach? >>> >>> Add the following to META-INF/MANIFEST.MF: >>> >>> Manifest-Version: 1.0 >>> Dependencies: org.jboss.logging >>> >>> Do, I have to do this, plus the jboss-structure.xml? >>> >>> Andy >>> >>> >>> >>> -Jaikiran _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

So, I got past the class not found exception for logging (I actually had to add org.jboss.logmanager export), since I was using the logmanager.

So, after getting past that, and successfully creating a module for MySQL and defining my data source, I know have another interesting issue with my ear file. I get the following: Caused by: java.lang.ClassNotFoundException: services.entities.Product from [Module "deployment.OrderManagerApp.ear.OrderManagerEJB.jar:main" from Service Module Loader] So, my ear is constructed in a fairly simple manner, and the same as it was for AS 5/6. I have an OrderManagerEntities.jar that has the entities in them, including the services.entities.Product that its complaining about, and that jar is in the ear, but the stateless session beans in OrderManagerEJB.jar reference it. It appears that there is not proper visibility to the entities in the other jar of the ear, and it cannot find it.

----- Original Message ----- > From: "David M. Lloyd" <david.lloyd(a)redhat.com&gt; > To: "Andrig Miller" <anmiller(a)redhat.com&gt; > Cc: jboss-as7-dev(a)lists.jboss.org > Sent: Tuesday, March 22, 2011 1:40:06 PM > Subject: Re: Question about EAR's and Class Loading > On 03/22/2011 02:29 PM, Andrig Miller wrote: >> So, I got past the class not found exception for logging (I actually >> had to add org.jboss.logmanager export), since I was using the >> logmanager. > > BTW we've been discussing this one - I think we're going to set it up > so > that manifest Dependencies at the EAR level are copied into their > constituent deployments, since this is probably what users will expect > will happen ("export" has certain potentially undesirable side-effects > with regards to class-path references between deployment units). So > expect the "export" to be no longer necessary in Beta2. > Excellent. That will be nice. >> So, after getting past that, and successfully creating a module for >> MySQL and defining my data source, I know have another interesting >> issue with my ear file. >> >> I get the following: >> >> Caused by: java.lang.ClassNotFoundException: >> services.entities.Product from [Module >> "deployment.OrderManagerApp.ear.OrderManagerEJB.jar:main" from >> Service Module Loader] >> >> So, my ear is constructed in a fairly simple manner, and the same as >> it was for AS 5/6. I have an OrderManagerEntities.jar that has the >> entities in them, including the services.entities.Product that its >> complaining about, and that jar is in the ear, but the stateless >> session beans in OrderManagerEJB.jar reference it. It appears that >> there is not proper visibility to the entities in the other jar of >> the ear, and it cannot find it. > > If OrderManagerEntities.jar is in the EAR's "lib" directory (or the > directory you have configured as such in application.xml) then the > OrderManagerEJB.jar should be able to "see" it. If not then you'll > need > an explicit "Class-Path" reference to it from your EJB JAR. No, my OrderManagerEntities.jar is not the EAR's "lib" directory, its at the same level as the OrderManagerEJB.jar, and its listed as an EJB module in the application.xml. This seems broken to me.

Andy > -- > - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

----- Original Message ----- > From: "David M. Lloyd&quot;&lt;david.lloyd(a)redhat.com&gt; To: "Andrig > Miller&quot;&lt;anmiller(a)redhat.com&gt; Cc: jboss-as7-dev(a)lists.jboss.org > Sent: Tuesday, March 22, 2011 1:40:06 PM Subject: Re: Question > about EAR's and Class Loading On 03/22/2011 02:29 PM, Andrig Miller > wrote: >> So, I got past the class not found exception for logging (I >> actually had to add org.jboss.logmanager export), since I was >> using the logmanager. > > BTW we've been discussing this one - I think we're going to set it > up so that manifest Dependencies at the EAR level are copied into > their constituent deployments, since this is probably what users > will expect will happen ("export" has certain potentially > undesirable side-effects with regards to class-path references > between deployment units). So expect the "export" to be no longer > necessary in Beta2. > Excellent. That will be nice. >> So, after getting past that, and successfully creating a module >> for MySQL and defining my data source, I know have another >> interesting issue with my ear file. >> >> I get the following: >> >> Caused by: java.lang.ClassNotFoundException: >> services.entities.Product from [Module >> "deployment.OrderManagerApp.ear.OrderManagerEJB.jar:main" from >> Service Module Loader] >> >> So, my ear is constructed in a fairly simple manner, and the same >> as it was for AS 5/6. I have an OrderManagerEntities.jar that has >> the entities in them, including the services.entities.Product >> that its complaining about, and that jar is in the ear, but the >> stateless session beans in OrderManagerEJB.jar reference it. It >> appears that there is not proper visibility to the entities in >> the other jar of the ear, and it cannot find it. > > If OrderManagerEntities.jar is in the EAR's "lib" directory (or > the directory you have configured as such in application.xml) then > the OrderManagerEJB.jar should be able to "see" it. If not then > you'll need an explicit "Class-Path" reference to it from your EJB > JAR. No, my OrderManagerEntities.jar is not the EAR's "lib" directory, its at the same level as the OrderManagerEJB.jar, and its listed as an EJB module in the application.xml.

> If OrderManagerEntities.jar is in the EAR's "lib" directory (or the > directory you have configured as such in application.xml) then the > OrderManagerEJB.jar should be able to "see" it. If not then you'll > need > an explicit "Class-Path" reference to it from your EJB JAR. No, my OrderManagerEntities.jar is not the EAR's "lib" directory, its at the same level as the OrderManagerEJB.jar, and its listed as an EJB module in the application.xml. This seems broken to me.

On 03/22/2011 02:42 PM, Andrig Miller wrote: >> If OrderManagerEntities.jar is in the EAR's "lib" directory (or the >> directory you have configured as such in application.xml) then the >> OrderManagerEJB.jar should be able to "see" it. If not then you'll >> need >> an explicit "Class-Path" reference to it from your EJB JAR. > > No, my OrderManagerEntities.jar is not the EAR's "lib" directory, its at the same level as the OrderManagerEJB.jar, and its listed as an EJB module in the application.xml. > > This seems broken to me. As a rule, we are restricting visibility by default as much as the spec allows (which may mean certain behaviors are different from AS 5/6). So the question is really, is this contrary to spec? If so, it's a bug. That's what we need to answer.

On 03/22/2011 02:51 PM, David M. Lloyd wrote: > On 03/22/2011 02:42 PM, Andrig Miller wrote: >>> If OrderManagerEntities.jar is in the EAR's "lib" directory (or the >>> directory you have configured as such in application.xml) then the >>> OrderManagerEJB.jar should be able to "see" it. If not then you'll >>> need >>> an explicit "Class-Path" reference to it from your EJB JAR. >> >> No, my OrderManagerEntities.jar is not the EAR's "lib" directory, its at the same level as the OrderManagerEJB.jar, and its listed as an EJB module in the application.xml. >> >> This seems broken to me. > > As a rule, we are restricting visibility by default as much as the spec > allows (which may mean certain behaviors are different from AS 5/6). So > the question is really, is this contrary to spec? If so, it's a bug. > That's what we need to answer. Here's the relevant passage: "Components in the EJB container may have access to the following classes and resources. Portable applications must not depend on having or not having access to these classes or resources. [...] * The content of any EJB jar files included in the same ear file. * The content of any client jar files specified by the above EJB jar files." Thus it is correct to require an explicit Class-Path between EJB JARs within an application.

On 3/22/11 3:08 PM, Jason T. Greene wrote: > On 3/22/11 2:58 PM, David M. Lloyd wrote: >> On 03/22/2011 02:51 PM, David M. Lloyd wrote: >>> On 03/22/2011 02:42 PM, Andrig Miller wrote: >>>>> If OrderManagerEntities.jar is in the EAR's "lib" directory (or the >>>>> directory you have configured as such in application.xml) then the >>>>> OrderManagerEJB.jar should be able to "see" it. If not then you'll >>>>> need >>>>> an explicit "Class-Path" reference to it from your EJB JAR. >>>> No, my OrderManagerEntities.jar is not the EAR's "lib" directory, >>>> its at the same level as the OrderManagerEJB.jar, and its listed as >>>> an EJB module in the application.xml. >>>> >>>> This seems broken to me. >>> As a rule, we are restricting visibility by default as much as the spec >>> allows (which may mean certain behaviors are different from AS 5/6). So >>> the question is really, is this contrary to spec? If so, it's a bug. >>> That's what we need to answer. >> Here's the relevant passage: >> >> "Components in the EJB container may have access to the following >> classes and resources. Portable applications must not depend on having >> or not having access to these classes or resources. >> [...] >> * The content of any EJB jar files included in the same ear file. >> * The content of any client jar files specified by the above EJB jar >> files." >> >> Thus it is correct to require an explicit Class-Path between EJB JARs >> within an application. > Note that its typically not required if you are using injection / jndi, > because then you are wiring a dependency and passing instances along > module boundaries. > > In the JPA case though, its just local classes, so their needs to be > some kind of import (/lib, class-path ref, module-ref) in our current > low-visibility model. BTW the reason we went with the low-visibility model, was that our thinking was it would reduce CCEs and allow for multiple EJB jars to use different versions of a thirdparty framework in the same EAR.

From: "Jason T. Greene" <jason.greene(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org Sent: Tuesday, March 22, 2011 2:08:18 PM Subject: Re: [jboss-as7-dev] Question about EAR's and Class Loading On 3/22/11 2:58 PM, David M. Lloyd wrote: > On 03/22/2011 02:51 PM, David M. Lloyd wrote: >> On 03/22/2011 02:42 PM, Andrig Miller wrote: >>>> If OrderManagerEntities.jar is in the EAR's "lib" directory (or >>>> the >>>> directory you have configured as such in application.xml) then >>>> the >>>> OrderManagerEJB.jar should be able to "see" it. If not then >>>> you'll >>>> need >>>> an explicit "Class-Path" reference to it from your EJB JAR. >>> >>> No, my OrderManagerEntities.jar is not the EAR's "lib" directory, >>> its at the same level as the OrderManagerEJB.jar, and its listed >>> as an EJB module in the application.xml. >>> >>> This seems broken to me. >> >> As a rule, we are restricting visibility by default as much as the >> spec >> allows (which may mean certain behaviors are different from AS >> 5/6). So >> the question is really, is this contrary to spec? If so, it's a >> bug. >> That's what we need to answer. > > Here's the relevant passage: > > "Components in the EJB container may have access to the following > classes and resources. Portable applications must not depend on > having > or not having access to these classes or resources. > [...] > * The content of any EJB jar files included in the same ear file. > * The content of any client jar files specified by the above EJB jar > files." > > Thus it is correct to require an explicit Class-Path between EJB > JARs > within an application. Note that its typically not required if you are using injection / jndi, because then you are wiring a dependency and passing instances along module boundaries. In the JPA case though, its just local classes, so their needs to be some kind of import (/lib, class-path ref, module-ref) in our current low-visibility model.

-- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I ask this on the forum, but haven't gotten a response, so I figured I would try here. I have been porting an application up to AS 7. In doing that, I changed the logging I was doing in the application (mostly trace level), and I changed it to use JBoss Logging directly. When I deploy the application, it fails with a class not found exception, where it cannot find the Level class. So, my questions are. Is JBoss Logging exposed as a public API through the module system? If not, was that intentional? If not, what is the recommended approach?