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

[Design of Messaging on JBoss (Messaging/JBoss)] - Data and logs directory created in bin when running from dis

by timfox

When I run the standalone server from the distro, i.e. cd bin ./run.sh the data and logs directories are created inside the bin directory, this doesn't seem right to me, they should be created from the root directory View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236976#4236976 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236976

17 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: Remoting 3 and HTTP client

by richard.opalka＠jboss.com

JBWS-2674 depends on this issue as well. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236953#4236953 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236953

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: IdentityService API Usage update

by kukeltje

Hmm... does this mean the JBoss idm creates the groupId? I hope there is some nice logic behind it and not some 'hash' thingy (I've not looked at the JBoss idm code so forgive me if my remark is bs ;-)) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236951#4236951 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236951

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassPool for JBoss Reflection

by kabir.khan＠jboss.com

The classpools from asintegration-mc could be put into another jar, although I am not sure if jboss-reflect is the right place for them. Maybe they should be put into another project. Also, due to the workings of AOP, they extend AOPClassPool from the aop project, which in turn extends ScopedClassPool from javassist. Ideally we should have one jar for the classpool from aop, one for the classpool from asintegration-core, one for the one from asintegration-jmx and one for asintegration-mc. AOPClassPool and the ClassPoolFactories have some dependencies on the AspectManager, but it should be possible to abstract that out. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236945#4236945 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236945

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by jbarrez

Sorry, didnt know about the AsyncCommandService, should've checked before posting ;-) anonymous wrote : There should be a way for users to obtain a synchronous and an asynchronous version of the ProcessEngine. E.g. by adding a method ProcessEngine getAsyncProcessEngine() on the process engine itself. Isn't this confusing to have 2 process engines for people that want to use both sync and async commands (altough the use cases are limited, but they do exist). Can't the services returned by the processEngine be sync or async? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236930#4236930 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236930

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by tom.baeyens＠jboss.com

Commands and CommandService are not necessary to give the user the capability of async commands. There is already an AsyncCommandService, but it should be hidden behind the other services. So I would translate your point into: There should be a way for users to obtain a synchronous and an asynchronous version of the ProcessEngine. E.g. by adding a method ProcessEngine getAsyncProcessEngine() on the process engine itself. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236929#4236929 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236929

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by jbarrez

I believe we shouldn't impose a fixed sync/async way of working on the users of the remote api. I also think that usng a method param to change to async invocation is cumbersome for most users. So, perhaps we should create a sync CommandService and an Async CommandService? I'm also in favour of using EJB3. Since the commandservice normally is behind the service interfaces ... why not use a modern and cool implementation where everybody loves to work with? EJB3 runs today on all app servers I'm aware of (JBoss, Glassfish, Oracle, IBM, ...). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236925#4236925 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236925

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - cluster.management role used in clusters

by jmesnil

Now that https://jira.jboss.org/jira/browse/JBMESSAGING-1629 is implemented, the SecurityStore does not bypass anymore the permission check for the clustered user. This means that *every address which can be clustered* must add the "cluster.management" role to its address settings for the different permissions. The cluster user is used by management, bridges, cluster connections, etc. This makes the configuration complex: to make sure it works, I'm adding the "cluster.management" role to all permissions types in every address settings... it's not something that is user-friendly. I'm considering backtracking what I've done a little bit and bypass again the cluster user when checking the role in the security store. The cluster user will still be configurable and authenticated as a normal user, but it will be bypassed when checking roles (i.e. it will have all the roles). With this backtracking, the user'd not have to consider the cluster user when assigning the permissions to its addresses. It's something that will be completely internal to JBoss Messaging. wdyt? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236919#4236919 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236919

17 years

1
0
0 / 0

[Design of JBossXB] - multi-version, xsd/dtd, annotation, default namespace parser

by jeff.zhang

There are some ra.xml files, they are 1.5/1.6 version, defined by xsd or DTD, some properties defined in annotation in the class and overrided in the xml, and maybe it use default namespace (see JBMETA-198/199) So how we do it by using parser and metadata class? My idea is like this: 1. parse it by the newest version metadata class and xsd file 2. got exception, try dtd file 3. still got exception, try default namespace, if still error, return can't pase 4. check the version of pasered metadata, cast to right version 5. if define metadataComplete attibute, reflection class and get annotation, and merge metadata information Do you think this is reasonable processing? Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236915#4236915 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236915

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by tom.baeyens＠jboss.com

also async commands can be done behind the same interface. in that case, the command service can be replaced with a version that sends an async message to the job executor to execute the job asynchronously. in that case you have to choose if you want to use the whole api asynchronously or not. i'm not yet sure if we have to introduce a way to let users choose async or not on a method by method basis... wdyt ? the code is present but not yet tested/documented. that's for later as that doesn't have a priority yet. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236916#4236916 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236916

17 years

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