On Thu, 2008-09-04 at 14:32 +0200, Carlo de Wolf wrote:
On Thu, 2008-09-04 at 12:08 +0200, Adrian Brock wrote:
> On Thu, 2008-09-04 at 11:47 +0200, Sacha Labourey wrote:
> > Team,
> >
> > I am interesting in better understanding how you take decisions when
> > splitting classes between JARs. Let me be more accurate...
> >
> > Ideally, each macro-service (Tomcat, WS, EJB3, etc.) would have its own
> > MyService.sar file/directory in /deploy (or better, /deploy/system/).
>
> Another issue is the splitting out metadata models so we don't have
> to deploy the full jar including all the implementation details
> in server/[config]/lib, instead the meta model can be included in
>
> whatever.deployer
Up to a certain point. I don't want a JavaEE meta model in every
project. But I certainly want an EJB3 meta model which extends the
JavaEE meta model in the ejb3 project.
That's not what I said. A deployer can have its own internal model
but it could import jboss-metadata.jar for the standard javaee stuff.
The same goes for some pieces of code like the mapped resolver
deployer
which operates on the whole meta model. It should be split up into fine
grained resolvers.
Yes, I'm not a big fan of things like:
ejbMetaData = unit.getAttachment(JBossMetaData.class);
webMetaData = unit.getAttachment(JBossWebMetaData.class);
clientMetaData = unit.getAttachment(JBossClientMetaData.class);
if(ejbMetaData == null && webMetaData == null && clientMetaData == null)
return;
if(ejbMetaData != null)
{
...
}
if(webMetaData != null)
{
...
}
if(clientMetaData != null)
{
}
It shows a lack of abstraction and is not very OO.
e.g. if somebody wants to create a custom type of deployment that wants
to take part in the JavaEE resolving scheme it should be a case
of extending some helper class not modifying a "switch" statement. :-)
Carlo
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development --
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx