[Design of JBoss Transaction Services] - bundling JTS into AS 5.0
by jhalliday
So I'm mulling over how best to include JTS into AS 5.0. Right now it's a separate download and manual install, which sucks.
We should ship the necessary .jar and config files in the AS and either have a server with it already installed (e.g. 'default', 'all', 'all-jts') or at least provide scripting for as much of the install as possible (e.g. 'ant -f install-jts-to-server-all.xml')
There are a few complications: the .jar files and config files for JTA and JTS don't cohabit well. Having both on the classpath is asking for trouble, so we can't simply dump them both into 'all' and use the transaction-beans.xml to switch between them. Installing the JTS requires first uninstalling the JTA.
Right now I'm leaning towards editing the JBossAS build process so it pulls the JTS .jars and config file from the maven repo and puts them in docs/examples/jts along with an ant script that will copy 'all' to 'all-jts', ripping out the JTA and putting in the JTS in the process. There may be some bits of that process that will be tricky to automate fully as it requires editing existing xml files, but it should be possible to automate most of it. This approach makes for a smaller AS distribution footprint than providing a full server subdir with the jts in, as the cost of being less convenient for customers who do need the JTS.
Any further thoughts from the JBossAS side of the house before I start in on this?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171225#4171225
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171225
17 years, 7 months
[Design the new POJO MicroContainer] - Re: MDR doesn't work on annotated privates
by wolfc
"adrian(a)jboss.org" wrote : The idea of DeclaredMethodSignature is to get something working.
|
| I'd much rather use MethodSignature, it's just a case of finding a way to
| do it without adding performance penalities to (or even worse breaking)
| existing code.
|
| Like I said in an earlier post, once we know how to do that, we can retrofit
| DeclaredMethodSignature to be:
|
|
| | @Deprecated // legacy hack
| | public class DeclaredMethodSignature extends MethodSignature { ... }
| |
|
Although I agree, I don't see how that's possible. MethodSignature only works if you know the class hierarchy.
class A { void postConstruct() {} }
| class B extends A { void postConstruct() {} }
For object A1: MethodSignature postConstruct equals DeclaredMethodSignature A.postConstruct.
For object B1: MethodSignature postConstruct equals DeclaredMethodSignature B.postConstruct.
If I had @PostConstruct on A.postConstruct:
For object A1: has annotation @PostConstruct on MethodSignature postConstruct
For object B1: has no annotation @PostConstruct on MethodSignature postConstruct
while both MethodSignatures are equal.
I would say:
m1 = memoryMetaDataLoaderA.getComponentSignature(methodSignaturePostConstruct);
| m2 = memoryMetaDataLoaderA.getComponentSignature(declaredMethodSignatureAPostConstruct);
| assert m1.equals(m2);
and
m1 = memoryMetaDataLoaderB.getComponentSignature(methodSignaturePostConstruct);
| m2 = memoryMetaDataLoaderB.getComponentSignature(declaredMethodSignatureAPostConstruct);
| m3 = memoryMetaDataLoaderB.getComponentSignature(declaredMethodSignatureBPostConstruct);
| assert !m1.equals(m2);
| assert m1.equals(m3);
Right?
"adrian(a)jboss.org" wrote : Add it if you want, or raise a JIRA issue.
The assertion only highlights the problem, it doesn't solve anything.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171213#4171213
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171213
17 years, 7 months