[jboss-jira] [JBoss JIRA] Commented: (AS7-944) EJB lifecycle interceptors that are not included in the deployment are not applied
jaikiran pai (JIRA)
jira-events at lists.jboss.org
Mon Jun 13 04:12:23 EDT 2011
[ https://issues.jboss.org/browse/AS7-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608173#comment-12608173 ]
jaikiran pai commented on AS7-944:
----------------------------------
Here's a IRC discussion of this issue:
{quote}
08:51:01 IST) jbossbot: jira [AS7-944] EJB lifecycle interceptors that are not included in the deployment are not applied [Open (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/AS7-944
(08:51:29 IST) Jaikiran: the issue there is that we don't build a Index (== CompositeIndex) out of module dependencies for deployment
(08:51:33 IST) Nihility [~Nihility at redhat/jboss/Nihility] entered the room.
(08:51:33 IST) mode (+v Nihility) by ChanServ
(08:55:49 IST) dmlloyd: Jaikiran: in this example are the included classes coming from a static module or another deployment?
(08:56:16 IST) Jaikiran: dmlloyd: a module on which the deployment depends
(08:56:23 IST) Jaikiran: we don't build indexes out of those modules
(08:56:33 IST) Jaikiran: so the compositeindex can't see the annotation on those modules
(08:56:43 IST) dmlloyd: yeah. that was our intended behavior
(08:56:59 IST) Jaikiran: yeah, so i'm not really sure whether we should change that or not
(08:57:24 IST) Jaikiran: seam or other 3rd party components might add a framework level interceptor to the ejb and expect it to work
(08:57:36 IST) Jaikiran: i.e. seam and the other 3rd party being configured as a module
(08:58:03 IST) dmlloyd: Jaikiran: yeah, that's a good point. It makes it impossible for us to ship interceptor classes basically
(08:58:33 IST) Jaikiran: yeah.
(08:59:40 IST) Jaikiran: the other point to this is - do all modules have jandex index computed once so that it can be reused?
(08:59:56 IST) dmlloyd: no, presently we do not create indexes for built-in modules at all.
(08:59:57 IST) Jaikiran: or would a dependency on a blah module mean, the index recomputation has to happen again?
(09:00:16 IST) Jaikiran: ok, so that's going to be tricky to create the index
(09:00:19 IST) dmlloyd: if we did decide to solve this, one big part would be running jandex over the module repository at build time
(09:00:31 IST) dmlloyd: not sure how Nihility feels about all this though
(09:00:42 IST) Jaikiran: if the module happens to be a user specific one, then it won't be part of hte build
(09:00:43 IST) Jaikiran: *the
(09:01:08 IST) Jaikiran: for example (probably irrelevant one) jdbc drivers modules
(09:01:17 IST) Nihility: originally my idea was
(09:01:19 IST) Jaikiran: (couldn't find another example)
(09:01:33 IST) Nihility: that modules MUST include indexes (we never scan them)
(09:01:45 IST) Nihility: and that we only consider them with a certain flag
(09:02:14 IST) Nihility: e.g. use_indexes="true"
(09:02:18 IST) Nihility: or something like that
(09:02:50 IST) Nihility: kind of like how we handle META-INF/services
(09:03:22 IST) dmlloyd: Nihility: so you would still re-read the index at least every time it's requested? as a resource?
(09:03:53 IST) Nihility: dmlloyd: yeah either that or we cache them, but i dont like caching them from a memory perspective
(09:03:57 IST) kkhan: ok, I'll take a look
(09:04:21 IST) Nihility: dmlloyd: note that the jax-rs subsystem does a form of this, because resteasy ships with annotations that it needs to scan itself
(09:04:35 IST) Jaikiran: interesting
(09:04:36 IST) ***Jaikiran checks
(09:05:06 IST) Nihility: one of the things i wanted to avoid though, was alot of self scanning
(09:05:12 IST) Nihility: so whatever solution, ideally we limit it
(09:05:36 IST) Nihility: a plus is that the index file is very fast to read
(09:06:00 IST) Jaikiran: what's self scanning?
(09:06:31 IST) Nihility: self scanning is where we have to scan our own code to take action, vs just doing it programtically
(09:07:05 IST) Nihility: e.g. we cant boot until we analyze 3k annotations
(09:07:19 IST) Jaikiran: ok, i see what you mean
(09:07:48 IST) Nihility: but if its bundling interceptors for reuse by developers
(09:07:55 IST) Nihility: that makes sense imo
(09:08:26 IST) Nihility: part of inifnispans remaining init time is self reflection processing
(09:08:35 IST) Nihility: for wiring injections
(09:08:43 IST) Nihility: (using annotations)
(09:08:51 IST) Jaikiran: right. if it hits perf noticeably then we can make it deployment specific I guess - i.e. check modules for annotations only if enabled (somehow) for the deployment
(09:09:39 IST) kevinpollet left the room (quit: Quit: kevinpollet).
(09:09:44 IST) dmlloyd: we could make it part of "Dependency" maybe
(09:09:45 IST) kevinpollet [~kevinpoll at 217.112.54.72] entered the room.
(09:09:52 IST) dmlloyd: or Dependencies or whatever it is
(09:10:15 IST) dmlloyd: Dependencies: org.jboss.foobar services annotations,org.jboss.baz export,etc.
(09:10:25 IST) Nihility: yeah exactly
(09:10:29 IST) Jaikiran: yeah
(09:10:49 IST) Nihility: if you guys can come up with reasonable automatic rules though thats fine
(09:10:52 IST) dmlloyd: it's even better if the indexes live in a unique subdirectory of META-INF like META-INF/jandex/index.file
(09:10:59 IST) Jaikiran: for this to work properly, we would need the pre-indexed modules which we currently don't have
(09:11:00 IST) Nihility: like if all EJB deployments that have a dep on blah should always see annotations
(09:11:07 IST) Nihility: that sounds fine to not require it
(09:11:36 IST) Nihility: Jaikiran: thats pretty easy to do, check the resteasy example
(09:11:44 IST) Nihility: we just modify the build to run the index task
(09:11:52 IST) Nihility: and include it as an additional resource in the module.xml
(09:12:14 IST) Jaikiran: oh yeah, i saw that over the weekend. wasn't sure why it was disabled (other than perf reasons)
(09:12:26 IST) Jaikiran: build time perf i.e
(09:12:37 IST) Nihility: was it disabled?
(09:12:47 IST) Nihility: hmm that might have been accidental
(09:12:50 IST) Jaikiran: i don't see it running currently
(09:12:54 IST) ***Jaikiran checks again
(09:12:57 IST) Nihility: oops
(09:13:53 IST) Nihility: oh its there
(09:14:00 IST) Jaikiran: it's been parameterized
(09:14:08 IST) Nihility: ./org/jboss/resteasy/resteasy-jackson-provider/main/resteasy-jackson-provider-2.1.0.GA-jandex.jar
(09:14:10 IST) Jaikiran: only resteasy modules use "jandex=true"
(09:14:12 IST) Jaikiran: in build.xml
(09:14:19 IST) Jaikiran: rest modules don't generate those indexes
(09:14:26 IST) mmoyses is now known as mmoyses_
(09:14:29 IST) kevinpollet left the room (quit: Ping timeout: 276 seconds).
(09:14:33 IST) hbraun left the room (quit: Quit: hbraun).
(09:15:21 IST) Nihility: right yeah
(09:15:24 IST) Nihility: so we can just add that flag
(09:15:30 IST) Nihility: to whatever we need indexes for
(09:15:51 IST) Nihility: we can even index jdk classes if we had to
(09:16:07 IST) Jaikiran: ok
(09:16:09 IST) Nihility: like standard sdk ones i mean
(09:16:13 IST) Jaikiran: yep
(09:16:18 IST) Jaikiran: so overall, this looks doable
{quote}
> EJB lifecycle interceptors that are not included in the deployment are not applied
> ----------------------------------------------------------------------------------
>
> Key: AS7-944
> URL: https://issues.jboss.org/browse/AS7-944
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.0.0.Beta3
> Reporter: Marius Bogoevici
> Assignee: jaikiran pai
>
> Suppose that we have a class
> {code}
> @Startup @Singleton @Interceptors(A.class, B.class)
> public class MyEJB {
> }
> {code}
> Where A.class is included with the deployment and B.class is included in a module that is visible to the deployment.
> B will be identified correctly as an interceptor for MyEJB, but LifecycleAnnotationParsingProcessor will not process it (as it apparently handles only components found within the deployment). Therefore, B will be ignored when creating the interceptor set for MyEJB, since ComponentInstallProcessor will treat it as a class that has no lifecycle methods.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list