"logger.isDebugEnabled()"= false

@ SleeContainer.java

log4j that is...

agora ve la o printInvocationSequence no SbbObject

true :(

eu acho q tem a ver com o class loader na invoca??o ser mudado para o do sbb, que penso q seja o do tmp/deploy/...

01:20:02,018 INFO [STDOUT] [SleeContainer] Activated ServiceID[DiameterTestsService#org.mobicents#1.0]

01:20:02,080 INFO [DiameterTestsSbb] sbbRolledBack invoked.

what's different here... no [STDOUT] no do SBB... meaning q n ta a "cair" no log4j do mobicentimos

bzzzt

q raio de path: \servers\jain-slee\core\sar\log4-rs\src\src\main

2008-07-18 02:37:34,668 DEBUG [org.jboss.logging.Log4jRepositorySelector] Unknown classloader : c3ad9b, type : class org.jboss.mx.loading.UnifiedClassLoader3

barreiro: ate amanha, tens trabalho no http://code.google.com/p/mobicents/issues/detail?id=203

martins, tas a pedir ao Amit e ao Vlad, mas eu ek tenho mexido naqueles scripts ultimamente.

martins: o logger em ConcreteSbbGenerator eh child do ROOT, o do SbbDeployer ? child do mpbicents ... ja n faz mt sentido ser a cena do tmp, estas 2 classes devem estar no mesma situacao

ate pq os RAs tb vao parar a tmp e n lhes acontece isso :s

martins: leste o q deixei ai de manh??

org.mobicents.slee.container.deployment.SbbDeployer logger parent => mobicents

org.mobicents.slee.container.deployment.ConcreteSbbGenerator logger parent => root

[30224,RepositoryClassLoader,main] loadClass org.jboss.mx.loading.UnifiedClassLoader3@7b6617{ url=file:/C:/Work/JBoss/server/default/deploy/mobicents.sar/ ,addedOrder=16} name=org.mobicents.slee.container.deployment.SbbDeployer, loadClassDepth=0

[38062,RepositoryClassLoader,main] loadClass org.jboss.mx.loading.UnifiedClassLoader3@7b6617{ url=file:/C:/Work/JBoss/server/default/deploy/mobicents.sar/ ,addedOrder=16} name=org.mobicents.slee.container.deployment.ConcreteSbbGenerator, loadClassDepth=0

mesmo package, mesmo sar, mesmo classloader ... no comprendo.

n sei se ? o mesmo

pq quando o codigo do sbb generator ? chamado ? usado o class loader do sbb

ve o metodo no SleeContainer

private synchronized void installSbb(

final MobicentsSbbDescriptor mobicentsSbbDescriptor)

throws Exception {

da? vai para sbbDeployer.deploySbb(mobicentsSbbDescriptor, this);

e ? a? q o generator ? chamado

exacto, foi dai q eu vi q os loggers eram diferentes

loadClass org.jboss.mx.loading.UnifiedClassLoader3@7b6617 == loadClass org.jboss.mx.loading.UnifiedClassLoader3@7b6617

e mm asim em debug a fiz this.getClass().getClassLoader() nos dois e deu o mm

a classe pode ter o mesmo class loader mas quando ? executado o class loader ? o do sbb

tal como na entrega do evento

ah, estar a ser executado no contexto do sbb e o classloader ser diferente

hum

n me parece coincidencia q sempre q mudas o classloader para o do sbb o logger ja n esteja afectado pela config do log4j do mobicents

epa, mas isso de qq forma deveria afectar os dois. a cena eh q n vejo a razao de ser de uma maneir p 1 e de outra p outro

estou a pensar bem.. ou n? :P

quais 2

sbbDeployer VS ConcreteSbbGenerator

uma vez q o ConcreteSbbGenerator eh chamado pelo SbbDeployer ... as condicoes sao as mesmas para ambos

public boolean deploySbb(MobicentsSbbDescriptor sbbDeploymentDescriptor,

SleeContainer serviceContainer) throws DeploymentException {

String sbbAbstractClassName = ((MobicentsSbbDescriptor) sbbDeploymentDescriptor)

.getSbbAbstractClassName();

sbbVerifier = new SbbVerifier(sbbDeploymentDescriptor);

//Verify abstract class

boolean classVerifiedSuccessfully = sbbVerifier

.verifySbbAbstractClass(sbbAbstractClassName,

serviceContainer);

MobicentsSbbDescriptor descriptorImpl = (MobicentsSbbDescriptor) sbbDeploymentDescriptor;

if (logger.isDebugEnabled()) {

logger.debug("usageParametersInterface = "

+ descriptorImpl.getUsageParametersInterface());

}

aqui ? false?

ou ? false num sitio qq do SbbDeployer

em qq sitio. na linha onde chama o ConcreteSbbGenerator ? false.

o objecto do SbbDeployer ? criado antes da mudan?a do class loader

n sei se ? disso

/ create deployer

SbbDeployer sbbDeployer = new SbbDeployer(getDeployPath());

// change classloader

ClassLoader oldClassLoader = Thread.currentThread()

.getContextClassLoader();

try {

Thread.currentThread().setContextClassLoader(

mobicentsSbbDescriptor.getClassLoader());

// Set up the comp/env naming context for the Sbb.

mobicentsSbbDescriptor.setupSbbEnvironment();

// deploy the sbb

sbbDeployer.deploySbb(mobicentsSbbDescriptor, this);

huum

doiss

experimenta a trocar a ordem

eh o q estou doing :)

as vezes das ares de quem percebe disto, p?.. ;-)

acredita q n fa?o ideia se ? essa a raz?o

pois

finally {

Thread.currentThread().setContextClassLoader(oldClassLoader);

}

volta ao velho ... :p

depois.. por isso trocar a ordem eh um bocado irrelevante, nao?

mas entretanto ja chamou o sbb deployer q por sua vez criou o objecto do generator usando o classloader do sbb

? a unica diferen?a q vejo

exacto, mas tas a dizer p trocar a ordem como, meter o SbbDeployer a ser carregado no novo?

s

e ver se o isDebugEnabled ja da true no deployer

ok. o melhor q devemos obter dai ? o SbbDeployer dar debug a true tb... :D mas ja eh qq coisa ;)

agora pra instalar o media servers usa-se o pom.xml em servers/media/release

da pra entender?

n. mas tenta convencer o indiano se fores capaz.

vejam la a janelinha privada lol

qd ha problemas num projecto grande, parte-se em pequenos e fica-se c um problema num projecto pequeno... parece-me bem :D

mas q problemas podem ter, s? se repetem os pacotes e as classes

n custa muito resolver

naquela banda a forma de resolver problemas ? assobiar e mudar tudo

ou entao dizer q n vale o esfor?o hehe

pois..

a troca d ordem das coisas n funcionou

continua a dar false no SbbDeployer

e true no Generator

:-\

vou testar outra coisa

btw, HANNOVER 96 X FC PORTO @ RTP1

tb n deu... sem fazer a mudan?a de classloader.

martins, barreiro: estao aqui? :P

não, saí :P

ainda bem

queria falar sem tu ouvires :D

a invocacao de um metodo estatico instancia uma classe ?

sim

n

coooool

era mm isso q precisava.. um sim e um nao. obrigado! :D

os metodos estaticos sao instanciados quando a classe ? usada a primeira vez

Drone: desempata :P

sim, mas a invocacao deles...

claro q isto se aplica a chamares metodos estaticos ou n

a invokacao deles carrega a class no classloader, e são executados lá ...

ta a ser invocado um metodo estatico do SbbDeployer num CL diferente de qd ele eh criado la no SleeContainer

a resposta ? um nim

:)

se primeiro chamares um metodo estatico a classe ? carregada, se primerio chamares um n estatico a classe ? carregada e os membros static e static{} s?o chamados

pois, eh o q tenho observado...

a resposta ao q realmente queres saber ? q o logger ? criado na primeira invoca??o da classe

seja estatica ou n

exacto

além disso, é criado um logger diferente por cada classloader.

deixa la invocar uma coisa estatica na mm altura q eh feito pro SbbDeployer

barreiro: como assim, mm se for estatico?

o logger.

o estatico é só válido dentro do classloader. A mesma classe carregada por dois classloaders gera duas instancias do objecto da classe, onde vivem as variáveis e os métodos estáticos.

ahaah

that did the trick .

false e false.

alexandre dances!

:P

mas no SbbObject, obviamente, continua a true

ok, confirma-se entao de q eh do classloader onde eh carregado

brb