"adrian(a)jboss.org" wrote:
As an aside, with those classes, it will also know that you don't want to be
invoked for deploy/undeploy if there is no such attachment.
i.e. no longer any need for the boiler place
Code:
if (unit.getAttachment(MyMetaData.class) == null)
return;
If you don't want this filtering, you can turn it off with
Code:
public MyDeployer()
{
super(MyMetaData.class);
setAllInputs(true);
}
IMO, there's just too much implicity in both the old and new deployment architecture.
My experience writing the first deployer in this new architecture was that I had to dive
through a lot of internal code to figure out what the hell was going on.
That's because there's never been documatation.
The old framework was only ever a prototype so we could flush out
requirements, its not surprising people did it wrong.
| It seems like this is getting worse with the new refactoring you did. I honestly
don't care about saving one line of if attachment exists code. It actually makes the
code more readable and more importantly, more understandable for people using your
deployer as an example for writing their own.
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059106#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...