September 2008 - jboss-dev-forums

[Other JBoss Development Design] - Re: JBoss slf4j location information is wrongly logged

by wolfc

I think LoggerPlugin should be trimmed of it's 'log' methods to a single log method: void log(String fqcn, Priority prio, String message, Throwable cause); Then Logger can enter it's own fqcn for the convenience methods and expose the log method for usage in (slf4j) logging adapters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175477#4175477 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175477

17 years, 7 months

1
0
0 / 0

[Other JBoss Development Design] - JBoss slf4j location information is wrongly logged

by wolfc

For example the following line is outputed when scanning for entities: 14:43:38,623 DEBUG [org.hibernate.ejb.packaging.AbstractJarVisitor:112] Searching mapped entities in jar/par: vfszip:/home/carlo/work/jboss-head/build/output/jboss-5.0.0.CR2/server/cts/tmp/jsr88/web_pkg_scope.ear/web_pkg_scope_web.war/WEB-INF/classes/ It says line 112, while it should have been line 116. Line 112 is where org.jboss.slf4j.JBossLoggerAdapter uses Logger to log the message. And since Log4jLoggerPlugin makes the assumption that Logger is the caller class name, you end up with that line number. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175476#4175476 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175476

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - EJB3 Classloader Leak (EJBTHREE-1442)

by ALRubinger

I've moved this topic away from http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175163 as the culprit is no longer the proxy factories. I've found that the remaining transient failures may be linked to Ejb3JBoss5Deployment instances that are not cleaned up. Profiler image tracking these instances is attached to https://jira.jboss.org/jira/browse/EJBTHREE-1442 So the fun part will be to find out why. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175474#4175474 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175474

17 years, 7 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: reflect and mdr CR releases

by kabir.khan＠jboss.com

That's weird. Must be a time-lag in the replication of the repository. If I look in subversion or in the repo, it's all there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175441#4175441 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175441

17 years, 7 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Handling soft versus hard pooledInvoker exceptions in JR

by bstansberry＠jboss.com

Agreed about safety in the 4.x releases. These are client-side classes and 4.x is in micro-release mode with possibly older releases trying to communicate with any 4.2.4 this would go into. Adding new classes would break such clients. It's probably about too late to add new classes to 5.x as well, as the CR2 is about to go out. I think what you propose looks OK; it basically mimics the behavior of the finally "catch (Exception e)" block in JRMPInvokerProxyHA.invoke(). AFAICT, only side effect it would have would be to prevent failover if java.rmi.ConnectException(cause EOFException) were returned from the server side. And if that happened, preventing failover is probably the right thing to do anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175440#4175440 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175440

17 years, 7 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Handling soft versus hard pooledInvoker exceptions in JR

by ScottMarlowNovell

anonymous wrote : On the other hand, a hack fix might be safer for fixing earlier releases (creating a proper full set of classes for the Pooled invokers.) I meant to say that a hack fix might be safer for fixing earlier releases (than creating a proper full set of classes for the Pooled invokers.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175419#4175419 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175419

17 years, 7 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Handling soft versus hard pooledInvoker exceptions in JR

by ScottMarlowNovell

I agree that the pooled code looks hacky in the exception handling. I would like to explore what the better fix might be and then we can consider if that is safe enough (I don't want to break fail-over for anyone :-). On the other hand, a hack fix might be safer for fixing earlier releases (creating a proper full set of classes for the Pooled invokers.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175417#4175417 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175417

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBVFS-60, hasBeenModified implementation resolution problem

by scott.stark＠jboss.org

The problem with the current JBVFS-59 FileVFSUnitTestCase.testWarLinkUpdate failures is that the test is rapidly modifying the underlying test-link.war.vfslink.properties file, but the resolution of the URLConnection.getLastModified() is >1000 microseconds on some systems. We need a better implementation of the VirtualFileHandler.hasBeenModified for each URL type. We had dropped our override of the file: URL handler because what we were overriding had been implemented in later jdk versions. I assume this resolution limitation is coming from the java.io.File implementation, so I don't know what we can do about it at this point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175388#4175388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175388

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Replay transaction on XA

by clebert.suconic＠jboss.com

As I was talking to Andy today, when we replay the Transaction we need to find MessageReferences for deletedMessages, and we only store the ID of the message (never the queueID what is required to find the MessageReference). There are 4 possible solutions for this: I - Change delete method to also store a queueID, supporting the replay operation. (Performant, but I'm not sure if we should do it) II - Scan for the Message on the Queues associated with the address. (But that's a problem if you had 1000 queues). But reload with PreparedTransaction shouldn't happen too oftenly.. so I'm not sure if that would be a problem. (This is the option I would choose. We can do it with minimal changes) III - Aways record an update with the ID. But that would have other implications on the journal. (Performance and logical) (I'm aways against adding new records just, so I don't like this option) IV - Use the TransactionData associated with the prepareTransaction, to store extra information about ACKs (besides just the XID). (This is also performant... that should be one of the options evaluated). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175386#4175386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175386

17 years, 7 months

1
0
0 / 0

[Design of JBoss Labs] - Link to jPDL javadoc broken

by apestel

>From http://www.jboss.org/jbossjbpm/jbpm_documentation/ Click the "View Online" link next to "jPDL Javadoc" and the link is broken. Hope this is the right forum, it was linked to under "Problems" at the above link. Thanks, Aaron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175385#4175385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175385

17 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2008