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

[Design of EJB 3.0] - Re: RoleBasedAuthorizationInterceptorFactory dependencies

by anil.saldhana＠jboss.com

http://jira.jboss.com/jira/browse/EJBTHREE-1250 has removed any security manager lookup in the authz interceptor factory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140674#4140674 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140674

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: webservices ejb3 api usage

by anil.saldhana＠jboss.com

Please provide the following dependency in the maven repository. | | Missing: | ---------- | 1) org.jboss:jbossws-spi:jar:1.0.2.GA | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140672#4140672 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140672

16 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Quartz, timer unification, message inflow RAR

by wolfc

With the upcoming EJB 3.1 there are new demands on the timer service. These are not addressed by this SPI. I also agree with Tom that Quartz has too many weak spots. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140668#4140668 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140668

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBoss 2.0 Thread model

by david.lloyd＠jboss.com

It's pretty simple. Every message is associated with an Executor. You have a "main" Executor, which is typically a plain thread pool, which does any work that can be done in an unordered fashion. New messages that aren't related to any previous messages would be processed by this executor directly. Then you create a single OrderedExecutorFactory with your "main" Executor as its parent. Now if you know that all messages tagged with some ID must be processed in order, you get a new Executor from the factory and associate it with this ID. Then all your message processing for that ID is done sequentially. If there are some asynchronous things that can be done, you can always submit another task to the main Executor. anonymous wrote : Also I'd caution against the "execute on current thread if queue is empty" optimisation since if the current thread is the thread that does IO from the selector this can keep that thread tied up for a long time, during which time it can't service any more IO requests. Not sure what you're getting at here. There's no such optimization - basically the code says, "if this is the first time a task was added to the queue, then this executor is not running, so run it", and on removal, "if this was the last task removed from the queue, no need to run anymore". As far as using a concurrent queue - perhaps you could squeeze out a tiny bit more performance, but unless it shows up as a blip on a profiler, I'm not going to bother because frankly I doubt that there will be significant (unwanted) contention for the lock. (Remember that the purpose is to serialize access, after all) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140667#4140667 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140667

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: RoleBasedAuthorizationInterceptorFactory dependencies

by anil.saldhana＠jboss.com

| public class RoleBasedAuthorizationInterceptorFactory extends PerClassAspectFactoryAdaptor | implements AspectFactory | { | | public Object createPerClass(Advisor advisor) | { | // Must be a separate line (EJBContainer cannot be dereferenced) | EJBContainer container = EJBContainer.getEJBContainer(advisor); | SecurityDomain securityAnnotation = (SecurityDomain) advisor.resolveAnnotation(SecurityDomain.class); | | //If there is no annotation, return a null action interceptor | if(securityAnnotation == null) | return new NullInterceptor(); | CodeSource ejbCS = advisor.getClazz().getProtectionDomain().getCodeSource(); | String ejbName = container.getEjbName(); | return new RoleBasedAuthorizationInterceptorv2(container, ejbCS, ejbName); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140666#4140666 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140666

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: RoleBasedAuthorizationInterceptorFactory dependencies

by anil.saldhana＠jboss.com

The look up is useless in the interceptor factory. It needs to go. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140665#4140665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140665

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBoss 2.0 Thread model

by timfox

David - can you provide an example of how your OrderedExecutorFactory would be used in practice? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140659#4140659 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140659

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBoss 2.0 Thread model

by timfox

"david.lloyd(a)jboss.com" wrote : | This is essentially what I've done. My OrderedExecutorFactory is much simpler than the one in MINA (there's some IoSession-specific stuff in theirs so you can't really use it verbatim; mine is generic). | | Since the link seems to have gotten "killed" in your "editing" session, here it is again: http://tinyurl.com/33b4gq That's the kind of thing. Although I'd use a ConcurrentLinkedQueue or LinkedBlockingQueue to prevent having to synchronize on the whole list. Also I'd caution against the "execute on current thread if queue is empty" optimisation since if the current thread is the thread that does IO from the selector this can keep that thread tied up for a long time, during which time it can't service any more IO requests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140658#4140658 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140658

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBoss 2.0 Thread model

by david.lloyd＠jboss.com

"timfox" wrote : One way of implementing this is having a set of BlockingQueues one for each "id" value. | | Then you have a pool of workers that poll on these queues. | | This is basically how a ThreadPoolExecutor works, but instead of a single queue feeding it, you have many queues. | | I'd take a look at what Trustin has done in org.apache.mina.filter.executor.OrderedThreadPoolExecutor (which works similarly to how I've described) | | You want to avoid having one thread per id value since you may have many thousands of id values. This is essentially what I've done. My OrderedExecutorFactory is much simpler than the one in MINA (there's some IoSession-specific stuff in theirs so you can't really use it verbatim; mine is generic). Since the link seems to have gotten "killed" in your "editing" session, here it is again: http://tinyurl.com/33b4gq View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140655#4140655 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140655

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBoss 2.0 Thread model

by david.lloyd＠jboss.com

"timfox" wrote : I have seen this problem come up many times in different guises. | | What we're really talking about here is some kind of "sticky" thread pool executor. | | Where you have a pool of threads to service requests, but consecutive invocations can have an affinity for a particular thread depending on some key (this corresponds to the "session id"). | | I'm kind of surprised j2se doesn't already contain something that can do this. Yeah - well technically it doesn't have to be the same thread. The executor just has to guarantee that B "happens-after" A, in the same thread or a different one. I agree on the j2se statement (although it's really a trivial amount of code to implement; see the above link). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140654#4140654 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140654

16 years, 2 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 April 2008