[Design of AOP on JBoss (Aspects/JBoss)] - Re: jbossretro/aop integration
by kabir.khan@jboss.com
I've got the pool/repository stuff moved into javassist, and have created a javassist 3.3.0.snapshot and jboss retro 1.0.2.snapshot. AOP wraps/extends this pool as needed for the extra functionality.
The tests now pass on my machine, and I am in a position to have a pure jdk 5 codebase using jboss retro to run with jdk 1.4. I'll need to "re-annotate" some of the tests, i.e use JDK 5 annotations w/ retro instead of the annotationc JDK 1.4 ones.
Annotationc can be kept alive for a while, since annotions compiled in by that are readable by the retroed aop code. Meaning we have two ways to annotate code for use with AOP
1. JDK 5 code and jboss retro
| @Foo
| public class Blah{
| Set<String> test;
| }
|
2. JDK 1.4 code and annotationc
| /**
| *@(a)org.acme.Foo{
| */
| public class Blah{
| Set test;
| }
|
I'll keep this on hold for a few days, so if anybody can think of any issues with this switch to JDK 5 speak now
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957908#3957908
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957908
19 years, 8 months
[Design of JBoss/Tomcat Integration] - Re: TC6 integration 1st pass
by bill.burke@jboss.com
"scott.stark(a)jboss.org" wrote : I don't think it matters currently as this will have to be updated for the migration of the deployers to the VDF update. I'm close to having jboss boot with the mc/vdf.
|
I'm guessing you mean that it doesn't matter if I hack up the deployer...Web deployer needs a lot of reorganization anyways to do the dependency resolving that the EJB3 container currently already does.
What about the metadata though? I'm currently thinking to go back and use org.jboss.metadata classes instead of creating a new hierarchy. There's just too much code that depends on those metadata classes that would really suck to touch just to get this JavaEE5 integration in for Tomcat (Webservices for example). We'll also want to try and reuse the old EJB 2.1 BMP/CMP containers for EJB 3.0.
The other idea is to just reparse web.xml with the new hierarchy and just hack it in.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957885#3957885
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957885
19 years, 8 months
[Design of JBoss Collaboration Server] - Re: JBCS on Jboss 4.0.4GA
by osterday
Elmo,
I can't answer with 100% certainty, but I can try from my experience...
1) Yes, you need to use the MySQL driver from the install or newer - we're using mysql-connector-java-3.1.12-bin.jar without problems. The earlier driver we had been using broke stuff. ;-)
2) I think JBCS M4 installed version can't run on GA. I think even M5 installed version can't. I'm using a compliled version from CVS HEAD on GA and it works fine. Originally we used M5 on CR2.
3) I don't use jBPM, so can't help there.
In regard to upgrading... I'm pretty sure you'll have to blow away the db for M4 to use M5 as the data structures aren't compatible. So if you've got messages in the db you want, I guess you'll need to export them somehow... I think there was a post about this.
There are even some differences in M5 and HEAD on how the body ids work so older messages break - although I was able to fix this with a db script.
I'm hoping there aren't too many more changes to the data structures so I don't have to rework things when 1.0 comes out. ;-) That's the price you pay for early adoption I guess!
Hope that helps...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957884#3957884
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957884
19 years, 8 months
[Design of Management Features on JBoss] - Re: Nested deployments, duplicate names and jsr77
by mclaugs
The Nesting feature of JBoss has always made the jsr77 expression of some deployment very hard to think about. Since we have defined a j2eeType of ServiceModule and Looking at the spec I would suggest this as a possible approach.
Lets assume you have this deployment.
fooSar.sar containing a fooEar.ear containing a fooWar.war
jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,Name=fooSar.sar
for the SAR
jboss.management.local:J2EEServer=Local,j2eeType=J2EEApplication,Name=fooEar.ear
for the EAR
jboss.management.local:J2EEServer=Local,J2EEApplication=fooEar.ear,j2eeType=WebApplication,ServiceModule=fooSar.sar,Name=fooWar.war
for the WAR
What I am thinking is that we do not treat a SAR like an application because a SAR archive can contain an application but it might also contain just a web archive or the other types as well, so I think having the J2EEApplication= key for the SAR can lead to a lot of confusion.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957870#3957870
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957870
19 years, 8 months