April 2009 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: VFS thread safety issues

by alesj

"alesj" wrote : | If I'm able to do this before you start doing your updates, | I suggest you do them into 2.1 branch and I'll later port them to trunk. This is done, current branch 2.1 == trunk. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226231#4226231 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226231

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - MessagingServer deployment

by jmesnil

I'm looking at the deployment issues when starting MessagingServer. The root problem we have is that the queues created from the bindings loaded by the journal do not use the correct address settings because these settings are set later when the deploymentManager is started (and the address settings deployer is deployed). My first solution was to start the deployment manager *before* creating the queues from the bindings. Tim objected that it may have side-effects as "things" could be deployed before the server is still starting and not ready to use. After a closer look, I don't think it is currently the case. The queues are not deployed when the QueueDeployer is deployed (I really need to change the name). They are deployed afterwards at the proper place. Other resources deployed (address settings, security) are not a problem: they can be deployed while the server is starting. However, Tim's point is valid: we shouldn't deploy unilaterally while the server is starting. I'm drawing the dependencies order between the various component created/deployed by MessagingServer but it might take some time to have it right (we have some cycles betwen the components). Since we're short on time for beta, we can fix our current issue by starting the deployment manager sooner. But the correct fix is to untangle our dependencies and create/start/deploy things at the proper place in the proper order. This will take more time. wdyt? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226223#4226223 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226223

16 years, 11 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: ManagedConnectionFactory security-domain value recreatio

by emuckenhuber

"ips" wrote : +1 on changing security-domain to a CompositeValue and +1 also on avoiding GenericValue/ManagedObject as property values in general. Besides making the value impossible for clients to set, it makes the value difficult to even read. We'll have no issues on the console side converting a CompositeValue to an RHQ property. | Okay i'll change the security-domain to a CompositeValue then. It basically just has a SimpleValue domain and a EnumValue for the deploymentType. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226220#4226220 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226220

16 years, 11 months

1
0
0 / 0

[Design of Management Features on JBoss] - Issues with MapCompositeValue

by emuckenhuber

Recently i noticed that the behavior of MapCompositeValue is a bit weird. The main issue with this is that remove() does not update the MetaType. Looking into that - i don't think that the value-keys should be stored in the metaType anyway, as the metaType should be immutable. I think we should add a keySet() to the MapCompositeValue, otherwise you could get a value when a entry was removed before. In the meantime i worked around that and just ignore null values. Any concerns adding this? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226218#4226218 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226218

16 years, 11 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: ManagedConnectionFactory security-domain value recreatio

by ips

+1 on changing security-domain to a CompositeValue and +1 also on avoiding GenericValue/ManagedObject as property values in general. Besides making the value impossible for clients to set, it makes the value difficult to even read. We'll have no issues on the console side converting a CompositeValue to an RHQ property. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226215#4226215 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226215

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: StorageManager API

by jmesnil

It's when you have to draw a dependency graph than you really appreciate enforcing Demeter's law ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226213#4226213 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226213

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB4.x/AS 5 classloading

by beve

anonymous wrote : You can still use your mechanism, | but then the demand must have whenRequired before or equal PreInstall. I've modified the EsbDeployer and we now set the demands like this: | bmdBuilder.addDemand(objectName.toString(), ControllerState.PRE_INSTALL, ControllerState.INSTALLED, null); | What I think I'm saying here is that this deployment demands objectName.toString(), and it requires that when this deploment is at the PRE_INSTALL stage, that objectName().toString() is INSTALLED. Have I understood that correctly? I'm getting the same error with the above code but it might not be correct. If I look at the classloader used in ClassUtil.forName, the thread context classloader is first used to try to locate the resource: final ClassLoader threadClassLoader = Thread.currentThread().getContextClassLoader() ; | The classloader returned is : BaseClassLoader@215548{vfszip:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/transformation-pojo-quickstart.esb/} Since this is the deployment units classloader and the deployment has a demands on smooks.esb should it not be able to access and load the SmooksAction in smooks.esb/jbossesb-smooks.jar, which is in smook.esb. I'm not using any explicit classloading configuration here going with the "big ball of mud" option :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226212#4226212 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226212

16 years, 11 months

1
0
0 / 0

[Design of Management Features on JBoss] - ManagedConnectionFactory security-domain value recreation

by emuckenhuber

WRT https://jira.jboss.org/jira/browse/JBAS-6796 It seems that wrapping the security-domain in a ManagedObject does not seem to be the right way. At least from the console side the recreation of this value cannot be really done correctly, as there are not enough information available. Which means that the ManagedObject is not fully popluated. Using the ManagedObjectFactory on the console side also does not seem to make much sense, as they would depend on the SecurityMetaData class. A CompositeValue seems to make more sense here, as it's more robust and easier to handle than a ManagedObject. We can use a MetaMapper, which then can create the correct SecurityMetaData based on that. I think in general the use of a ManagedObject as a value should be avoided, as the recreation is quite complex without the ManagedObjectFactory and the real class. If this can also be done easily from the console side, then i would suggest that we change that. comments? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226209#4226209 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226209

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: StorageManager API

by timfox

Yes, please remove any unneeded dependencies :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226208#4226208 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226208

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: StorageManager API

by jmesnil

If I'm not mistaken there are other useless dependencies for this API (PostOffice, addressSettingsRepository) the simplest API that could possibly work is: public void loadMessageJournal(final PagingManager pagingManager, | final ResourceManager resourceManager, | final Map<Long, Queue> queues, | final Map<SimpleString, List<Pair<byte[], Long>>> duplicateIDMap) throws Exception | I'm looking at the dependencies between components when the server is started. Having the minimal dependencies which *really* count helps see how things should be properly created/started/deployed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226206#4226206 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226206

16 years, 11 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 April 2009