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

[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)

by alesj

"adrian(a)jboss.org" wrote : | Are these now broken? | Yes. I ran them from IDEA's JUnit integration. Some of them pass, but most of them fail due to collection's element interface usage (instead of using declared type="AbstractXYZMetaData") when binding. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117521#4117521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117521

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 destination config.

by timfox

Can't we just make them a standard MC POJO service and get hot deployability for free? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117520#4117520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117520

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)

by adrian＠jboss.org

"alesj" wrote : I ported the MC JAXB features from JBossXB builder project. | How much was this thing tested? | I ported the entire set of MC parsing tests into the JBossXB builder testsuite. Are these now broken? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117519#4117519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117519

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Changes to failover functionality

by timfox

The most complex part of JBM currently is the failover functionality - both client side and server side. Historically this has been the largest source of bugs and problems to us. I have thought about this extensively over XMas and would like to propose the following changes which should a) Simplify our code significantly - making it easier to maintain and reducing defect potential. b) Making it simpler to understand and configure for the user Going ahead I think this will add up to a better experience for both us and the customer. Some of this is already known, and is pretty much what we have alredy discussed, other parts diverge. As discussed, we will support two different types of deployment scenario for HA: 1) Failover via a shared filesystem: In this mode, the user configures a shared filesystem (e.g. SAN) that is accessible by each node in the cluster. Each node stores its persistent storage (e.g. BDB environment) there. When a server fails, it relinquishes an exclusive lock on the file, and another server can start up and load the file. On the client side connection failure is detected. Since we're not replicating session state any sessions need to be rolled back. But this shouldn't cause a problem to the user if they're using transactional sessions. This mode will provide the highest level of performance (since no replication required), but trades off against a somewhat slower failover since the new server needs to reload the queue state from the storage. 2) Live-backup replication. In this mode, a shared FS is not available so we replicate queue state to a backup node. Note the backup node does not become active until it's primary fails. This means failover is fully transparent, and very quick (should be subsecond) since we don't have to reload any state. We also replicate all consumer/session/connection creation to the backup. One of the best things about this approach is we can remove most client side failover functionality, since, for replicated backup, the connection-session-consumers will already exist on the server side so no need to wait. For shared filesystem failover, the connection-sesion-consumers on the client side need to be thrown away, and the new node won't be available until it loads its queue - the client can keep retrying (with timeout) until it connects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117517#4117517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117517

18 years, 3 months

1
0
0 / 0

[Design of JBoss Portal] - Repository snapshot update

by julien＠jboss.com

So we need to discuss how we are going to manage concurrent usage of the snapshot repository of the various modules. Probably the most common one will be the common module. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117516#4117516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117516

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 destination config.

by ataylor

anonymous wrote : The default security will probably be fine without changes for the majority of users, but if they want to change it from the default then they just do something like: Ok Will jms-jndi.xml be hot deployable as well? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117514#4117514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117514

18 years, 3 months

1
0
0 / 0

[Design of JBoss Portal] - LocalizedString equals implementation

by julien＠jboss.com

I don't understand the semantic of the equals method of the LocalizedString class. Can someone explain ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117513#4117513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117513

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 destination config.

by timfox

"ataylor" wrote : | but still have to configure the security elsewhere in the queues.xml file, or am i missing something. | The default security will probably be fine without changes for the majority of users, but if they want to change it from the default then they just do something like: | <security match = "queues.finance.stocks.*"> | <permission="read", roles="traders"> | <permission="write", roles="admin"> | </security> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117512#4117512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117512

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 destination config.

by ataylor

anonymous wrote : For a JMS user, they just need to add their connection factory and/or destinations in the jms-jndi.xml file (or whatever we want to call it). but still have to configure the security elsewhere in the queues.xml file, or am i missing something. Removing the JNDI stuff is down as a JIRA task for me to do, so this probably needs doing first. I'll add a comment to it that we need a seperate JBoss service to that takesd care of adding destinations and factories via the jms-jndi.xml file. Also, it might make sense to move some(or all then we'll have a clean seperation) of the exposed JMX methods, createqueue for instance would expect it to be added to JNDI. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117510#4117510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117510

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 destination config.

by timfox

For a JMS user, they just need to add their connection factory and/or destinations in the jms-jndi.xml file (or whatever we want to call it). This is the one that instantiates the jms objects and puts them in JNDI. This is not really any different to how it currently works. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117506#4117506 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117506

18 years, 3 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 January 2008