October 2007 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: Transaction behavior of clustered SFSB caching

by wolfc

No I expand upon the concept, with SimpleLongevityCache.Entry. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093600#4093600 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093600

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Injection at invocation time, not instantiation time

by wolfc

The service beans are also used for one time startup logic. These never get called. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093599#4093599 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093599

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock in JBoss Messaging during JBoss5 shutdown

by anil.saldhana＠jboss.com

http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/main/org/jboss... You can see that I have added | fail("FIXME") | to some of the methods. Just remove one of them, maybe public void testMDBRunAs() throws Exception Then, start JBoss instance and in the testsuite module, run ant -Dtest=org.jboss.test.security.test.EJBSpecUnitTestCase one-test You should see some deadlock (server hang) on the server side or client side. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093598#4093598 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093598

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Transaction behavior of clustered SFSB caching

by bstansberry＠jboss.com

With this can we get rid of the SimplePassivatingCache.Entry concept? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093576#4093576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093576

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Injection at invocation time, not instantiation time

by cbredesen

The case against this would be service beans that aren't interactive, but are background workers, and thus never invoked. So at what point do you deploy/inject those? The obvious answer is that you make those work like the current service beans (deployed at startup) but then how do you differentiate between the beans that are invoked and ones that are purely background ones? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093573#4093573 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093573

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Injection at invocation time, not instantiation time

by bdecoste

The problem with delaying instantation or injection is that the @Service bean may never be invoked - it could be some background service ... God, I feel like Adrian talking to myself on the forums :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093571#4093571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093571

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Injection at invocation time, not instantiation time

by bdecoste

A customer is asking for injection to occur at invocation time, not bean instantiation time. This is a non issue for session beans as they are instantiated at invocation time, but it's an issue for Service beans that are instantiated at deploy time. Specifically the problem is if a @Service bean tries to inject @EJB(mappedName="xyz") and that bean is not yet deployed on another node, the @Service bean fails to deploy. Another way to resolve this is not to instantiate Service beans until invocation time just like session beans. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093566#4093566 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093566

18 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: @XmlElementWrapper/@XmlElements

by scott.stark＠jboss.org

So how would an application.xml module element have to be handled? It should be something like this, but the schema for the wrapping module element has an unbounded max: | class Application | { | @XmlElementWrapper(name="module") | @XmlElements( | @XmlElement(name="connector", type=ConnectorModule.class), | @XmlElement(name="java", type=JavaModule.class), | ... | ) | private List<Module> modules; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093565#4093565 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093565

18 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: DeploymentInfo/Template MCF

by scott.stark＠jboss.org

The ManagedPropertys of the template should already be wired to the ManagedConnectionFactoryDeploymentMetaData instance. The question is how are the ManagedPropertys of the template being created. It should be from the required properties of the ManagedObject for the root ManagedConnectionFactoryDeploymentGroup with a single ManagedConnectionFactoryDeploymentMetaData in its deployments property. If a template should include more than just required properties, then we should add a tempate=true/false field to the ManagementProperty annotation to identify these. In psuedo code, creating a ds should entail something like: | // Create the deployment template from a template ManagedConnectionFactoryDeploymentGroup | ManagedConnectionFactoryDeploymentGroup group = new ManagedConnectionFactoryDeploymentGroup(); | // Issue of what ManagedConnectionFactoryDeploymentMetaData subclass to create... | // TODO: type should be input from admin client | ManagedConnectionFactoryDeploymentMetaData ds = ...; | group.getDeployments().add(ds); | | // Get the template from the ManagedObject | // TODO: name and type should be input from admin client | ManagedObject groupMO = AbstractManagedObjectFactory.initManagedObject(group, "DefaultDS", "LocalTx"); | // TODO: | DeploymentTemplateInfo templateInfo = AbstractTemplateInfoFactory.createInfo(groupMO); | | // ... admin client updates template properties | // Profileservice calls to the template with the updated properties | public VirtualFile applyTemplate(VirtualFile root, String deploymentBaseName, | DeploymentTemplateInfo values) | throws Exception | { | // Need to apply the detached property values to ManagedPropertys bound to a ManagedObject/metadata instance | // Create the ManagedObject as above, but this time the ds type, and name should be in the properties. | ManagedConnectionFactoryDeploymentGroup group = ...; | ManagedObject dsDeploymentMO = AbstractManagedObjectFactory.initManagedObject(group, ...); | // Set the dsDeploymentMO ManagedProperty values | for(ManagedProperty prop : values.getProperties().values()) | { | ManagedProperty moProp = dsDeploymentMO.getProperty(prop.getName()); | moProp.setValue(prop.getValue()); | } | | // Create the template file from the ManagedConnectionFactoryDeploymentGroup | Class[] classes = {ManagedConnectionFactoryDeploymentGroup.class}; | JAXBContext context = JAXBContext.newInstance(classes); | Marshaller marshaller = context.createMarshaller(); | marshaller.marshal(group, fw); | ... | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093556#4093556 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093556

18 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: @XmlElementWrapper/@XmlElements

by alex.loubyansky＠jboss.com

Yes, maxOccurs=1 for XmlElementWrapper according to the spec. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093554#4093554 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093554

18 years, 6 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 October 2007