November 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: @JMX aspect and aop/mc integration

by kabir.khan＠jboss.com

"bstansberry(a)jboss.com" wrote : For any bean that calls any method in its constructor, if I add the @JMX annotation I'm getting an NPE during deployment. This should be fixed now, update jboss-aop-jdk50.jar View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985428#3985428 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985428

19 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Problems displaying results

by ivanneto

Hi Clebert. Sorry for the delayed answer. I've done some more tests and I think that JBoss Profiler has some problems with Linux/AMD64 environments. I tried the same steps I described in my previous post, but this time I ran JBoss using a 32-bit Sun JVM. Everything went OK. The config I used before (no success): Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_08-b03, mixed mode) Linux 2.6.17-2-amd64 JBoss (MX MicroKernel) [5.0.0.Beta (build: CVSTag=HEAD date=200609140344)] The config I used in a successful test: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode) Same kernel, same JBoss version I just changed the VM from a 64-bit to a 32-bit version and everything went just fine. Best regards, Ivan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985415#3985415 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985415

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Document where non-String FQN do not work, JBCACHE-838

by bela＠jboss.com

There's no point in supporting a non-string ID in JGroups for partial state transfer if we cannot support the same in the cache loaders (JDBC, File etc). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985414#3985414 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985414

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Current behavior of DeploymentUnit.getAttachment

by adrian＠jboss.org

The problem is one of leakage when the order of processing attachments is not defined. e.g. More explicitly, imagine an ear that contains an ear where the inner ear doesn't have an application.xml it would see the application.xml of the containing ear. This is why I described the current behaviour as a hack. It only works because the component deployers are at the end and they only process the specific component attachments/metadata So there is no deployer that will look at a component and reprocess the parent's metadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985411#3985411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985411

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Document where non-String FQN do not work, JBCACHE-838

by manik.surtani＠jboss.com

I agree. That should be the starting point here, and from there on, decide on whether we need a temporary layer between JG and JBC to force String conversion until JG can handle non-Strings. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985397#3985397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985397

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: JBC and RPC

by manik.surtani＠jboss.com

"bstansberry(a)jboss.com" wrote : | Segregating these kinds of things into a separate transient Runtime subobject sounds fine. Without objection I'm going to proceed down that line now, as it solves some issues with wiring things together in the AS. | Ok. "bstansberry(a)jboss.com" wrote : | I'd like to explore more what you're thinking about here though in terms of reuse. | I haven't thought too far down this line yet, I just think it may be useful in future, like some of what you mentioned above. I wouldn't attempt to do this for 2.0.0 though; perhaps 2.1.0? I presume this would have quite an impact on your using such features in AS clustering though... ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985394#3985394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985394

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: @JMX aspect and aop/mc integration

by kabir.khan＠jboss.com

"bstansberry(a)jboss.com" wrote : For any bean that calls any method in its constructor, if I add the @JMX annotation I'm getting an NPE during deployment. I have reproduced the problem and am looking into it View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985392#3985392 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985392

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - who's using oscache

by tom.baeyens＠jboss.com

... and for what ? i see a dependency declared in the build.properties in HEAD. Just a FMI (For My Information) :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985383#3985383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985383

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - improving the build

by tom.baeyens＠jboss.com

I'm going to make some slight improvements to the build: 1) add build profiles 2) improve versioned dependencies 1) add build profiles I'm going to factor out all the library version properties to a separate properties file. Many of these files can go into the profile directory. E.g. for each version of jboss, we can create a set of properties that match these of jboss. Also jbpm internal dependencies will be included in the profile property files. 2) improve versioned dependencies For each top level subproject, you'll be able to specify wether the sources are used (using version 'snapshot'). Or wether a specific version from the repository is being used. For each of the third party libs, you'll be able to specify the filename and version in the profile properties files. Any early feedback comments on this are appreciated. Let me know asap when i should happen to break your build. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985368#3985368 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985368

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - versioning for subprojects (e.g. bpel)

by tom.baeyens＠jboss.com

I saw that bpel makes a distinction in versioning for the .jar and for the .war. This probably should be refactored as the idea was that only top level projects would be versioned separately. So this would imply that there is 1 version for the bpel sub project. I assume that Alex made a small mistake when trying to reverse engineer this strategy. Documentation from my part might have helped :-) sorry! I'm working on stabilizing the build process and then I will try to enhance the docs as well. Or were there specific reasons why you made a separation between the .war and .jar, Alex ? Don't worry for now. I'm going to leave the bpel properties as they are and refactor the other projects a bit. Then I can show you how update the bpel properties accordingly. We can have a call to go through it. And if you explain me the bpel build process a bit, i can do that rework of the build properties for bpel as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985361#3985361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985361

19 years, 5 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 November 2006