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 +0000, "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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
