The only objection I have is putting everything in a single module and
just separate concerns on a package level.
As I've pointed out a couple of times, in the AS 7 code base we're not
vigilant enough nor does the review process catch design issues. For the
review process to do a proper design check would form an unwanted choke
point. So we still need to find ways to guard the code against design
regression.
Carlo
On 08/25/2011 12:48 AM, Stuart Douglas wrote:
I have updated by branch, I have migrated the tests and moved the ejb
classes into org.jboss.as.ejb3. As far as I can see it is ready to
merge if we decide to go ahead with this.
Stuart
On 25/08/2011, at 8:26 AM, Andrig Miller wrote:
>
>
> ------------------------------------------------------------------------
>
> *From:*"Jason T. Greene" <jason.greene(a)redhat.com
> <mailto:jason.greene@redhat.com>>
> *To:*"Stuart Douglas" <stuart.w.douglas(a)gmail.com
> <mailto:stuart.w.douglas@gmail.com>>
> *Cc:*"JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org
> <mailto:jboss-as7-dev@lists.jboss.org>>
> *Sent:*Wednesday, August 24, 2011 3:20:12 PM
> *Subject:*Re: [jboss-as7-dev] Moving EJB3 code into the AS7
> source tree
>
> On 8/24/11 4:08 PM, Stuart Douglas wrote:
> > Hi Guys,
> >
> > While looking at some EJB3 stuff I began to wonder just how much
> stuff
> > from the JBoss EJB3 maven artefacts we actually use. Even though
> there
> > is a lot of artefacts, it turns out that we use around 75
> classes from
> > EJB3, and more than half of them are timer service related (It looks
> > like a lot of the stuff in the EJB3 package is either legacy
> stuff that
> > is just hanging around).
> >
> > Given that the majority of the actual EJB logic / implementation
> is in
> > the AS modules (in the EJB and EE modules), I was wondering if
> it would
> > be worth merging the whole of EJB into AS7 and dumping the EJB3
> > aggregator project altogether.
> >
> > I have a branch that does this here (although this branch has not
> > migrated any tests yet):
> >
> >
https://github.com/stuartwdouglas/jboss-as/tree/remove
> >
> > Personally I think this would make it much easier to refactor,
> and would
> > also allow us to remove some adaptor classes between AS7 and
> EJB3 (e.g.
> > AS7 has to sub class the EJB3 interceptors, rather than EJB3
> providing
> > real jboss invocation interceptors).
>
> I agree 1000% on this. In the past we had already decided to keep the
> ejb3 impl in the AS tree, so I think we should avoid splitting off
> components that are purely ejb3 specific and don't have use
> elsewhere.
>
> I haven't reviewed all of this patch, but one thing that I had
> noticed
> earlier is that we have some code that was just copied over and not
> really in use (e.g. some broken pool implementations). IMO if we
> aren't
> using / supporting stuff in AS we should just not carry it over.
>
> +1 to both of these. It would make my life easier on the performance
> team too.
>
>
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev