December 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: Multithreaded services and their EPR(s)

by estebanschifman

When Mark first explained the concept of EPR to me, he assimilated an EPR to a simple 'address'. If many people live in the same address, even in the same apartment/suite, and we are looking for one of them in particular, we need to know the name of the person we are seeking (UID). One address, many people = one EPR, many UIDs I don't share the description of many listeners in the same EPR being "...hundreds of EPRs...". It is the very same EPR with hundreds of listeners servicing it: each registration with a unique identifier. This concept is independent of if the many listeners are several threads in the same JVM, or distributed in disparate address spaces. If this is solved with one entry, or hundreds, in the registry underlying repository, it will be completely hidden for the user. They could't care less. Having a UID added to the registration process would not alter the underlying architecture of alpha1. It would be a requirement of the registration API. That's why in a post on the public forum I made on friday, there was a suggestion for the Registry to return a UID at registration time, and that same UID be required at de-registration time. E View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990818#3990818 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990818

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - EJBTHREE-402, serialVersionUID needs to be fixed

by scott.stark＠jboss.org

This now long standing EJBTHREE-402 serialversionUID problem needs to be fixed. Running unit tests from within eclipse is broken because the implicit serialVersionUID calculated is different between the eclipse generated jdt class, and the sun jdk class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990816#3990816 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990816

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Breaking up the MC project and Mavenizing it

by scott.stark＠jboss.org

My thougts are that we need to transform the existing jbossbuild projects under: https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/ into a maven based build, and break up the container project in the process as its jboss-container.jar artifact is too coarse. At a minimum, it should probably be broken up into projects for the following packages: P1 org.jboss.classloading P2: org.jboss.metadata org.jboss.repository - maybe should be dropped as metadata is replacing it P3: org.jboss.net org.jboss.virtual - VFS code P4: org.jboss.annotation org.jboss.beans org.jboss.classadaptor org.jboss.config org.jboss.joinpoint org.jboss.reflect Every project should be further broken up into an spi/api artifacts for the spi packages, and a plugin artifact for the plugin/implementation packages. The aspects in the aop-mc-int project should be in a separate common aspects project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990814#3990814 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990814

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Multithreaded services and their EPR(s)

by kurt.stam＠jboss.com

1. I think we agree that the registration of the EPR should *not* be done in the thread. 2. However as Esteban pointed out that if we register multiple listeners in different address spaces we still have a problem. And I think it is actually useful to know from a registry position that we have mutliple physical listeners, for load balancing and failover scenarios. So should we have these listeners register as 'different' EPRs of the same service? --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990812#3990812 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990812

18 years, 1 month

1
0
0 / 0

[Nukes Development] - Re: URIencoding is not working... Not able to save the Germa

by leonidsh

URIencoding works only for GET method, not for POST This is Tomcat behaviour. See: http://java.sun.com/developer/technicalArticles/Intl/HTTPCharset Did You find any solution for POST? Thanks, Leon View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990806#3990806 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990806

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Multithreaded services and their EPR(s)

by mark.little＠jboss.com

First, the EPR is on a per service basis, not a per thread basis. Threads are an implementation issue that should not be exposed to users/clients. If there are hundreds of threads working on behalf of a given service (aka business logic), it would be wrong to then have hundreds of EPRs. In some ways I agree with Esteban, but in others I think this is related to the thread pool issue. I'm assuming that irrespective of the reloading issue, there is a single listener thread at the "bottom" of the hierarchy that does the registration for the service and all it does upon receipt of a message is to spawn a new worker thread. That's pretty much what most distributed systems have been doing since the mid 1990's when threads (or lightweight processes as they were known then) became more widely available. Assuming we follow this model and ignore reload for now, then we should be fine. Now back to the reload issue. As I've said before, I think there are good reasons for reloading and reinstantiating the configuration/setup, but that is an implementation specific concern for services. It shouldn't be something that is mandated for all listener implementations. In fact, by default I think all that should happen is a reload of the parameters and if anything has changed we trigger an event and leave it up to the event handler to figure out. If that handler wants to re-instantiate, then it's up to it to figure out how to do it without screwing up anything else. We could provide a handler for JMS, but does anything else really need it at the moment? Assuming we can agree on what the issue(s) is(are) and potential solutions, the next question is: what can we do for the GA that is quick and gives us a solution? It may not be the best solution, but we can revisit that after the release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990787#3990787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990787

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Breaking up the MC project and Mavenizing it

by alesj

Scott, what exactly did you mean by breaking up the project? We once mentioned lifecycle, injection annotations separation - so that developers can use them. What other 'components' do we want? I've created a JIRA issue about this - assigned to me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990786#3990786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990786

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Multithreaded services and their EPR(s)

by estebanschifman

The problem, in my view, goes beyond just multithreaded listeners. It will in fact be common to all situations in which more than one listener is registered to the same [category,name,EPR], which could be quite frequent. E.g. processes in different address spaces servicing the same JMS queue. So there might not be something like "...the parent of all the threads ... responsible for registering the service..." Multithreading has been the circumstance that surfaced the problem, but in my opinion it will occur in other scenarios as well. We could consider the idea of expanding the registering key to [category,name,EPR,UID] which would solve the problem for good. Thanks. Esteban View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990784#3990784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990784

18 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityContext

by scott.stark＠jboss.org

We need to make the SecurityContext an interface (it already essentially is), and define some utility methods for accessing key Subject info so that consumers don't have to know how the Subject/SubjectInfo maintain info for things like: - String getUsername(SubjectInfo s) - Principal getUserPrincipal(SubjectInfo s) For Resource, let's generalize the layer into a type and pull the know types out into a separate ResourceTypes constants class. - MappingContext/MappingProvider, this seems restrictive in that one has to pass in a mutable mappedObject to the performMapping method. This won't work for Principals, Certificates, credentials. This should also be parameterized to support an expected type: | public interface MappingProvider | { | /** | * Initialize the provider with the configured module options | * @param options | */ | void init(Map options); | | /** | * Map the passed object | * @param map A read-only contextual map that can provide information to the provider | * @param input an Object on which the mapping will be applied | * @return the mapping of input | * @throws IllegalArgumentException if the input is not understood by the | * provider. | */ | <T> T performMapping(Map map, T input); | } | With this, we probably want the SecurityContext.getMappingContext(Class mappingType, String key) to allow selection of MappingProvider that support the T,key pair. We also want to move away from requiring a thread local as an aspect of the spi. In general the call context metadata should contain the SecurityContext, and security aspects would access this. For some apis like JACC we may still need integration via thread locals. I'm not seeing how the run-as identity and roles fits into the SecurityContext. How does it? I would also like to sketch out how we do the following with the revised spis: - Validate incoming calls that have no authentication info. This could be a trusted call based on internal run-as, external run-as with trust assertion, external run-as with trust based on known hosts, external run-as based on trusted transport cert. - How would we implement the jsr196 authentication? - How would we configure a scenario where the caller of an ejb was mapped to another identity/credentials for accessing resources like jca connections? For example, a caller derived username/password, principal/credential for a database or jms connection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990783#3990783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990783

18 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: Purge Policy for Connection Pools

by weston.price＠jboss.com

Please post your issue on the user forum. If you are indeed running into issues we should and would like to know about it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990780#3990780 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990780

18 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2006