June 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: MainDeployer MBean methods in JBoss 5

by Wolfgang Knauf

Thanks for the reply. I will take a look at JSR88, maybe I find an easy way to add it to the eclipse deployer. Some time ago I did some testing with undeploy/deploy on linux, and as I remember there worked more than on windows. Maybe there is a windows problem? Best regards Wolfgang View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160049#4160049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160049

16 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Support for @JMX on attributes

by alesj

Yup, Brian is right. and that's what I also meant. Just using factory differenty in MC as what people are used to. I'll finish this tomorrow, posting here when done with tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160046#4160046 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160046

16 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Support for @JMX on attributes

by bstansberry＠jboss.com

Excuse me for jumping in (testsuite is running so I've got a minute). Since I'm uninvolved I'm sure to be wrong. ;) I think Adrian's proposed syntax does what you are looking for; it doesn't say the MC creates the object, it tells the MC to get a ref to the object by invoking a getter. You create the object yourself internally however you wish. Exposing it as via a bean element just allows you to add the @JMX annotation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160043#4160043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160043

16 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Support for @JMX on attributes

by timfox

To put it another way, as you know, the classic factory pattern allows you to keep the creation of the object as an implementation detail of the creator task. If the factory wants to encapsulate creation that way it should be allowed to and not forced to make those details public. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160039#4160039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160039

16 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Support for @JMX on attributes

by timfox

Only the MessagingServer knows how to create a MessagingServerManagement instance. Passing a MessagingServer instance into the MessagingServerManagement constructor is not desirable since it would require us to expose publicly a load of internal details of the MessagingServer. Here is how we create a MessagingServerManagement instance, internal to the MessagingServer | serverManagement = new MessagingServerManagementImpl(postOffice, storageManager, configuration, connectionManager, securityRepository, queueSettingsRepository, this); | Most of these params are internal to the MessagingServer and I don't want to have to expose them publicly just so MC can expose the MessagingServerManagement class as JMX. I believe MC should be flexible enough to support this factory style approach of creating manageable objects. Allowing to specify @JMX on an attribute level would certainly work for us. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160034#4160034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160034

16 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Support for @JMX on attributes

by alesj

OK, I'll drop the proxy, creating bean out of factory+method, then leaving it to JMX handling. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160031#4160031 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160031

16 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references

by alessio.soldano＠jboss.com

"wolfc" wrote : It didn't make ejb3-core 0.1.5, so it's coming in 0.1.6. Yes, I know, I tested it doing a local 0.1.6-SNAPSHOT. Thank you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160026#4160026 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160026

16 years

1
0
0 / 0

[Design of JBoss Web Services] - @WebServiceRef default name

by alessio.soldano＠jboss.com

This is related to http://jira.jboss.com/jira/browse/JBMETA-64. Well, considering the api doc says the default name should be as is now in trunk, I was thinking it's probably better to close the issue as "won't fix" (thus changing the behavior we had in Beta4). On my side I would have changed the tests, in order not to use the default name (i.e. I'll always use the name attribute) to pass on both containers. My only concern now is that the old naming default was probably used to cope with cases of multiple class having different attribute annotated with @WebServiceRef with the same name: ... public class A { @WebServiceRef private ServiceOne prettyService; ... } ... public class B { @WebServiceRef private ServiceTwo prettyService; ... } What do you think about this Emanuel? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160024#4160024 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160024

16 years

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by prabhat.jha＠jboss.com

I will have Julien/Thomas comment on amount of read/write. What I saw during many iterations of my tests that OL performed and scaled much better {1,2,3} nodes cluster but scalability went down when nodes in cluster went to {4,5}. I have not tried tests with PL with a {4,5} node cluster. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159998#4159998 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159998

16 years

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

ASYNC generally isn't valid for an entity, since you can't guarantee cache consistency. It might be OK if all your entities are really "owned" by one node; i.e. it's not expected that another node will access that entity except in case of failover. I'm somewhat surprised you are seeing a big perf improvement with OL. That would generally imply lots of cache writes, since the benefit of OL is it allows reads to proceed concurrently with writes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159990#4159990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159990

16 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008