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

[Design of Security on JBoss] - Re: JBossSX trunk to be v2.1.x

by sguilhen＠redhat.com

I agree with branching our current projects and leading trunk towards a JAXB based model. We currently have 2 different parsers and an object model that needs to be manually updated every time we add something to the configuration. With JAXB the relationship between configuration schema and object model is a lot easier to manage, not to mention that JAXB is available by default in JDK 6 - and this means less dependencies for standalone projects. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210849#4210849 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210849

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: DeliveryCount & ACKs

by timfox

Also see https://jira.jboss.org/jira/browse/JBMESSAGING-1339. We should come up with a consistent solution View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210844#4210844 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210844

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: DeliveryCount & ACKs

by timfox

I think the real problem is, we should be incrementing the delivery count *before* we send the message to the client. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210843#4210843 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210843

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: oryx and jbpm

by tom.baeyens＠jboss.com

"eikish" wrote : Hi, I'm that "Eiki" :) | Hi Eirikur, nice to meet you with your real name :-) "eikish" wrote : It seems that developers are mostly creating visual XForms syntax editors but not form editors that use XForms underneath if you know what I mean.... | i don't and i would like to know. can you explain that a bit more ? "eikish" wrote : I think with Oryx this strategy would be best as well but I'm worried about backward compatability. We are using jBPM 3.3 and don't see that v.4 will be out any time soon so I need to make sure we build (or you as well?) a jpdl extension to oryx that will work on jBPM 3.3 as well... | | Will JPDL4 work on 3.3? | we aim to supply migration support including a tool for translating jbpm 3 processes to jpdl 4. jbpm 4 will not be backwards compatible with jbpm 3. though the basic structure would be the same. if you have the jpdl 3 plugin, it should not take a big effort to port it to 4. if you're willing to lead it, we'ld like to host and maintain the oryx extension to import/export oryx to jpdl 4. we can help with setting up the module in our codebase. what kind of dependencies are involved in creating an oryx extension ? is that development maven based ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210841#4210841 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210841

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: DeliveryCount & ACKs

by clebert.suconic＠jboss.com

With this change: catch (RuntimeException e) | { | if (!transactedOrClientAck) | { | try | { | | consumer.acknowledge(jbm.getCoreMessage(), false); | | session.getCoreSession().rollback(); | | session.setRecoverCalled(true); | } | catch (Exception e2) | { | log.error("Failed to recover session", e2); | } | } | } | the message would be sent to the ACK list on the transaction before the rollback, so the counter would be incremented. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210838#4210838 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210838

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - DeliveryCount & ACKs (Repost)

by clebert.suconic＠jboss.com

I have been working with https://jira.jboss.org/jira/browse/JBMESSAGING-1294, and this is the current scenario: - The MessageReference.deliveryCount is only updated after ACKs. Say, if you: - received a message - called message.acknowledge - called rollback When you receive that same message again, the deliveryCounter will be incremented, as the ACK will have it incremented: | Class: ServerConsumerImpl | { | ... | Method acknowledge(final boolean autoCommitAcks, final Transaction tx, final long messageID) | { | ... | if (autoCommitAcks) | { | ref.getQueue().acknowledge(ref); | } | else | { | ref.getQueue().acknowledge(tx, ref); | | // Del count is not actually updated in storage unless it's | // cancelled | ref.incrementDeliveryCount(); | } | } | If you are using AUTO_ACK (In JMS Terms that means non-transacted), that means you won't ever need to increment the DeliveryCount, as the message will be committed as soon as you called ack. However if you are using MessageListener, that's not true. If you receive a message and an exception was thrown, the counter should be incremented also. But the ClientConsumer can't call ACK, as that would remove it from the Queue. So, that means that Acknowledge requires a different semantic when an exception is caught on JMSMessageListenerWrapper. One way to fix this, would be to change the ACK call signature on ClientSessionInternal: | void acknowledge(long consumerID, long messageID) throws MessagingException; // Maybe I would leave this | | void acknowledge(long consumerID, long messageID, boolean autoACK) throws MessagingException; | And have the JMSMessageListenerWrapper doing: | catch (RuntimeException e) | { | if (!transactedOrClientAck) | { | try | { | | consumer.acknowledge(jbm.getCoreMessage(), false); | | session.getCoreSession().rollback(); | | session.setRecoverCalled(true); | } | catch (Exception e2) | { | log.error("Failed to recover session", e2); | } | } | } | With that, the AutoACK property would aways be sent on SessionAcknowledgeMessage, leaving the AutoACK to be controlled from the client. (I could extend the packet if the boolean is considered a problem, & if this solution is acceptable). The only problem I found on this solution, is requiring a type-cast to ClientConsumerInternal on JBossMessageConsumer. Any thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210836#4210836 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210836

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - DeliveryCount & ACKs

by clebert.suconic＠jboss.com

I have been working with https://jira.jboss.org/jira/browse/JBMESSAGING-1294, and this is the current scenario: - The MessageReference.deliveryCount is only updated after ACKs. Say, if you: - received a message - called message.acknowledge - called rollback When you receive that same message again, the deliveryCounter will be incremented, as the ACK will have it incremented: | Class: ServerConsumerImpl | { | ... | Method acknowledge(final boolean autoCommitAcks, final Transaction tx, final long messageID) | { | ... | if (autoCommitAcks) | { | ref.getQueue().acknowledge(ref); | } | else | { | ref.getQueue().acknowledge(tx, ref); | | // Del count is not actually updated in storage unless it's | // cancelled | ref.incrementDeliveryCount(); | } | } | If you are using AUTO_ACK (In JMS Terms that means non-transacted), that means you won't ever need to increment the DeliveryCount, as you will receive as soon as the message hit the client. However if you are using MessageListener, that shouldn't be true. If you receive a message and an exception was thrown, the counter should be incremented also. But the ClientConsumer can't call ACK, as that would remove it from the Queue. So, that means that Acknowledge requires a different semantic when an exception is caught on JMSMessageListenerWrapper. One way to fix this, would be to change the ACK call signature on ClientSessionInternal: | void acknowledge(long consumerID, long messageID) throws MessagingException; // Maybe I would leave this | | void acknowledge(long consumerID, long messageID, boolean autoACK) throws MessagingException; | And have the JMSMessageListenerWrapper doing: | catch (RuntimeException e) | { | if (!transactedOrClientAck) | { | try | { | | consumer.acknowledge(jbm.getCoreMessage(), false); | | session.getCoreSession().rollback(); | | session.setRecoverCalled(true); | } | catch (Exception e2) | { | log.error("Failed to recover session", e2); | } | } | } | With that, the AutoACK property would aways be sent on SessionAcknowledgeMessage, leaving the AutoACK to be controlled from the client. (I could extend the packet if the boolean is considered a problem, & if this solution is acceptable). The only problem I found on this solution, is requiring a type-cast to ClientConsumerInternal on JBossMessageConsumer. Any thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210836#4210836 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210836

17 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - JBossSX trunk to be v2.1.x

by anil.saldhana＠jboss.com

I am thinking that we need to work on the configuration aspects. We currently have JBossXB based configuration and the mc configuration. I am thinking that we need to branch out security projects into Branch_2_0 and make the trunk to lead to 2.1.x versions. We can refactor the configuration aspects from trunk towards a JAXB based model. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210833#4210833 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210833

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: [JBMESSAGING-1367] Create JCA resource adapter for JBM 2

by ataylor

I'm also getting the following error: javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction! | at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:80) | at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:65) | at org.jboss.messaging.ra.inflow.JBMMessageHandler$XATransactionDemarcationStrategy.<init>(JBMMessageHandler.java:397) | this becuase every session is trying to associate the same thread with the same tx. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210829#4210829 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210829

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: [JBMESSAGING-1367] Create JCA resource adapter for JBM 2

by timfox

We don't always use the local server. The ra should support all the params of the client session factory. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210819#4210819 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210819

17 years, 1 month

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 February 2009