[JBoss Microcontainer Development] New message: "Re: Deployer ordering issue for EJB/JAX-RS/WAR?"
by Adrian Brock
JBoss development,
A new message was posted in the thread "Deployer ordering issue for EJB/JAX-RS/WAR?":
http://community.jboss.org/message/519398#519398
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
I think Carlo has a better understanding of what Bill is talking about - terminology problem again. :-)
He is talking about Components rather than SubDeployments.
But that doesn't sound like the right thing to order after?
Ordering after the ComponentDeployer for EJBs would work since it controls the ordering in which the deployers are invoked
(for the whole deployment - parent/child/components).
It's only the mandatory input - setInput() or passed to the constructor - that decides whether to ignore your deployer if it doesn't have it.
The problem with ordering after the ComponentDeployer would be that it is very late. It is when you start doing stuff to the runtime.
Typically you want to get your metadata all sorted out before that, otherwise different parts of the runtime would see different config.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519398#519398
16 years, 2 months
[JBoss Microcontainer Development] New message: "Re: Deployer ordering issue for EJB/JAX-RS/WAR?"
by Ales Justin
JBoss development,
A new message was posted in the thread "Deployer ordering issue for EJB/JAX-RS/WAR?":
http://community.jboss.org/message/519395#519395
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
I think we have a misunderstanding here. :-)
Bill is asking about EjbMetaData, where Carlo is already talking about its components - JBossEnterpriseBeanMetaData.
As I don't understand what exactly are you interested in, I'll answer in a more generic way.
By default we handle parent deployments first.
But there is a flag that you can set on the deployer to handle children first.
By simply stating inputs you only affect the order. There are required inputs which also affect the actual usage of the deployer.
I know we should handle ejbs in .wars, but I have no clue on how we actually do that. Carlo?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519395#519395
16 years, 2 months
[JBoss Microcontainer Development] New message: "Re: Deployer ordering issue for EJB/JAX-RS/WAR?"
by Adrian Brock
JBoss development,
A new message was posted in the thread "Deployer ordering issue for EJB/JAX-RS/WAR?":
http://community.jboss.org/message/519394#519394
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
> mailto:bill.burke@jboss.com wrote:
>
> JAX-RS needs to scan for EJBs within a WAR that might expose JAX-RS endpoints. Right now, EJBs are in the same DU as the WAR. The question I have is, what happens when EJBs become a child DU of the WAR? I need to scan EJB metadata and then, if it has JAX-RS metadata, modify JBossWebMetaData.
>
> Are DUs deployed inner-most first?
Why would the EJBs be in a child DU? WARs don't have child DUs. See WARStructure.
WEB-INF/lib/*.jar are not subdeployments they are just part of the WAR's classpath.
To answer your last quest (probably redundant?), you can decide what order the DUs are passed to your deployer, see
Deployer::isParentFirst() which returns true by default from AbstractDeployer.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519394#519394
16 years, 2 months
[JBoss AOP Development] New message: "Re: ClassPool Refactoring"
by Flavia Rainone
JBoss development,
A new message was posted in the thread "ClassPool Refactoring":
http://community.jboss.org/message/519315#519315
Author : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com
Message:
--------------------------------------------------------------
> mailto:kabir.khan@jboss.com wrote:
>
> While I am here, I noticed that the point 3) in http://community.jboss.org/message/281717#281717 has not been done. I want to change ClassPoolRepostitory.callback to a list, which would mean changing the API from:
>
> *public* *void* setClassPoolRepositoryCallback(ClassPoolRepositoryCallback callback)
> *public* ClassPoolRepositoryCallback getClassPoolRepositoryCallback()
>
>
>
> to:
>
>
>
> *public* *void* addClassPoolRepositoryCallback(ClassPoolRepositoryCallback callback)
> *public* *void* removeClassPoolRepositoryCallback(ClassPoolRepositoryCallback callback)
> *public* Collection<ClassPoolRepositoryCallback> getClassPoolRepositoryCallbacks()
>
>
>
>
> While this is a change in API, I seriously doubt anybody is using this yet, apart from the unreleased AOP stuff Flavia is working on, so I'll make this change unless Ales objects by Monday afternoon :-)
Thanks, Kabir! Doing this and checking for whether it added some overhead was next in my list (I was first dealing with the performance hit, which I considered more urgent).
I'll profile it next week, once I'm back.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519315#519315
16 years, 2 months
[JBoss Microcontainer Development POJO Server] New message: "Re: StructureModificationChecker and Synch with VFS3"
by Ales Justin
JBoss development,
A new message was posted in the thread "StructureModificationChecker and Synch with VFS3":
http://community.jboss.org/message/519307#519307
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> With the strategy discussed in this post, does it make sense to have a SynchWrapperModificationChecker? Are there use cases for still having a the deployment root be periodically synchronized with the the original physical location?
This workaround was introduced due to how JBossWeb works.
e.g.
If you had to create copy -- which we did due to Winz locking crap & resource loading at undeploy - JBW code worked on a copy.
But users of course don't have a clue about that copy (nor should they),
hence they expect when they changed the (exploded) original, the copy needed to reflect those changes.
Dunno how JBW works these days, and I'm not following this descussion in details, to know if/how this still applys.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519307#519307
16 years, 2 months