I think JSR88 is only made optional. So it's not bad to keep it. I agree with David that we can focus our effort on other things first.
-Jack On Wed, Nov 25, 2009 at 11:14 AM, Shawn Jiang <[email protected]> wrote: > > > On Wed, Nov 25, 2009 at 3:14 AM, David Jencks <[email protected]>wrote: > >> >> On Nov 24, 2009, at 12:46 AM, Shawn Jiang wrote: >> >> Currently, JSR-88 implementation are widely used by geronimo console and >>> shell. But, JSR-88 is not a part of Java EE 6 spec anymore, Will JSR-88 >>> still be supported in Geronimo 3.0 ? >>> >>> Or we can replace JSR-88 with more elegant implementation to remove the >>> extra abstract in JSR-88 ? >>> >> >> There are 2 parts to jsr-88, at least in my thinking >> >> - remote deploy capabilities. This is useful and I think the design is >> adequate although not optimal. I don't consider redesigning this a high >> priority but if you have some ideas and some time I'd like to know more. I >> wouldn't mind keeping jsr-88 compatibility but this is not really essential. >> > > I don't have new ideas on this for now. I'm asking this because I want to > know if it's OK for us to continue call JSR-88 API when migrating the deploy > shell commands. > > >> >> - vendor plan model (dconfigBeans). These are pretty weird and useless >> but we are using them in at least the database portlets to generate plans. >> Replacing all of our plan stuff with jaxb should let us replace this too. >> I hope we can get this done for g 3.0 but its not currently my top >> priority. >> >> Unless redesigning the jsr-88 stuff will make reimplementing in gogo a lot >> easier I'd be tempted to concentrate on getting the existing server to work >> with little redesign. >> > Thanks ! > > >> >> thanks >> david jencks >> >> >>> -- >>> Shawn >>> >> >> > > > -- > Shawn >
