RE: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
Hi Ceki, > >http://www.mail-archive.com/jboss-development@lists.sourceforge.net/msg10808.html > Thanks for the pointer. I was going to make these changes, but you've already provided the code :-) I think I said before, there are still some places that use Category directly. I'm changing these to use our Logger. NOTE for jboss-dev: I am aware of the bootstrap logger which didn't exist when Ceki provided this patch. Thanks again for help Ceki. Regards, Adrian _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
At 02:54 20.01.2002 +, Adrian Brock wrote: >Hi Ceki, > >>The problem *I* am interested in solving is to let each application >>have in its own independent logging universe. I don't see a problem >>with JBoss components sharing one logging universe (that of JBoss). > >Then basically we agree. I can deal with my extra complications once >I have this working. i.e. Allowing the Web Server an internal logging universe >separate from JBoss and the servlets it runs. Great. >>Thus, servlet code naturally log using the log4j classes >>loaded by the EJB classloader. In other words, one logging universe >>for the whole application. >>I am not familiar with JBoss way of organizing the classloader hierarchy >>although I would like to learn. > >Yes, JBoss works the same. Marc Fleury is about to commit >some code that makes this more interesting. I don't think it changes the >scope of what we are trying to do. >JBoss has a feature where even if you use the remote interface of a >j2ee bean from a servlet it actually does a local invocation since they >are deployed using the classloader. >Although this has been broken for a while in 3.0 pending Marc's changes. > >I have one question. I was about to try to implement JBoss RepositorySelector. with >each application having its own repository initially configured like the >JBoss universe, but with the application free to reconfigure. >But before I started I wanted to make sure log4j 1.2 didn't produce any funnies >with the current code. >I found the Category class in log4j 1.2 won't work with code compiled on earlier >versions. Is this deliberate, won't this cause problems when the source isn't >available to do recompiles? >Our compilation uses xdoclet which also uses log4j, so it is not >simply a case of recompiling JBoss. I'll have to recompile that as well. Yes, I am aware of the problem. I supplied a corrective patches some time ago both for jboss and also xdoclet. http://www.mail-archive.com/jboss-development@lists.sourceforge.net/msg10808.html We have gone to great lengths to ensure that version 1.2 is backward compatible with earlier versions. However, some previously deprecated APIs are now removed. Moreover, users who have written sub-classes of Category will need to modify their code. See the HISTORY file for more details. Regads, Ceki ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
Hi Ceki, >The problem *I* am interested in solving is to let each application >have in its own independent logging universe. I don't see a problem >with JBoss components sharing one logging universe (that of JBoss). Then basically we agree. I can deal with my extra complications once I have this working. i.e. Allowing the Web Server an internal logging universe separate from JBoss and the servlets it runs. >Thus, servlet code naturally log using the log4j classes >loaded by the EJB classloader. In other words, one logging universe >for the whole application. >I am not familiar with JBoss way of organizing the classloader hierarchy >although I would like to learn. Yes, JBoss works the same. Marc Fleury is about to commit some code that makes this more interesting. I don't think it changes the scope of what we are trying to do. JBoss has a feature where even if you use the remote interface of a j2ee bean from a servlet it actually does a local invocation since they are deployed using the classloader. Although this has been broken for a while in 3.0 pending Marc's changes. I have one question. I was about to try to implement JBoss RepositorySelector. with each application having its own repository initially configured like the JBoss universe, but with the application free to reconfigure. But before I started I wanted to make sure log4j 1.2 didn't produce any funnies with the current code. I found the Category class in log4j 1.2 won't work with code compiled on earlier versions. Is this deliberate, won't this cause problems when the source isn't available to do recompiles? Our compilation uses xdoclet which also uses log4j, so it is not simply a case of recompiling JBoss. I'll have to recompile that as well. Regards, Adrian _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
|Well, it really simple. In the case of Weblogic which does not use |log4j for its own logging, each application (that uses log4j) gets a |different copy of log4j classes loaded into memory. It follows that how, how is the "gets a different copy". i don't want to hear about the parent delegation model, What does that mean, from a class you do log.log(something) and how do you get the first reference. You seem to imply that there is a ContextClassLoader.getClass(log4j) or what? |Each log4j copy can be used and configured separately. In other words, |distinct jars uses distinct log4j copies. what I want to see is the code that sets up the reference you are using and I will be able to tell you |Now, since the war classloader is a child of the jar classloader, |everything seen by the parent (jar) classloader is seen by the war |classloader. Thus, the servlet part uses the same log4j copy as the |jar (ejb) part. Does this explain why the delegation model is in the |picture? no, it doesn't explain why you set up the reference and its configuration through the classloader. i want to hear about the getResourceAsStream(configuration) and the first reference to log4j, or the getClass or the classforname (god forbid) not the flaky parent delegation model which we understand perfectly (and go beyond in jboss3.0)... marcf | |Oh, btw, I am assuming log4j is *not* in the classpath. | |Regards, Ceki | |ps: For those on jboss-dev who did not follow the beginning of this |discussion on log4j-dev, here are the relevant threads: | |http://marc.theaimsgroup.com/?t=10107551141&r=1&w=2 |http://marc.theaimsgroup.com/?t=10111351264&r=1&w=2 | | | |>please let me know |> |>marcf |> |>|-Original Message- |>|From: [EMAIL PROTECTED] |>|[mailto:[EMAIL PROTECTED]]On Behalf Of Ceki |>|Gulcu |>|Sent: Thursday, January 17, 2002 1:37 PM |>|To: [EMAIL PROTECTED] |>|Subject: Re: [JBoss-dev] Re: The penny drops - JBoss Repository Selector |>| |>| |>| |>|The problem *I* am interested in solving is to let each application |>|have in its own independent logging universe. I don't see a problem |>|with JBoss components sharing one logging universe (that of JBoss). |>| |>|The case of Tomcat or any other servlet container is very interesting |>|because the user's servlet code is part of the user's |>|application. Consequently, servlets should log on the logging universe |>|of larger application. |>| |>|With the Weblogic 6.1 classloading scheme, this is very easy to |>|accomplish. In the Weblogic 6.1 classloader hierarchy EJBs have a |>|classloader which is also the parent of the web-application (WAR) |>|classloader. Thus, servlet code naturally log using the log4j classes |>|loaded by the EJB classloader. In other words, one logging universe |>|for the whole application. |>| |>|I am not familiar with JBoss way of organizing the classloader hierarchy |>|although I would like to learn. |>| |>|Anyway, some entity has to know at some point in time which WAR is |>|associated with which (EJB) JAR. That entity can easily set the |>| |>|oops... |>| |>|Jboss embeds the whole of Tomcat/Jetter/whatever. OK then how can the |>|servlets in an application access the *local* interface of entity |>|beans? |>| |>|Do you know what I am talking about? Has this issue been addressed in |>|JBoss 3.0? Regards, Ceki |>| |>| |>|At 16:56 17.01.2002 +, "Adrian Brock" <[EMAIL PROTECTED]> wrote: |>|>Hi Ceki, |>|> |>|>I'm trying to reduce the length of my posts, this one will probably |>|>break that rule :-( |>|> |>|>Re: Repositories |>|>I'll try explaining this from the beginning. We basically agree |>|>but I'm not getting my point across about multiple repositories. |>|>Maybe I'm missing one of your points as well? :-) |>|> |>|>First, here is what JBoss does at the moment. |>|>Nearly the first thing that happens is to deploy an MBean called |>|>Log4JService. This has the task of locating the property file |>|>and sets up the configureAndWatch. |>|>So we have one hierarchy for all logging. |>|> |>|>The problem we are trying to solve is what happens when something |>|>doesn't like the JBoss configuration and tries to reconfigure log4j. |>|> |>|>A related issue (not the original problem raised on log4j-user) is that |>|>a user wants to take a component that already does logging and put it in |>|>its own hierarchy/configuration. |>|> |>|>There are two types of deployment within JBoss. |>|>1) A service, such as embedded Tomcat. |>|>These could provide an internal mechanism for configuring log4j, it |>|>maybe useful for them to run in a different hierarchy. |>|
RE: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
At 17:28 17.01.2002 -0800, marc fleury wrote: >2.x uses the weblogic way of classloading (i.e. jar as parent of war). > >We ran into problems and limitations about a year ago, also where in the >picture are services. The classloading scheme is about to be changed when I >commit the Unified Deployer (JBossDeployer). It essentially shares the >classes through the URLClassloader of JBoss3.0. This goes for *everything* >applications, server modules, services, wars, everything. > >However in our case I am not sure I understand how log4j gets to its >classes. can you expand on the "thus servlet code naturally log using the >log4j classes loaded by the EJB classloader". How is the logging setup >done? what classes does it get? why is the parent delegation model in the >picture here. Well, it really simple. In the case of Weblogic which does not use log4j for its own logging, each application (that uses log4j) gets a different copy of log4j classes loaded into memory. It follows that Each log4j copy can be used and configured separately. In other words, distinct jars uses distinct log4j copies. Now, since the war classloader is a child of the jar classloader, everything seen by the parent (jar) classloader is seen by the war classloader. Thus, the servlet part uses the same log4j copy as the jar (ejb) part. Does this explain why the delegation model is in the picture? Oh, btw, I am assuming log4j is *not* in the classpath. Regards, Ceki ps: For those on jboss-dev who did not follow the beginning of this discussion on log4j-dev, here are the relevant threads: http://marc.theaimsgroup.com/?t=10107551141&r=1&w=2 http://marc.theaimsgroup.com/?t=10111351264&r=1&w=2 >please let me know > >marcf > >|-Original Message- >|From: [EMAIL PROTECTED] >|[mailto:[EMAIL PROTECTED]]On Behalf Of Ceki >|Gulcu >|Sent: Thursday, January 17, 2002 1:37 PM >|To: [EMAIL PROTECTED] >|Subject: Re: [JBoss-dev] Re: The penny drops - JBoss Repository Selector >| >| >| >|The problem *I* am interested in solving is to let each application >|have in its own independent logging universe. I don't see a problem >|with JBoss components sharing one logging universe (that of JBoss). >| >|The case of Tomcat or any other servlet container is very interesting >|because the user's servlet code is part of the user's >|application. Consequently, servlets should log on the logging universe >|of larger application. >| >|With the Weblogic 6.1 classloading scheme, this is very easy to >|accomplish. In the Weblogic 6.1 classloader hierarchy EJBs have a >|classloader which is also the parent of the web-application (WAR) >|classloader. Thus, servlet code naturally log using the log4j classes >|loaded by the EJB classloader. In other words, one logging universe >|for the whole application. >| >|I am not familiar with JBoss way of organizing the classloader hierarchy >|although I would like to learn. >| >|Anyway, some entity has to know at some point in time which WAR is >|associated with which (EJB) JAR. That entity can easily set the >| >|oops... >| >|Jboss embeds the whole of Tomcat/Jetter/whatever. OK then how can the >|servlets in an application access the *local* interface of entity >|beans? >| >|Do you know what I am talking about? Has this issue been addressed in >|JBoss 3.0? Regards, Ceki >| >| >|At 16:56 17.01.2002 +, "Adrian Brock" <[EMAIL PROTECTED]> wrote: >|>Hi Ceki, >|> >|>I'm trying to reduce the length of my posts, this one will probably >|>break that rule :-( >|> >|>Re: Repositories >|>I'll try explaining this from the beginning. We basically agree >|>but I'm not getting my point across about multiple repositories. >|>Maybe I'm missing one of your points as well? :-) >|> >|>First, here is what JBoss does at the moment. >|>Nearly the first thing that happens is to deploy an MBean called >|>Log4JService. This has the task of locating the property file >|>and sets up the configureAndWatch. >|>So we have one hierarchy for all logging. >|> >|>The problem we are trying to solve is what happens when something >|>doesn't like the JBoss configuration and tries to reconfigure log4j. >|> >|>A related issue (not the original problem raised on log4j-user) is that >|>a user wants to take a component that already does logging and put it in >|>its own hierarchy/configuration. >|> >|>There are two types of deployment within JBoss. >|>1) A service, such as embedded Tomcat. >|>These could provide an internal mechanism for configuring log4j, it >|>maybe useful for them to run in a different hierarchy. >|>2) A
RE: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
2.x uses the weblogic way of classloading (i.e. jar as parent of war). We ran into problems and limitations about a year ago, also where in the picture are services. The classloading scheme is about to be changed when I commit the Unified Deployer (JBossDeployer). It essentially shares the classes through the URLClassloader of JBoss3.0. This goes for *everything* applications, server modules, services, wars, everything. However in our case I am not sure I understand how log4j gets to its classes. can you expand on the "thus servlet code naturally log using the log4j classes loaded by the EJB classloader". How is the logging setup done? what classes does it get? why is the parent delegation model in the picture here. please let me know marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Ceki |Gulcu |Sent: Thursday, January 17, 2002 1:37 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Re: The penny drops - JBoss Repository Selector | | | |The problem *I* am interested in solving is to let each application |have in its own independent logging universe. I don't see a problem |with JBoss components sharing one logging universe (that of JBoss). | |The case of Tomcat or any other servlet container is very interesting |because the user's servlet code is part of the user's |application. Consequently, servlets should log on the logging universe |of larger application. | |With the Weblogic 6.1 classloading scheme, this is very easy to |accomplish. In the Weblogic 6.1 classloader hierarchy EJBs have a |classloader which is also the parent of the web-application (WAR) |classloader. Thus, servlet code naturally log using the log4j classes |loaded by the EJB classloader. In other words, one logging universe |for the whole application. | |I am not familiar with JBoss way of organizing the classloader hierarchy |although I would like to learn. | |Anyway, some entity has to know at some point in time which WAR is |associated with which (EJB) JAR. That entity can easily set the | |oops... | |Jboss embeds the whole of Tomcat/Jetter/whatever. OK then how can the |servlets in an application access the *local* interface of entity |beans? | |Do you know what I am talking about? Has this issue been addressed in |JBoss 3.0? Regards, Ceki | | |At 16:56 17.01.2002 +, "Adrian Brock" <[EMAIL PROTECTED]> wrote: |>Hi Ceki, |> |>I'm trying to reduce the length of my posts, this one will probably |>break that rule :-( |> |>Re: Repositories |>I'll try explaining this from the beginning. We basically agree |>but I'm not getting my point across about multiple repositories. |>Maybe I'm missing one of your points as well? :-) |> |>First, here is what JBoss does at the moment. |>Nearly the first thing that happens is to deploy an MBean called |>Log4JService. This has the task of locating the property file |>and sets up the configureAndWatch. |>So we have one hierarchy for all logging. |> |>The problem we are trying to solve is what happens when something |>doesn't like the JBoss configuration and tries to reconfigure log4j. |> |>A related issue (not the original problem raised on log4j-user) is that |>a user wants to take a component that already does logging and put it in |>its own hierarchy/configuration. |> |>There are two types of deployment within JBoss. |>1) A service, such as embedded Tomcat. |>These could provide an internal mechanism for configuring log4j, it |>maybe useful for them to run in a different hierarchy. |>2) An application. This is the original problem. The application wants |>to have a completely separate hierarchy and configuration to JBoss. |> |>The easy solution is every time I see a new ClassLoader in the |>RepositorySelector, create a new LoggerRepository. |>The configuration will either be specified at deployment or I |>use a fallback configuration. |>When something tries to reconfigure log4j it will be playing in its own |>backyard so problem solved. :-) |> |>But there are 50+ services in the default configuration of JBoss. |>Probably only the Web Server may want to reconfigure. The rest just |>want to use the JBoss hierarchy and configuration. I would like |>to let them share the same repository rather than creating 50 |>watchdog threads. | |>Now the extra complication I introduced. |>The deployer may want all their applications running in the |>repository/hierarchy, but not the JBoss one. |>Again it would be wasteful to create a repository for each |application when they are all sharing. |>I am not saying this is what will happen. As you said each applcation |>may want to specify its own log4j.properties. In this case, they |>each get a repository. | | |___ |Jboss-development mailing list |[EMA
Re: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
The problem *I* am interested in solving is to let each application have in its own independent logging universe. I don't see a problem with JBoss components sharing one logging universe (that of JBoss). The case of Tomcat or any other servlet container is very interesting because the user's servlet code is part of the user's application. Consequently, servlets should log on the logging universe of larger application. With the Weblogic 6.1 classloading scheme, this is very easy to accomplish. In the Weblogic 6.1 classloader hierarchy EJBs have a classloader which is also the parent of the web-application (WAR) classloader. Thus, servlet code naturally log using the log4j classes loaded by the EJB classloader. In other words, one logging universe for the whole application. I am not familiar with JBoss way of organizing the classloader hierarchy although I would like to learn. Anyway, some entity has to know at some point in time which WAR is associated with which (EJB) JAR. That entity can easily set the oops... Jboss embeds the whole of Tomcat/Jetter/whatever. OK then how can the servlets in an application access the *local* interface of entity beans? Do you know what I am talking about? Has this issue been addressed in JBoss 3.0? Regards, Ceki At 16:56 17.01.2002 +, "Adrian Brock" <[EMAIL PROTECTED]> wrote: >Hi Ceki, > >I'm trying to reduce the length of my posts, this one will probably >break that rule :-( > >Re: Repositories >I'll try explaining this from the beginning. We basically agree >but I'm not getting my point across about multiple repositories. >Maybe I'm missing one of your points as well? :-) > >First, here is what JBoss does at the moment. >Nearly the first thing that happens is to deploy an MBean called >Log4JService. This has the task of locating the property file >and sets up the configureAndWatch. >So we have one hierarchy for all logging. > >The problem we are trying to solve is what happens when something >doesn't like the JBoss configuration and tries to reconfigure log4j. > >A related issue (not the original problem raised on log4j-user) is that >a user wants to take a component that already does logging and put it in >its own hierarchy/configuration. > >There are two types of deployment within JBoss. >1) A service, such as embedded Tomcat. >These could provide an internal mechanism for configuring log4j, it >maybe useful for them to run in a different hierarchy. >2) An application. This is the original problem. The application wants >to have a completely separate hierarchy and configuration to JBoss. > >The easy solution is every time I see a new ClassLoader in the >RepositorySelector, create a new LoggerRepository. >The configuration will either be specified at deployment or I >use a fallback configuration. >When something tries to reconfigure log4j it will be playing in its own >backyard so problem solved. :-) > >But there are 50+ services in the default configuration of JBoss. >Probably only the Web Server may want to reconfigure. The rest just >want to use the JBoss hierarchy and configuration. I would like >to let them share the same repository rather than creating 50 >watchdog threads. >Now the extra complication I introduced. >The deployer may want all their applications running in the >repository/hierarchy, but not the JBoss one. >Again it would be wasteful to create a repository for each application when they are >all sharing. >I am not saying this is what will happen. As you said each applcation >may want to specify its own log4j.properties. In this case, they >each get a repository. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
