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

[Design the new POJO MicroContainer] - Re: VFS3 - missing features and other issues

by david.lloyd＠jboss.com

"alesj" wrote : "david.lloyd(a)jboss.com" wrote : I think the quick/easy fix would be a mistake here. | I'm not looking for a quick&easy&dirty fix here. | I'm simply looking for an old API mapping to the new functionality. | | How you glue those "assembled" or temp or what-ever-you-wanna-call-them resources, | I don't really care, all I need is the old API. | Which shouldn't be that difficult to support, or, | if it is difficult, then there is something wrong with the new API. | The equivalent you want is probably "VFS.mountTemp()". "alesj" wrote : | The issue is if I don't have this old API present in VFS or some other top level project/artifact, | it means I have to re-write a lot of MC's tests, which is definitely something I don't wanna do or have time for. Like Jason said - the first thing we're doing is porting over the VFS tests. Once that's done we'll be looking at the greater integration question. As we discussed in the meeting, if you don't want to do this work, you don't have to (Jason and I are the ones to whom the work was assigned) - but if you do, that's great as well. In terms of the tests, if that's the only reason for the API, then just duplicate the API in the tests. Tests are not a sufficient reason to keep an API around, no matter how inconvenient it is. That said, if you want to use the mountTemp() API instead, that's even better. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246736#4246736 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246736

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS3 - missing features and other issues

by david.lloyd＠jboss.com

"alesj" wrote : "david.lloyd(a)jboss.com" wrote : They should not be limited to a single global static list. | | | Hmmm, here practice proves you wrong. ;-) | We already went by this approach and it didn't work out - see below. | | "david.lloyd(a)jboss.com" wrote : | | And it's not appropriate for an archive deployer to explicitly manage nested archives of a type with which it is not familiar or authoritative over. | | | They can do the reverse, simply state the ones they are not able to support from the global ones. | Which is usually a small set, whereas you can easily miss some that you do. The issue probably stemmed from the fact that archives were always auto mounted. With the new system, archives that are not recognized/supported by any deployers or classloaders or whatever are simply ignored and treated as regular files. We should never need to worry about a global list because the various deployers will always pick up what's theirs. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246734#4246734 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246734

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS3 - missing features and other issues

by alesj

"david.lloyd(a)jboss.com" wrote : I think the quick/easy fix would be a mistake here. I'm not looking for a quick&easy&dirty fix here. I'm simply looking for an old API mapping to the new functionality. How you glue those "assembled" or temp or what-ever-you-wanna-call-them resources, I don't really care, all I need is the old API. Which shouldn't be that difficult to support, or, if it is difficult, then there is something wrong with the new API. The issue is if I don't have this old API present in VFS or some other top level project/artifact, it means I have to re-write a lot of MC's tests, which is definitely something I don't wanna do or have time for. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246728#4246728 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246728

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS3 - missing features and other issues

by alesj

"david.lloyd(a)jboss.com" wrote : They should not be limited to a single global static list. | Hmmm, here practice proves you wrong. ;-) We already went by this approach and it didn't work out - see below. "david.lloyd(a)jboss.com" wrote : | And it's not appropriate for an archive deployer to explicitly manage nested archives of a type with which it is not familiar or authoritative over. | They can do the reverse, simply state the ones they are not able to support from the global ones. Which is usually a small set, whereas you can easily miss some that you do. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246727#4246727 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246727

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS3 - missing features and other issues

by alesj

"david.lloyd(a)jboss.com" wrote : Though honestly, keeping track of your resources and explicitly unmounting is not that hard - I don't see why it is such a burden. This is actually what we're doing currently. And so far the latest VFS version doesn't seem to be bad in cleaning up after itself. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246726#4246726 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246726

17 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by tfennelly

So just to let people comment on how some of the security aspects might look.... Specifying the http authentication method for the deployment could look like this: | <http-provider name="http"> | <http-bus busid="ordermgt" /> | | <auth method="BASIC" /> | </http-provider> | Where the auth method can be an enum of "BASIC", "CLIENT" and "DIGEST". The allowed methods and roles could be defined on a per http-bus basis as follows (extending the last example): | <http-provider name="http"> | <http-bus busid="sales"> | <methods> |  | <method name="GET" /> | <method name="POST" /> | </methods> | <roles> |  | <role name="salesAdmin" /> | </roles> | </http-bus> | | <auth method="BASIC" /> | </http-provider> | Where the method name can be an enum of the HTTP method types listed as requirements earlier in this thread, with the OPTIONS method always allowed (I think that was the requirement for OPTIONS). All methods are allowed by default. Transport guarantees might also be configured on a per bus basis as follows e.g. | <http-provider name="http"> | <http-bus busid="sales"> | <transport guarantee="CONFIDENTIAL" /> | </http-bus> | </http-provider> | Where the guarantee is an enum of CONFIDENTIAL, INTEGRAL or NONE (default). Of course all of this is open to change. This is just one set of options/suggestions. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246712#4246712 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246712

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: idea about JCA and 303 integration

by jesper.pedersen

For 5) use | ConstraintViolationException(java.util.Set<ConstraintViolation<?>> constraintViolations) | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246711#4246711 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246711

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: idea about JCA and 303 integration

by jesper.pedersen

Its even more simple than that :) The deployer has already created the objects and injected the property values. So you need to 1) Create the ValidatorFactory 2) Get the Validator interface 3) Validate the object passed in as an argument against the Default group (for now) 4) If an empty set is returned - do nothing 5) If the set contains ConstraintViolation's create an exception with the violations embedded The rest is handled by Hibernate Validator - which does its own annotation scanning. And you can assume that the correct classloader is already set. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246709#4246709 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246709

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Re-using the REST facade

by rmoskal

Sorry I for got to apply the right style to the xml: <custom expr="#{nodeService3}" g="335,152,92,52" name="department"> View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246688#4246688 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246688

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Re-using the REST facade

by rmoskal

That was my initial idea too. But when I do that the rest server throws errors when you try to do something like just enumerate deployed processes. They are Juel errors, property not found when the Juel script engine comes across references to beans that live on the spring context. For the above node Juel complains it can't find nodeService3. This is just when I issue the call to list deployed proceses. The processEngine used by the restful api will needs access to my spring context when doing things like sending signals to my app. I noticed the rest server gets its processEngine from jndi (in JBPMIntegration). Perhaps if I were to somehow publish the processEngine embeded in my spring context onto java:/ProcessEngine that would do the trick. Thanks for your time. Robert View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246686#4246686 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246686

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