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

[Design of JBoss jBPM] - Re: Identity management docs

by heiko.braun＠jboss.com

I mean the WS facade doesn't deal with it. I would expect the JDPL core to deal with authorization when the command facade is used. Does it callback JAAS? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126249#4126249 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126249

18 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS brings Metro/CXF but in what version?

by richard.opalka＠jboss.com

"heiko.braun(a)jboss.com" wrote : Does this make sense to you guys? | Yes, it makes perfect sence to me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126248#4126248 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126248

18 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS brings Metro/CXF but in what version?

by heiko.braun＠jboss.com

I would just regard the prefix as branding. As thomas said, it's a new era. Therefore I would opt for jbossws-wsf-XYZ. WSF (web service framework) is something we included in the brand when we started the SPI. It's reflected in the package names as well. | * jbossws-wsf-native-2.0.3 | * jbossws-wsf-metro-1.0.0 | * jbossws-wsf-cxf-1.0.0 | Changes to SPI, framework, etc would trigger new releases of each stack anyway, right? I am looking at this from a users point of view. The prefix versioning just confuses people. "Did they release a new metro version?" This is what I would ask myself. Regardless if that was causing changes to the SPI or the framework. If any fix requires changes to the SPI, all stacks need to update anyway. So I'd say we release by a rule of thumb: - Any change to the SPI, framework requires an update to each stack - At least each stack needs to be run through QA - QA means a tagged framework version and thus an update to the stack (version.properties) In this case I don't see the need for a confusing prefix versioning like 'jbossws-3.0-XYZ'. Does this make sense to you guys? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126246#4126246 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126246

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: FIELD granularity web session replication tests

by kabir.khan＠jboss.com

I can work around this, but would like to know if there are any chances of moving jboss-metadata.jar to the bootstrap level? Although, I expect this isn't really an option? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126238#4126238 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126238

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: FIELD granularity web session replication tests

by kabir.khan＠jboss.com

I think I need access to the JBossWebMetaData attachment from my AspectDeployer. The problem is that jboss-metadata.jar is in a different classloader, i.e. AspectDeployer is in bootstrap cl, and jboss-metadata.jar is deployed in the deploy/ directory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126236#4126236 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126236

18 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Identity management docs

by tom.baeyens＠jboss.com

ok. makes sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126228#4126228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126228

18 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: RM Sender/Receiver as High Available (HA) Components

by richard.opalka＠jboss.com

First identified problem is HA itself. Imagine the following usecase: Client sends WS-RM message to a webservice endpoint that is not available. The default AS behaviour in such case is 404 (resource N/A). To overcome this problem here are the potential solutions that comes into my mind: 1) Deploy a special servlet that would do the following steps: * will match all http(s) requests that would result in 404 on running AS instance (is it doable?) * will ignore all http(s) POST requests that wouldn't contain SOAP envelope with WS-RM 1.0/1.1 protocol elements (quite performance issue but realizable) 2) Deploy a special servlet that would do the following steps: * will reside on /wsrm/* web context * all "GET WSDL" http(s) requests would return a modified WSDL document to reference the endpoint using /wsrm prefix for web context. (Of course only if such WSDL exists - otherwise it would return 404.) Example: | | client request GET .../wsrm/ctx/endpoint?wsdl | special servlet request GET .../ctx/endpoint?wsdl | RETURN modified WSDL or 404 (if above WSDL isn't available) | * will ignore all http(s) POST requests that wouldn't contain SOAP envelope with WS-RM 1.0/1.1 protocol elements (quite performance issue but realizable) For both above approaches it is supposed to use ServletContext.getContext() method to gain access to the context for various parts of the server, and as needed obtain RequestDispatcher objects from the context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126210#4126210 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126210

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: JBossTS overriding commons-logging discovery mechanism

by bstansberry＠jboss.com

No, no test case. You can see the effect by starting the AS all config and then watching the server.log for a while after it's started. Lots of this: 2008-02-03 10:34:12,166 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Recycle queue is empt | y | 2008-02-03 10:34:16,916 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] process(): region: / | 2008-02-03 10:34:16,916 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] processed 0 node even | ts in region: / That output is being logged at TRACE by JBossCache but is coming out at DEBUG. The *simple* problem isn't with the remapping of JBossTS's own logging discussed at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=93949. It's that the com.arjuna version of Log4JLogger still maps trace onto debug like this: | public void trace(Object message, Throwable t) { | logger.log(FQCN, Priority.DEBUG, message, t ); | } | | public boolean isTraceEnabled() { | return logger.isDebugEnabled(); | } | The com.arjuna code probably came from an earlier version of commons-logging that still did that. Effect is that trace means debug for all commons-logging users in the AS. That's easy enough to fix just by updating the com.arjuna Log4JLogger. A harder problem is some of the other stuff the AS's forked version of Log4JLogger does. Whenever asked to create a log4j Logger instance, it uses the TCCL to load the class and thereafter uses reflection to invoke on it. I guess that is to allow isolation of log4j subsystems between deployments. (Scott can talk better to that; I believe he added it.) To get that functionality back in place, we'd either need to merge it into the com.arjuna version, or do something like you said where we swap out the com.arjuna version once the JBossTS code is done instantiating its loggers. I don't know enough about JBossTS logging to know how practical or hacky the latter is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126197#4126197 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126197

18 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Identity management docs

by heiko.braun＠jboss.com

anonymous wrote : | or does it imply authorization checks as well ? | No, that's JBPM responsibility. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126182#4126182 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126182

18 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Removing hypersonic support

by Kevin.Conner＠jboss.com

Mea Culpa :) The main issue with hypersonic, certainly the one which is biting us the most now, is that it does not support transaction isolation. This is something that we need, within the jBPM integration area and other areas. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126171#4126171 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126171

18 years, 2 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 February 2008