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

[Design of JCA on JBoss] - JCA ConnectionManager SubjectFactory Injection

by anil.saldhana＠jboss.com

http://jira.jboss.com/jira/browse/JBAS-5067 The new changes happen in: http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss... http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss... Injection happens in: http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss... | private static final String SUBJECT_FACTORY_NAME = "JBossSecuritySubjectFactory"; | private String subjectFactoryName = SUBJECT_FACTORY_NAME; | | attribute = new ServiceAttributeMetaData(); | attribute.setName("SubjectFactory"); | ServiceInjectionValueMetaData injectionValue = new ServiceInjectionValueMetaData(subjectFactoryName); | attribute.setValue(injectionValue); | attributes.add(attribute); | The SubjectFactory interface from the security project looks: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-spi/tag... The implementation of the SubjectFactory in AS5 is: http://anonsvn.jboss.org/repos/jbossas/trunk/security/src/main/org/jboss/... Questions: - Should I retain the property of jaasSecurityMgrService in BaseConnectionManager2? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152452#4152452 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152452

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: profile service, farming

by bstansberry＠jboss.com

Bit of a brain dump here. Any comments on my wrongheadedness would be much appreciated. :) When I think about what the clustering services inside the AS will be doing with clustered deployments, I see two main things: 1) Keeping repositories in sync if people are using individual local filesystem repos on each node. This task is minor/optional/secondary, but I include it for completeness. 2) Coordinating deployments around the cluster as the ProfileService running on each node becomes aware of changes in the repository. Ensure each node is aware of the change, use a configurable policy to execute the deployment (e.g. sequentially or simultaneously), extend any 2PC deployment capability the profile service exposes to a cluster-wide operation. This is the more significant task. Keeping repositories in sync ------------------------------------ Again, this is IMHO the less meaningful task, but one that seems pretty straighforward. Only relevant if the repository is the local filesystem, not enabled by default (even in an 'all' config). 1.As with deployers/ and deploy/ there is a scanner that reads a set of URIs (e.g. farm/) and presents deployments to the ProfileService 2.On startup before presenting deployments to ProfileService it reconciles the state of farm/ with the cluster, brings over added deployments not available locally, brings over modified deployments, removes deployments previously removed from cluster but still present locally. 3.After startup, no longer presents things to the ProfileService; the profile service is responsible for scanning for changes itself. 4.After startup, however, it continues to scan the farm/ dir for purposes of noticing changes and replicating them around the cluster. Coordinating deployments ---------------------------------- Here things get more fuzzy. "Coordinating" basically means either a) controlling the initiating of the deployment process on each node, or b) somehow pausing it in the middle and exchanging messages around the cluster until the cluster-wide state is appropriate and then resuming, or c) some combination of both. To me using a) implies some variant of the HDScanner concept -- i.e something that periodically queries the Profile for modified deployments and then invokes on MainDeployer to undeploy the old version and deploy the new version. Looking at the MainDeployer API it looks like it exposes enough methods for pretty fine grained control of this; e.g. the change(String, DeploymentStage) method implies the ability to walk things through deploy/undeploy step by step. Using b) implies writing a specialized Deployer(s) that does coordination in the deploy()/undeploy() methods. That seems conceptually wrong to me; i.e. a bit outside of the scope of what a deployer should be doing. An advantage of doing it in a Deployer is the possibility of using metadata that an earlier deployer could make available. For example, a bean annotated with @Farm or a war with a special tag in jboss-web.xml could be cluster-deployed without needing to be associated with DeploymentPhase.APPLICATION_CLUSTERED. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152451#4152451 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152451

17 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1062 and metadata

by ALRubinger

MyStateful should extend javax.ejb.EJBObject to become an EJB2.x Remote Interface. Technically, @Remote is to designate business interfaces, so in this case it shouldn't be required on the SFSB implementation class. We happen to support its use for both EJB2.x Remote and EJB3 Business Remote, but for a valid EJB2.x view the interface must extend EJBObject. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152448#4152448 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152448

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: expressing dependent states

by adrian＠jboss.org

"jhalliday" wrote : | Is that right? Does MC actually use or plan to use concurrent startup to speed things up? If so, there is potential advantage in sticking with parameter injection rather than injecting it as a property on my bean. Yes, but I don't really see how delaying the injection increases the concurrency? In most circumstances if you have dependencies they are going to wait until you are fully installed so it doesn't really matter if you inject some other service into a property or a lifecycle method. On an aesthetic point, some advocates of IOC (e.g. nano/pico container) suggest you should inject into the constructor parameters since then you can be immutable and it is less error prone (you are forced to inject all the parameters while people are not forced to set all the properties or configure lifecycle methods). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152439#4152439 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152439

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: State of our failing tests

by clebert.suconic＠jboss.com

As the close is done asynchronous... I need to change the test to wait the completion of closes and callbacks for the test to be valid again. I have added a method on TestableJournal (debugWait). Adding the call to the wait on the test fixed the problem. I have changed it locally and it is fixed. I will commit it shortly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152437#4152437 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152437

17 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1062 and metadata

by emuckenhuber

While adding the logic described in JBMETA-41 to jboss-metadata there are now 3 tests failing, due the following: | package org.jboss.test.metadata.annotation.ejb3; | | @Stateful(name="AnotherName") | @Remote(MyStateful.class) | @RemoteHome(MyStatefulHome.class) | public class MyStatefulBean | { | ... | } | | public interface MyStatefulHome extends EJBHome | { | public MyStateful create(String x); | } | | public interface MyStateful | { | | } | So MyStateful should actually extend extend javax.ejb.EjbHome and will be the remote interface for the stateful bean - instead of a BusinessRemote? Or did i miss something? :) Thanks, Emanuel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152434#4152434 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152434

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: expressing dependent states

by jhalliday

wow, cool. So in that case injecting it as a property of my bean will give the same value as injecting it as a parameter of a lifecycle method call. The difference I guess is limited to the potential for concurrent execution. In the case of injection as a bean property, the lifecycles must be strictly serial ordered. Whereas, with lifecycle method parameter injection, the bean on which the injection is occurring can go through any of the lifecycle phases before the one for which it requires the injected parameter, concurrently with the lifecycle of the bean that will be injected. Is that right? Does MC actually use or plan to use concurrent startup to speed things up? If so, there is potential advantage in sticking with parameter injection rather than injecting it as a property on my bean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152425#4152425 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152425

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Support marshaling or unmarshaling the soap message us

by tfennelly

"maeste" wrote : Hi, | I'm really very very busy in these days and I would give contributions only after I would have a chance to put seriously my mind on the problem (and maybe wrote some proof of concept code with wise). | Just give me some days Stefano... just in case we're getting our wires crossed... we were just wondering if you had any comments re the work that Jim's been doing and how it might compare with what you've been doing on the other side of the equation with WISE i.e. WS invocation. We didn't want you to investigate anything more than you've already done. Maybe I'm misreading you :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152422#4152422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152422

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Support marshaling or unmarshaling the soap message us

by maeste

Hi, I'm really very very busy in these days and I would give contributions only after I would have a chance to put seriously my mind on the problem (and maybe wrote some proof of concept code with wise). Just give me some days View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152420#4152420 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152420

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: bug triage...

by kukeltje

bump... oh... I already was at the top ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152416#4152416 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152416

17 years, 10 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 May 2008