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

[Design of EJB 3.0] - Porting Deployers to EJB3 Source Tree

by ALRubinger

Time to address this again, after some more thought. Previous discussion is: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151711 The Problem: Timeboxed EJB3 Releases assume that no changes will be required of AS Deployers, regardless of whether an SPI has been altered. Because Deployers are orthogonal (in most cases), their role is decoupled from compile constraints, but we still rely heavily on their output. Most relevant here is the preparation of the metadata from which we create EJB Containers. Can't Have it Both Ways: "scott.stark(a)jboss.org" wrote : ...legacy deployers like ejb2 and the war deployer still have way too many dependencies on other jbossas pieces to pull out. | | The Ejb3Deployer does have other integration pieces like JBossASDepdencyPolicy, JBossASKernel, Ejb3JBoss5Deployment, so those would have to be separated out into another layer and injected when configured for jbossas. In other words, in the present setup we cannot simply move the deployers out of AS as they're needed by other AS components. We also cannot update them from the EJB3 Plugin in subsequent EJB3 releases. So we're stuck in an undesirable situation. For this reason, we must provide an EJB3 component to define deployers (I use this term generically, this is not necessarily MC Deployers SPI) without AS dependencies. AS may then bring these in. A Disagreement over EJB3 Project Scope: "adrian(a)jboss.org" wrote : Individual projects should not be making policy decisions. They're job is to "do one thing well". In ejb3's case, its task is to create an EJB container from an EJBMetaData object. | ... | You don't care how the EJBMetaData gets constructed, that is a policy decision of the appserver. e.g. parsing annotations, programmatically or something else. EJB3 should be able to take in artifacts, create the appropriate metadata, and deploy; this is what will enable us to run outside of the AS. In our Unit Tests we're currently hacking up metadata in an inconsistent fashion to mock the deployers' actions. It is the responsibility of *EJB3 Core* to create Containers from Metadata. However, there's nothing preventing an "EJB3 Deployers" Component from providing metadata creation out of JARs, EARs, or even .class files. Proposal: Stemming from some thoughts and discussions with Carlo and Ales - * Create "org.jboss.ejb3:jboss-ejb3-deployers" in repos/jbossas/projects/ejb3 * Deployers to be created must rely on a new vendor-agnostic SPI * The Deployers themselves become an MC-specific plugin to the SPI abstraction. This decouples the EJB3 deployment mechanism from MC, and further paves the way for EJB3 to run atop other IoC providers. The Take Home: * We provide a mechanism for deploying EJBs outside of AS (rapid-development, user-friendliness) * We further decouple from MC's Deployer SPI, in direction to support arbitrary IoC Containers (user choice) * We may then continue with EJB3 Releases without worry of what's changed within the AS deployers upon which we currently rely (timeboxing, a stated EJB3 Project Goal) I haven't been Brocked in awhile, so let's hear it. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163437#4163437 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163437

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoping of war/jar file embedded in sar service archives

by scott.stark＠jboss.org

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't use IDE auto format on commit

by david.lloyd＠jboss.com

In addition to Eclipse, IDEA (and many other text editors) can support a mode wherein trailing spaces are only trimmed from modified lines. This way the file is slowly cleaned, without introducing massive sweeping code changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163433#4163433 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163433

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't use IDE auto format on commit

by trustin

I agree that automatic removal of trailing spaces can be a problem for a while. However, once all trailing spaces are removed globally (e.g. a huge yet vague commit of changed empty lines), it shouldn't be a problem IMHO. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163430#4163430 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163430

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't use IDE auto format on commit

by skajotde

Eclipse 3.4 has nice option to fomat on save only last edited lines. I think auto format on edited code is ok and dont mess diffing with old code. Auto format on whole file may corrupt and reach unreadable svn diff ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163428#4163428 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163428

17 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-5647 HAPartition Sync Call with RspFilter

by bstansberry＠jboss.com

Yeah, it's kind of hacky, probably a bad idea. Don't do it if the overhead of translating from Address to ClusterNode in the adapter class is small. HA-JNDI is in the cluster module, which has a JGroups dependency. So a class that can satisfy both ResponseFilter and RspFilter doesn't introduce any new dependency. The hacky thing is ClusterPartition looking at an object of type ResponseFilter, seeing it implements RspFilter, and treating it as a RspFilter even though it was not presented that way. Good catch on the pom dependency. I need to look why that's there (rather than just being transitive via the optional JBC dependency.) Probably because JBC 2.1.0.GA didn't depend on the JBC release I wanted in the AS, but I don't see why I'd want JGroups in the ha-server-api pom because of that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163426#4163426 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163426

17 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-5647 HAPartition Sync Call with RspFilter

by galder.zamarreno＠jboss.com

I'm trying to play a bit devil's advocate here. Optimisations are important and I suppose sometimes there're some trade-offs that you have to make to achieve them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163422#4163422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163422

17 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-5647 HAPartition Sync Call with RspFilter

by galder.zamarreno＠jboss.com

"bstansberry(a)jboss.com" wrote : As an optimization, ClusterPartition can check if a ResponseFilter passed to callRemoteMethods also implements RspFilter. If so, just pass it through, don't wrap it. The filter used by HA-JNDI could be such a filter. Hmmm, I'm a bit confused here. I clearly understand the performance optimisation here but by doing so, aren't you just going against the abstraction of the JGroups layer? Ok, maybe not entirely against it because clients do need to adhere to passing a ResponseFilter, and whether they pass a RspFilter as well it's up to them but you're effectively promoting implementations to directly tie themselves to RspFilter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163421#4163421 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163421

17 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-5647 HAPartition Sync Call with RspFilter

by galder.zamarreno＠jboss.com

"bstansberry(a)jboss.com" wrote : More directly relevant, the ha-server-api project has no dependency on JGroups, and thus consumers of it don't either... Hmm, actually ha-server-api/pom.xml shows a dependency on JGroups. I suppose this is the result of ha-server-api depending on JBC, which would indirectly bring JGroups. I understand your point though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163416#4163416 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163416

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't use IDE auto format on commit

by clebert.suconic＠jboss.com

This is my own opinion... Invoking auto-format manually is okay as an exception (not every time), as long as you're 100% sure nobody else is using the same file (e.g. initial commit)... or when formatting is really screwed up for some reason. But we should never use auto-format automatically on commit. "Trustin" wrote : | * trailing space removal | This might affect SVN diffs on things you didn't change. It might cause some hassle on updates and merges "Trustin" wrote : | * Adding @Override annotation automatically | * Optimizing imports View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163414#4163414 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163414

17 years, 9 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 July 2008