March 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Depends on microcontainer bean in -service.xml

by weston.price＠jboss.com

anonymous wrote : | We should probably change the JMX proxy MBean to go through the ServiceController | such that dependencies on the old JMX ObjectNames still work? | +1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031579#4031579 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031579

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: org.jboss.test.cts.test.MDBUnitTestCase

by clebert.suconic＠jboss.com

I changed the other on on SessionAsepct... i didn't find the dependency on ConsumerAspect.handleReceive though??? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031577#4031577 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031577

17 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - WS-Policy brainstorming

by palin

Hi all, working on test cases to extract requirements for ws-policy and ws-policy attachment implementations, we (Stefano and me) started thinking how the policy framework could be, thus we would like to do a little brainstorm here to share our thoughts on the issue. 1) First of all, we do need ws-po and ws-poa since we need ws-rm; for this reason the main goal would be to do the minimal work to get a working policy framework that can be used to test the future ws-rm implementation. Thus we will start supporting normal policy form (http://www.w3.org/Submission/WS-Policy/#Normal_Form_Policy_Expression) only as agreed with Thomas; compact form (http://www.w3.org/Submission/WS-Policy/#Compact_Policy_Expression) will be added later. For the same reason we think all UDDI related stuff (http://www.w3.org/Submission/WS-PolicyAttachment/#AttachingPoliciesUsingUDDI) could also be added in the future. 2) We nevertheless think that in order to be able to obtain future good interoperability, even now we should at least think about how this upcoming ws-po/ws-poa implementation will interact with ws-rm policy and other implementations of specs depending on policy. 3) We immagine that all the spec implementations based on ws-policy would be only required to provide mechanisms for their own assertions, ws-po/ws-poa implementation instead would provide all we need for alternatives, scope and effective policy selection, policy intersection and so on. This is what is defined in Policy Model and Policy Expression chapters of ws-policy spec: http://www.w3.org/Submission/WS-Policy/#Policy_Model http://www.w3.org/Submission/WS-Policy/#Policy_Expression and in chapter 3 and 4 of ws-policy attachment: http://www.w3.org/Submission/WS-PolicyAttachment/#PolicyAttachment http://www.w3.org/Submission/WS-PolicyAttachment/#AttachingPolicyUsingWSD... 4) We would ofcourse need metadata for ws-policy and these will contain specific metadata of eventual assertions belonging to ws-rm, etc. We think we should be able to go to and from metadata parsing/writing wsdl, with the wstool or may be via annotations that could be defined for assertions. 5) Thomas wrote an initial policy implementation some times ago: this is to be used as a starting point for core ws-policy metadata, since it already contains a policy model implementation. This should be further developed to add scope/effective policy mechanisms. 6) Speaking about how these metadata creation could be plugged into the existing source, we think that we could evaluate something similar to what has been done for other extension implementations like eventing and addressing (MetaDataBuilder creating ExtensibleMetaData objects and so on). Any comments and/or ideas? Thanks Alessio Soldano http://www.javalinux.it http://www.javalinuxlabs.org View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031571#4031571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031571

17 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: MethodInvocation.getArguments return value for 0 argumen

by kabir.khan＠jboss.com

I think in the case of no arguments null should be fine for around as well as before/after/throwing/finally? I don't see how interaction between b/a/t/f and around makes any difference when there are no arguments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031564#4031564 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031564

17 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Advanced MessageStore implementation

by bill.burke＠jboss.com

Maybe looking at some ESP project might be good to flush out further requirements? http://www.streamcruncher.com/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031548#4031548 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031548

17 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: MethodInvocation.getArguments return value for 0 argumen

by flavia.rainone＠jboss.com

It is relatively easy. We just need to be careful because @Args array used on before advices are currently the same as the one inside the invocation. And, the arguments array contained in the invocation is also used on after advices. So, either we add a special case, by not doing that before/around/after interaction when there are zero arguments, or we turn the empty arguments array into null for before and after advices. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031544#4031544 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031544

17 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Advanced MessageStore implementation

by mark.little＠jboss.com

"tpeuss" wrote : Sorry guys! I was not precise enough for you to understand what the goal of such an implementation would be: | It should be a base for transaction analysis tool where you can look at all the messages (or parts of it) that have flown through your system. | Yes, that's the original intention of the MessageStore. We want to provide something that can be used for audit trail purposes, distributed debugging etc. We also want to link it in with CBR, so messages can flow to their destinations and also a copy can be routed to the store. anonymous wrote : I am pretty sure that you agree that this is not possible with a MessageStore implementation that is in place in ESB nor with the one from the Messaging code (I had a look at this, too). | The current store is a black box I believe. Hence my comments about needing to extend the API. As for the JBM implementation, I will have to check with the team to see about its applicability. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031533#4031533 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031533

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Depends on microcontainer bean in -service.xml

by adrian＠jboss.org

We should probably change the JMX proxy MBean to go through the ServiceController such that dependencies on the old JMX ObjectNames still work? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031514#4031514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031514

17 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: jboss portal core in maven2 repository?

by FredF

"thomas.heute(a)jboss.com" wrote : We don't maintain a maven repository, sorry. ok. *starting to create ant build files* View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031504#4031504 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031504

17 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: jboss portal core in maven2 repository?

by thomas.heute＠jboss.com

We don't maintain a maven repository, sorry. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031496#4031496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031496

17 years, 6 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 March 2007