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

[Design of JBoss Web Services] - Re: WS-RM Prototype Ready for Preview

by alessio.soldano＠jboss.com

Hi Richard, finally found some time to take a look at your RM code. Well done, for sure. Soon I'll comment about what you and Thomas are discussing now (the HA etc.), I need to investigate a bit more before. Speaking of the efforts aimed at simplifying the RM use, I think you might evaluate (if you have not done this yet ;-) ) whether it is possible to install the RM handler through the RMPolicyAssertionDeployer. This would eventually remove the requirement for a custom endpoint configuration (of course eventual security still requires configuration) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117168#4117168 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117168

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by jason.greene＠jboss.com

"manik.surtani(a)jboss.com" wrote : "manik.surtani(a)jboss.com" wrote : | | I'd like to make this a priority for 3.x, to restrict Fqn elements to {String, byte, short, int, long, float, double, char, boolean}. Thoughts? | | | | It should be anything that has can be mapped to AND from a string. So that would be all primitives and wrapper types, and enums. We could support lazily loading an enum (its just a string), or we could just tell people they have to convert them to and from strings themselves. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117158#4117158 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117158

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by jason.greene＠jboss.com

"manik.surtani(a)jboss.com" wrote : | +100. Hugely limiting in the way we have to support custom objects in Fqns right now. I understand why people don't want just Strings as Fqn elements, but we should restrict this to Strings + boxed primitives or something like that. | | Again, though, not something we can do now (2.1.0). Perhaps 3.0.0? | We should deprecate it in 2.1.0, but still allow it to work. It never worked like people expected anyway. Most importantly, we should change all of our code that does this sooner than later. This is an example of how it could possibly work with entity caching: | /entities/[TYPE]/[HASHCODE] | KEY1 -> UUID1 | KEY2 -> UUID2 | KEY3 -> UUID3 | /entities/[TYPE]/[HASHCODE]/[UUID1] | [FIELD_NAME] -> [FIELD_VALUE] | ... | /entities/[TYPE]/[HASHCODE]/[UUID2] | [FIELD_NAME] -> [FIELD_VALUE] | ... | /entities/[TYPE]/[HASHCODE]/[UUID3] | [FIELD_NAME] -> [FIELD_VALUE] | ... | So a given entity requires 2 node lookups, no matter the number of collisions. There will, of course, be contention on the hashcode, but this is expected. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117157#4117157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117157

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: NPE booting Embedded JBoss from trunk

by scott.stark＠jboss.org

I'll take a look at it and try to get it resolved by monday as I need to do a release of jbm for other jbossas issues. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117148#4117148 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117148

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-1251

by manik.surtani＠jboss.com

"bstansberry(a)jboss.com" wrote : | This is what is happening. Question is why a new "valid" node isn't created in the lock() call. | Yes, this is the root of the bug. Where we add nodes if the node does not exist and createIfNotExists == true, we should also set the node to valid if createIfNotExists == true and the node exists but is not valid. "bstansberry(a)jboss.com" wrote : | Hmm, maybe not, I think I see the idea. You're *only* checking for nodes that are "floating in space". Nodes that are still part of the main cache structure, no matter what their status, are OK. | Yes, this is needed to prevent problems with concurrent deletes and puts. "bstansberry(a)jboss.com" wrote : | OT: on the repeek thing -- that seems like quite a bit of overhead since it's repeated on every node from the root down -- for every call. Could that check be limited to the last node in the hierarchy? | Not really - a delete could happen on a parent with a concurrent add on a child with READ_COMMITTED. That said, this could be optimised for R_R and then a separate check on every level for R_C. In the end the ugliness of all this is because locks are a part of a node and if a node does not exist attempting to create one (or concurrently delete one) means that 2 txs may acquire locks on different lock objects, on different nodes, sharing the same Fqn. Stuff that will go away with 3.x as I hope to use a single LockManager that maps locks to Fqn objects. This will still be accessible from the Node - to be compatible with current code - but Node.getLock() will ask the NodeManager for the lock by passing in the Node's Fqn. "bstansberry(a)jboss.com" wrote : | Alternative (which requires SPI change) is to add a boolean "orphan" flag to a node, or to make AbstractNode.deleted an enum with "FALSE, DELETING, DELETED" or something. Some way to change the state of the node itself when it's been cut loose from the tree. Invalid nodes may live longer than just the course of an invocation, and represents more than the partial state of deletion - JBCACHE-1155 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117142#4117142 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117142

18 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Maven ESB plugin

by Kevin.Conner＠jboss.com

Hiya Toby. That is where I would expect it to be located but I am getting a '301 Moved Permanently' response from the subversion repository. I'll check up on this and get back to you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117137#4117137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117137

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Refactoring on delegates

by clebert.suconic＠jboss.com

Anyone: Please avoid any big refactoring on delegates and aspects until I have merged my code into trunk. All the aspects have disappeared on my branch, so if you make big changes on any of those places will make me do manual merges. The bigger the change you make on those places, bigger the work I will have to solve those changes. And talking about my branch... I believe I am on a good shape to merge it now. This is an intermediate state where I still have States, and am using Proxies in replacement of the interceptors we were using before. As part of the API is not on interfaces, I had few issues on places we had to convert the Proxy into Delegate again (like, accessing the State object and other things that were not exposed on the interface). But this conversion won't be necessary after the next step on the refactoring, where States are going to disappear. After I have deleted all the Aspects on trunk, I'm going to remove the State Objects. And I will also verify the possibility of not using Proxies for ClosingInterceptor at all. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117105#4117105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117105

18 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Sending an Oracle JMS message to the ESB

by tschungelbuch

"Sorry for being a little slow here, but can't you write a trigger on a table to drop a message on the Oracle/AQ queue? Which will then be picked up by the ESB?" This is actually exactly what I would like to do, but as I wrote, I am new to AQ, therefore I thought that you may have a sample of AQ and ESB. Kind regards RH View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117102#4117102 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117102

18 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Sending an Oracle JMS message to the ESB

by kurt.stam＠jboss.com

Sorry for being a little slow here, but can't you write a trigger on a table to drop a message on the Oracle/AQ queue? Which will then be picked up by the ESB? Or do you not like the polling of the jms-listener? I doubt AQ support JCA inflow, but you could try to set that up using the JCA gateway. Sorry if I'm way off, I'm still trying to understand what it is you're actually asking. --K View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117096#4117096 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117096

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by manik.surtani＠jboss.com

Regarding the marshalling of custom Fqn elements (for now/2.x), how about we apply the same MarshalledValue approach for Fqn elements that aren't in a set of JDK classes? I propose that for the purpose of the MarshalledValue, we *just* use primitives as the set of elements/values that are not wrapped in a MarshalldValue. The argument is that even though things like Strings and Dates don't need specific class loaders, should we bother with the cost of deserialization when, after replication, the objects may never be used and just get evicted after some time? After all, MarshalledValues provide a mechanism of lazy serialization/deserialization as well as the use of specific class loaders. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117091#4117091 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117091

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