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

[Design of JBoss Build System] - component releases that depend on snapshot

by dimitris＠jboss.org

Here is a part of a dependency tree | org.jboss:jboss-transaction-spi:jar:5.0.0.Beta4:compile | +- jboss:jboss-common-logging-spi:jar:2.0.4.GA:compile | +- org.jboss.javaee:jboss-jca-api:jar:1.5.0.20070913080910:compile | \- org.jboss.javaee:jboss-transaction-api:jar:1.0.1.20070913080910:com | How are those component like jboss-jca-api:jar:1.5.0.20070913080910 or jboss-transaction-api:jar:1.0.1.20070913080910 produced? Are those snapshot dependencies that are automatically uploaded when the outer component is released? And is this considered a good practise? In this case we have a Beta4 version of the transaction-spi (and I believe the overal jboss-integration project) that depends on an untagged version of the jboss-javaee project. Am I missing something? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143432#4143432 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143432

17 years, 12 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: jee module's alt-dd

by alex.loubyansky＠jboss.com

A bit more generalized, how does this look? The change that is in this example in the EjbParsingDeployer could probably be in the SchemaResolverDeployer? Index: org/jboss/deployment/AppParsingDeployer.java | + protected EarMetaData parse(VFSDeploymentUnit unit, VirtualFile file, EarMetaData root) throws Exception | + { | + EarMetaData ear = super.parse(unit,file, root); | + List<DeploymentUnit> children = unit.getChildren(); | + if(children != null) | + { | + for(DeploymentUnit child : children) | + { | + String moduleName = child.getSimpleName(); | + ModuleMetaData module = ear.getModules().get(moduleName); | + if(module != null && module.getAlternativeDD() != null) | + { | + VirtualFile altDDFile = unit.getRoot().getChild(module.getAlternativeDD()); | + if(altDDFile == null) | + throw new IllegalStateException("Failed to locate alternative DD '" + module.getAlternativeDD() + "' in " + unit.getRoot().getPathName()); | + child.addAttachment(child.getSimpleName() + ".altDD", altDDFile); | + log.info("attached alt-dd " + altDDFile + " for " + child.getSimpleName()); | + } | + } | + } | + | + return ear; | + } | } | Index: org/jboss/deployment/EjbParsingDeployer.java | @Override | - protected void init(VFSDeploymentUnit unit, EjbJarMetaData metaData, VirtualFile file) throws Exception | + protected EjbJarMetaData parse(VFSDeploymentUnit unit, VirtualFile file, EjbJarMetaData root) throws Exception | { | - super.init(unit, metaData, file); | + VirtualFile altDDFile = (VirtualFile) unit.getAttachment(unit.getSimpleName() + ".altDD"); | + if(altDDFile != null) | + { | + log.info("using alt-dd: " + altDDFile); | + file = altDDFile; | + } | + return super.parse(unit, file, root); | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143431#4143431 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143431

17 years, 12 months

1
0
0 / 0

[Design of JBoss Web Services] - Jira and multiple fix versions

by thomas.diesler＠jboss.com

Folks, I propose when we work with Jira we only ever assign an issue to a single "fix version" Issues that apply to multiple stacks should be assigned to cxf/metro but not to native In that way, our workload estimates become more meaningful (because jira only counts the estimate once) and we have better control over our overall workload distribution metro: 50% cxf: 30% native: 20% View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143429#4143429 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143429

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Transition from mc state determined by event type

by scott.stark＠jboss.org

So the next issue we have with implementing the component factory is the ability to choose the target state based on the event taking us out of the current state. A stateful ejb can transition to discarded, passivated, method-ready-in-tx from the method-ready state. What control over the mc state transitions do we have for this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143427#4143427 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143427

17 years, 12 months

1
0
0 / 0

[Design of JBoss Build System] - Re: version properties in poms

by ALRubinger

No, these properties are just Strings. Same as -D switch. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143425#4143425 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143425

17 years, 12 months

1
0
0 / 0

[Design of JBoss Build System] - version properties in poms

by dimitris＠jboss.org

Except for convenience, i.e. show a compact representation of the version dependencies, is there any other reason to use version properties in the beginning of a pom, e.g. <version.jboss.messaging>1.4.1.Beta1</version.jboss.messaging> | Do version.* properties carry any special meaning for maven? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143423#4143423 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143423

17 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBAS-2408 - EJB3 / JCA integration

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | which we then implementation in JBossAS over the JCA metadata repository. | Obviously EJB3 is reposnsible for implementing the AOPEndpoint on top of its MDBContainer(s). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143408#4143408 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143408

17 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBAS-2408 - EJB3 / JCA integration

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | No. EJB3 is not the place for integration code. All EJB3 cares about is | I want to activate an endpoint with | * this callback | * these activation config properties | * some selection parameters to determine the rar, e.g. listener interface, rar name, etc. | i.e. there should be a jca spi in the jboss-integration that has something like: | public interface EndpointActivationBus | { | EndpointActivation activate(Endpoint endpoint, Set<ActivationConfigProperties> properties, RarSelection selection); | } | public interface EndpointActivation | { | deactivate(); | } | | public interface Endpoint | { | boolean isDeliveryTransacted(Method); | int getTransactionTimeout(Method); | // etc. | } | | public interface AOPEndpoint extends org.jboss.aop.Interceptor {} | public interface JMXEndpoint extends org.jboss.invocation.Interceptor {} | | public interface RarSelection | { | String getRarName(); | Class<?> getListenerType(); | Map<String, String> getProperties(); // for some kind of fuzzy match based on rar config | } | which we then implementation in JBossAS over the JCA metadata repository. You can imagine alternate methods where the caller does more work upfront if it knows a lot a about the rar, e.g. | EndpointActivation activate(Endpoint endpoint, ActivationSpec spec); | the activation spec obviously determines the rar. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143407#4143407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143407

17 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBAS-2408 - EJB3 / JCA integration

by adrian＠jboss.org

The correct fix for this is for JCA to provide an AbstractMessageEndpointFactory and "MessageEndpointInterceptor" (you actually need two for the two different models AOP or JMX, but they can share a lot of code). All the EJB2/3/POJO containers should do is provide callbacks for things like isDeliveryTransacted(Method), getTransactionTimeout(Method) and the dispatch interceptor (i.e. invoke the ejb container or pojo). This work is also tied up with the JCA metadata repository. "jesper.pedersen" wrote : | I can see two areas that would benefit the implementation: | | 1) The TODO in JBossMessageEndpointFactory::resolveResourceAdapter about the creation of the ObjectName for the RA - is this still valid ? | This should be replaced with the container passing the above mentioned callback to the JCA metadata repository. | 2) The use of JMSProviderAdapter in MessagingContainer which add a JAR dependency - we can just move this class to the ejb3 namespace | No. EJB3 is not the place for integration code. All EJB3 cares about is I want to activate an endpoint with * this callback * these activation config properties * some selection parameters to determine the rar, e.g. listener interface, rar name, etc. There a lot of other threads about this with more details in either the JCA forum and possibly the EJB3 or JMS forums? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143406#4143406 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143406

17 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - JBAS-2408 - EJB3 / JCA integration

by jesper.pedersen

I'm going to look into the http://jira.jboss.com/jira/browse/JBAS-2408 task which is about the integration between EJB3 and JCA in regards to inbound messaging for EJB 2.1 and EJB3. I have been going over the existing code - especially JBossMessageEndpointFactory, MessageInflowLocalProxy and MessagingContainer. The previous thread on this task discusses how the separation should be done using a MessageEndpointFactory, which is done. So what are the design/implementation goals for this task in context of the new microcontainer ? I can see two areas that would benefit the implementation: 1) The TODO in JBossMessageEndpointFactory::resolveResourceAdapter about the creation of the ObjectName for the RA - is this still valid ? 2) The use of JMSProviderAdapter in MessagingContainer which add a JAR dependency - we can just move this class to the ejb3 namespace The previous thread on this issue is here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73265 Any input on this task would great. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143396#4143396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143396

17 years, 12 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 April 2008