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

by weston.price＠jboss.com

The JDBC JSR http://jcp.org/en/jsr/detail?id=221 was finally approved. We need to start thinking about this. Postgres and a few other vendors have started their 4.0 driver work. I was planning on helping the PG/Hypersonic/JDTS guys on their stuff so we should at least have some drivers to test with. A mock driver in the testsuite is probably not a bad idea either. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990779#3990779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990779

17 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: AOP/JCA

by weston.price＠jboss.com

Next steps More design documents work Finish creating jca project structure (still need to resolve some Maven stuf) Check into SVN Start porting pieces of new JCA over to new project. This will be a combination (at least the spirit) of the JCA prototype in CVS as well as my current work. New links on the Wiki in the hopes of generating more contributor interest I haven't quite decided yet if the adapters should be a completely separate project, or should they be included as a sub-project of jca. Maven2 seems to support parent/child poms, so this should not be that big of a deal either way. Some tasks, programmtic deployment, RAR repository rely should be done against the new code base rather than having to shoehorn the existing JMX implementation to use this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990778#3990778 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990778

17 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Multithreaded services and their EPR(s)

by kurt.stam＠jboss.com

If a service is multithreaded, should each thread be registered as a separate EPR, or should there only be 1 EPR for the entire set of threads for this service? The current issue we have is the following: In the current implementation we only have one EPR for each service, which currently eventhough we only allow 1 thread, is sometimes causing us issues when the configuration is reloaded. It turns out that in this case the new thread B is created before thread A has ended, and the same EPR gets registered twice. Upon unregistering thread A both these EPRs are removed from the registry and upon unregistering thread B the registry throws an exception since no matching EPR exists any longer. The issue can be resolved by registering each thread as it's own EPR. This is easily done simply by adding a UID to the EPR, since upon unregistering we simply do a string comparison on the xml-serialized EPR. However personally I am worried that we will end up with a lot of 'dead' EPRs. If an unclean shutdown happens, the EPRs will never be removed from the registry. Therefore personally I think that the parent of all the threads should be responsible for registering the service with it's EPR and it should not get unregistered until the last thread ends. Can this be done in the current implentation? Any other ideas are welcome! Cheers, --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990768#3990768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990768

17 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Design of a Content Based Routing Service

by kurt.stam＠jboss.com

Thanks Dave, The patch made into RC1. Edson maybe you can take a look at new new codebase? I think that for GA I want to pull the destinations out of the rules and put them into the configuration, passing them into the rules when the rule base is constructed. Maybe an hashmap where the rules reference them by key. This so one can see the possible routing destinations by looking at the config, and you don't have to drop into the rules themselves. Note that the config gets reloaded periodically so we'd have to destroy the ruleBases at that point? Let me know what you think. thx, --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990767#3990767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990767

17 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Cleaned up security project

by anil.saldhana＠jboss.com

I think we can remove the dependence of MBean services on ServiceMBeanSupport. In fact most of the mbean services (JaasSecurityManagerService, AuthorizationManagerService) can be removed, as the security managers can be directly injected. One service that will be interesting will be the DynamicLoginConfig, which cannot be removed(because customers may have used it extensively in their sars and ears). Is it possible to inject jmx aspects to the tag for a pojo (DynamicLoginConfig) without using the JMX annotation (Kabir did)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990761#3990761 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990761

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - VirtualFile.finalize, JBMICROCONT-115

by scott.stark＠jboss.org

The current sporadic read errors in jboss5 are due to the VirtualFile.finalize closing any open streams associated with the VirtualFile. This is an invalid ownership notion with the current VirtualFile.openStream implementation as one can have access to streams without holding a reference to the VirtualFile. Since its such a tricky problem to debug, its not a good idea to require a usage policy of keeping a reference to the VirtualFile and using its close method to close all associated streams. The finalize method should be removed, and either one keeps a reference to the VirtualFile to use its close, or is responsible for closing any streams one opens. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990759#3990759 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990759

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Branch 1_0_XARecovery

by timfox

"juha(a)jboss.org" wrote : "timfox" wrote : | | 1) The call to persistenceManager.associateTxCallbackToPreparedTx() in TransactionRepository::loadPreparedTransactions() | | | | seems to be redundant since the callback will be automatically created when the refs / acks are replayed. | | | | However, removing it will cause the recovery to fail (messages are not delivered). | | Should definitely be redundant. If stuff fails when it's removed, then that points to another problem. "Juha" wrote : | Right. I was suspecting this based on the API but couldn't find any clear indication of this in the code. | What you want to do is basically this: for the acks: select message_id from jms_message_reference where transaction_id=? and state ="+" this gives you all the message ids you want to load then call persistenceManager.getMessages(List ids) to get the actual messages for those ids. Then call messageStore.reference(Message m) for each of those messages - this will give you a reference for each of the messages. Once you have your references you can call channel.handle(ref, tx) to replay them through the channel. (This will create any callbacks). A similar procedure applies for acks, except the query to get them is different: select message_id from jms_message_reference where transaction_id=? and state ="-" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990753#3990753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990753

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Branch 1_0_XARecovery

by juha＠jboss.org

"timfox" wrote : | 1) The call to persistenceManager.associateTxCallbackToPreparedTx() in TransactionRepository::loadPreparedTransactions() | | seems to be redundant since the callback will be automatically created when the refs / acks are replayed. | However, removing it will cause the recovery to fail (messages are not delivered). So if you think it is redundant then that failure to work correctly without the call needs to be investigated. That's why I've kept the related JIRA task on this still open. "timfox" wrote : | | 2) TransactionRepository::handleReferences(): | | call to persistenceManager.getMessageIdForRef(txId) | | you only seem to be returning the first message id, the transaction may contain many message adds - so | you need to retrieve them all. | Right. I was suspecting this based on the API but couldn't find any clear indication of this in the code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990752#3990752 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990752

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Hibernate as Messaging persistence layer

by timfox

Messaging's sql needs are very basic and "straight to the bone" so it's unlikely we would use Hibernate as an O/R mapper - it's not really needed for us. However, it is likely we could use Hibernate's dialects to avoid having to maintain different persistence configs for different databases - this would definitely have value. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990751#3990751 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990751

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Branch 1_0_XARecovery

by timfox

Juha- I have a few questions on the current implementation in svn: 1) The call to persistenceManager.associateTxCallbackToPreparedTx() in TransactionRepository::loadPreparedTransactions() seems to be redundant since the callback will be automatically created when the refs / acks are replayed. 2) TransactionRepository::handleReferences(): call to persistenceManager.getMessageIdForRef(txId) you only seem to be returning the first message id, the transaction may contain many message adds - so you need to retrieve them all. you need to do the following: 3) TransactionRepository::handleAcks(): same problem as for 2) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990750#3990750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990750

17 years, 5 months

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 December 2006