17:03:15 <emmanuel> #startmeeting
17:03:15 <jbott> Meeting started Mon Jun 27 17:03:15 2011 UTC.  The chair is emmanuel. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:15 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:03:18 <hardy_> I think you know better what is needed later on to bind the metadata to the runtime engine
17:03:31 <lightguard_jp> Great, MeetBot! Love this thing
17:03:36 <sebersole> hardy_: y'all are starting this other meeting
17:03:39 <sebersole> we can chat later
17:03:48 <hardy_> sebersole: ok
17:03:52 <emmanuel> So the idea was to all gather to discuss how we could improve the CDI / Seam user experience for Hibernate Search users
17:04:33 <emmanuel> Today, if a user do @Inject FullTextSession session @Inject FullTextEntityManager
17:04:35 <lightguard_jp> Great, MeetBot! Love this thing
17:04:37 <emmanuel> this should work
17:04:54 <emmanuel> #topic @inject
17:05:08 <emmanuel> do we see other areas where injecting should work?
17:05:19 <sannegrinovero> yes, I prepared a short list
17:05:28 <emmanuel> I imagine we could let user inject @Inject SearchFactory
17:05:34 <sannegrinovero> * QueryBuilder (qualified per entity?)
17:05:35 <sannegrinovero> * SearchFactory
17:05:46 <sannegrinovero> * Analyzer 1)qualified by name 2)qualified by type (is it possible to have them both?) 3) the global non-qualified one - analyzers need a Disposer too, but are threadsafe and shoul be reused.
17:06:04 <sannegrinovero> and finally: * accessing a readonly IndexReader directly from an entity type? would be nice, as it needs to be disposed, while it's not common to need this, the procedure to retrieve one is a bit verbose so a little help would be nice.
17:06:17 <sannegrinovero> in a but more complex area:
17:06:24 <sannegrinovero> * Support injection of other services in class/field bridges?
17:06:28 <sannegrinovero> * injecting in filters !!
17:06:32 <sannegrinovero> * security: what about enabling some filters by default? Mainly to hide unauthorized entities, as with Hibernate filters
17:06:49 <sannegrinovero> [finished my dump]
17:07:01 <emmanuel> thanks
17:07:08 <emmanuel> let's start with the first point
17:08:01 <emmanuel> lightguard_jp: query builder is retrieved like that
17:08:02 <emmanuel> searchFactory.buildQueryBuilder().forEntity(Book.class).get();
17:08:38 <lightguard_jp> Injecting a query builder keyed by an entity would be helpful. Looks like we could create a producer for this and have the user specify the class.
17:09:03 <lightguard_jp> It could be a nonbinding attribute and we could pull it from the annotation in the producer
17:09:03 <emmanuel> ideally we would need some way to get a QueryBuilder injected with something like that
17:09:03 <emmanuel> @Inject @ForIndexedEntity(Book.class) QueryBuilder builder;
17:09:39 <emmanuel> lightguard_jp: does that mean reading the annotation from the injection point all the time at  runtime?
17:09:43 <lightguard_jp> Yep
17:09:48 <emmanuel> :(
17:10:00 <emmanuel> This is a slow spot in Java
17:10:16 <emmanuel> I was hoping for a solution computed at initialization time
17:10:22 <lightguard_jp> I'm not sure of any other way to do it, unless you built up producers at deploy time.
17:10:50 <sannegrinovero> that could work as a QueryBuilder is stateless, bound only to the type
17:11:10 <sannegrinovero> but can you bind the appropriate one to each annotation then?
17:11:14 <emmanuel> sannegrinovero: well it's not entirely stateless, you can override things
17:11:19 <emmanuel> but we could decide not to support that
17:12:19 <emmanuel> lightguard_jp: so how would you "you built up producers at deploy time."?
17:12:42 <sannegrinovero> emmanuel, +1
17:12:44 <lightguard_jp> We can create producers at deploy time, I'm looking up the correct event to listen to
17:14:14 <hardy_> out of interest, where would this code live? In the Seam code base or as a CDI module in Search?
17:14:44 <lightguard_jp> Good question, may depend on which team wants to maintain it.
17:15:06 <emmanuel> hardy_: I think it should be an Hibernate Search module
17:15:13 <emmanuel> that's the trend these days
17:15:47 <lightguard_jp> emmanuel: Not seeing one where we can observe each @Inject that's found.
17:16:09 <hardy_> fine w/ me regarding the module
17:16:38 <emmanuel> lightguard_jp: can you ping pmuir on #weld-dev while we continue
17:16:43 <hardy_> when it comes to CDI itself my knowledge is purely based on reading some examples
17:16:46 <sannegrinovero> lightguard_jp, I assume you can add one?
17:17:14 <lightguard_jp> sannegrinovero: I was talking about CDI lifecycle events
17:17:53 <sannegrinovero> lightguard_jp, haa right forgot we're dealing with a spec
17:17:53 <emmanuel> @Inject SearchFactory is a no brainer
17:18:23 <emmanuel> it should work like @Inject EntityManagerFactory except you unwrap the corresponding EMF to get the SearchFactory
17:18:24 <sannegrinovero> right, unless there are multiple around. is this supported for Session right now?
17:18:58 <emmanuel> sannegrinovero: good question, lightguard_jp? if there are multuiple PUs, how do you deal with that?
17:19:15 <emmanuel> Ask the user to define a qualified producer method?
17:19:44 <lightguard_jp> Yep
17:20:40 <emmanuel> ok so it will work well when a single PU is defined and the user will have to do things by hand if more are involved
17:20:53 <sannegrinovero> ok, shall we skip to analyzers?
17:21:24 <emmanuel> pmuir: we had a question @Inject @ForEntity(Book.class) QueryBuilder builder
17:21:52 <emmanuel> where builder shjould be built like this searchFactory.buildQueryBuilder().forEntity(Book.class).get();
17:22:09 <emmanuel> could we somehow at CDI init time build the right producers?
17:22:24 <emmanuel> ie analyzing each injection point and look for @ForEntity
17:22:40 <emmanuel> and cache the producer generated
17:22:51 <pmuir> just make @ForEntity an annotation, not a qualifier
17:23:02 <emmanuel> the idea is to avoid to lookup the @ForEntity annotation at run time all the time
17:23:08 <sannegrinovero> pmuir, aren't they all annotations ? :P
17:23:09 <emmanuel> (java hot spot
17:23:10 <lightguard_jp> pmuir: I didn't see anything that really works well, and there's only one place we can replace a producer, doesn't look like a place to create one (unless I'm missing it in the docs).
17:23:12 <pmuir> and then create a dependent scoped producer method for QueryBuilder that injects the InjectionPoint
17:23:25 <pmuir> and inspect the annotation there
17:23:51 <lightguard_jp> Yeah, that was my idea too.
17:24:08 <pmuir> whats the problem?
17:24:11 <emmanuel> oh so InjectionPoint cache annotation and cache?
17:24:39 <emmanuel> remember in seam where we did getAnnotation(In.class);
17:24:44 <emmanuel> we realized that it was slow
17:24:55 <emmanuel> due to a synchronize / lock somewhere in the JDK
17:25:00 <emmanuel> I want to avoid that
17:25:25 <pmuir> in Weld you will get an unsynchronized access to the annotation at that point I think
17:25:30 <pmuir> let me see
17:26:13 <hardy_> emmanuel: on a tangent, do do you have more information about this locking issue (someone created an issue in HV the other day mentioning some lockoing issue around annotations)
17:26:57 <pmuir> yes, because you do ip.getAnnotated().getAnnotation(ForEntity.class)
17:27:19 <sannegrinovero> btw emmanuel, was checking ConnectedQueryContextBuilder, it seems the only state differentiating two QueryBuilders is (entityType && searchFactory instance); there's the analyzer too, but this is inferred from the entityType.
17:27:21 <pmuir> you always go through CDI's abstraction over the JDK annotations
17:27:24 <lightguard_jp> That's not using reflection is it?
17:27:37 <pmuir> atm Weld does cache this in a CHM always
17:27:40 <lightguard_jp> CDI caches that stuff doesn't it?
17:27:49 <emmanuel> hardy_: Class#getAnnotation calls initAnnotationsIfNecessary() which is synchronized
17:27:49 <lightguard_jp> That's not guaranteed by the spec though is it?
17:27:52 <lightguard_jp> pmuir: ^^
17:27:56 <pmuir> we are thinking of possibly reducing that somewhat as it uses too much heap
17:28:21 <pmuir> lightguard_jp: yes it's an impl detail of CDI
17:28:27 <pmuir> but it's always an impl detail
17:28:42 <pmuir> regardless of how you do it with CDI
17:28:42 <emmanuel> sannegrinovero: not following you
17:28:54 <pmuir> CDI could always do runtime analysis of annotations using refl
17:29:02 <emmanuel> pmuir: ok, so at least in Weld this approach would not suck too much unless you got rid of it
17:29:06 <emmanuel> (the optim)
17:29:42 <sannegrinovero> emmanuel, was about you saying that QueryBuilder is not stateless, and that this solution would then not support some extra context. I couldn't find extra context which would not be supported.
17:30:02 <pmuir> emmanuel: yes it should be O(1)
17:30:13 <pmuir> and even if we get rid of it somewhat, it won't be complete
17:30:28 <pmuir> e.g. we might switch to an approach where we cache often requested ones or something
17:30:40 <emmanuel> sannegrinovero: you have overridesForField(String field, String analyzerName);
17:30:50 <emmanuel> which we could add to the @ForEntity annotation
17:31:01 <emmanuel> though at this stage @ForEntity is probably not a good name
17:31:10 <pmuir> but there isn't a way to register a producer for every qualifier - that isn't really that sensible ;-) - without hacking the internals
17:31:53 <emmanuel> pmuir: well we could be listening to injection points and prebuild the producer somehow. That looks semsible to me ;)
17:32:34 <pmuir> if you see this is a perf problem you could build a cache of IP -> the class
17:32:36 <pmuir> and use that
17:32:46 <emmanuel> pmuir: I'm lazy ;)
17:32:47 <lightguard_jp> There isn't an event that we can listen to for injection points, unless I missed it.
17:32:49 <pmuir> you need cdi 1.1 to listen to UPs
17:32:50 <lightguard_jp> pmuir: ^^ is there one?
17:32:55 <pmuir> i mean ips
17:32:59 <pmuir> lightguard_jp: 1.1
17:33:33 <sannegrinovero> emmanuel, ahh right. didn't catch that one. we should have it return a new instance instead of mutating the original, good to change for HS4 ?
17:33:34 <lightguard_jp> Okay
17:33:37 <emmanuel> pmuir: you mean at init time right? but I can inject the IP in my producer and do what I want in 1.0
17:33:50 <lightguard_jp> Yep
17:34:21 <emmanuel> so that settles the technical implementation detail: worse case scenario, we do cache in the producer
17:34:45 <emmanuel> (probably better regardless actually)
17:35:00 <gastaldi> What ? No CDI on JPA 2.1 ? :)
17:35:02 <pmuir> emmanuel: yes
17:35:08 <emmanuel> sannegrinovero: mutating who the QueryBuilderContext?
17:35:26 <sannegrinovero> emmanuel, no the EntityContext
17:35:50 <sannegrinovero> (HSearchEntityContext)
17:36:22 <emmanuel> #action Support @Inject @QueryBuilder(for=Entity.class, overridesForFields = …) (we can support overridesForFields later)
17:36:58 <sannegrinovero> would it still need @Inject if it's an "annotation" instead of a qualifier?
17:37:24 <emmanuel> #action support @Inject SearchFactory (multiple PUs won't be supported and will require users to write a qualified producer and write the unwrapping code themselves)
17:37:33 <emmanuel> sannegrinovero: hum yes
17:38:05 <sannegrinovero> ok :)
17:38:10 <emmanuel> sannegrinovero: about analyzers
17:38:28 <emmanuel> you need a disposer because there is a close method somewhere?
17:39:00 <sannegrinovero> emmanuel, yes. but being multithreaded they could be disposed at application shutdown
17:39:20 <sannegrinovero> (assuming they are reused - otherwise they should be closed all the time)
17:39:26 <emmanuel> sannegrinovero: this contract is unclear today in HSearch
17:39:36 <emmanuel> Do we give back the same analyzers?
17:39:51 <emmanuel> I guess we do except for the wrapping analyzer
17:40:00 <gastaldi> emmanuel: Sorry, which project are you talking about when you said "Support @Inject @QueryBuilder(for=Entity.class, overridesForFields = …)" ?
17:40:06 <emmanuel> so the user should not call close() himself
17:40:13 <lightguard_jp> gastaldi: HSearch
17:40:18 <gastaldi> oh ok
17:40:19 <emmanuel> gastaldi: CDI extensions for Hibernate Search
17:40:23 <gastaldi> cool
17:40:37 <gastaldi> There should be a new feature on CDI 1.1 called Service Handlers
17:40:54 <lightguard_jp> gastaldi: Like the ones in Solder?
17:40:58 <gastaldi> Yup !
17:41:04 <sannegrinovero> emmanuel, I'll have to check that. I recently opened Bug 	HSEARCH-765 to check for a similar (but different scope) issue
17:41:05 <jbossbot> jira [HSEARCH-765] close ScopedAnalyzers used at indexing time [Open (Unresolved) Bug, Major, Sanne Grinovero] http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-765
17:41:14 <emmanuel> sannegrinovero: (am I right?) ^ if I am, then CDI should not close these analyers either
17:41:32 <hardy_> the "closing" of analyzer is news to me
17:41:58 <emmanuel> hardy_: yeah, I was aware of it thanks to 765 :)
17:42:01 <sannegrinovero> hardy_, the close() method was added somewhere during 2.9.x
17:42:55 <emmanuel> lightguard_jp: so assuming anayzer muct be .close() when they are done, could we still inject them witha  producer method and uninject them with an "unproducer" method?
17:43:04 <hardy_> maybe I've seen it, but it definitely slipped my mind
17:43:31 <lightguard_jp> emmanuel: Yep http://docs.jboss.org/cdi/api/1.0/javax/enterprise/inject/Disposes.html
17:44:04 <emmanuel> lightguard_jp: right but the scope would be "dependent scope" I guess in our case, is that still correct?
17:44:32 <lightguard_jp> Yeah, dependent I think would make the most sense
17:44:43 <lightguard_jp> I don't think people keep them around very long, do they?
17:44:55 <lightguard_jp> pmuir: Can you inject the IP into a disposer method?
17:45:08 <sannegrinovero> lightguard_jp, keep what around for long?
17:45:16 <emmanuel> lightguard_jp: I dont' think you need to as you would get the Analyzer injected anyways
17:45:33 <lightguard_jp> An analyzer
17:45:46 <emmanuel> disposes(@Disposed Analzyer analyzer) { analizer.close(); }
17:46:00 <lightguard_jp> Would a user want to keep an analyzer around for longer than a method call?
17:46:14 <lightguard_jp> Say like a conversation (or heaven forbid, a session)?
17:46:29 <emmanuel> #action Sanne checks if Analyzers provided to users via SearchFactory.getAnalyzer() must be closed by the user or not (my guess is not)
17:46:48 <sannegrinovero> emmanuel, I'm checking right now, and it seems you're right
17:47:12 <sannegrinovero> we just miss to close them at shutdown
17:47:33 <emmanuel> #action sannegrinovero open a JIRA to close Analyzers at shutdown :)
17:47:44 <emmanuel> hehe I love this bot ;)
17:47:48 <sannegrinovero> I'm doing that already :)
17:47:49 <hardy_> :-)
17:49:20 <emmanuel> #action Support @Inject @Analyzer (the HSearch annotation) Analyzer analyzer; if @Analyzer has no param set, inject the global analyzer, otherwise inject the requested analyzer
17:49:43 <emmanuel> sannegrinovero: hardy_: WDYT though, is analyzer useful enough to get it injected now that we have the DSL?
17:51:05 <hardy_> I think we could do w/o injection, especially since we propagate the DSL as preferred way of writing queries
17:51:11 <sannegrinovero> well you won't be using it all the time, so lower prio, but it's still very useful for non-trivial queries.
17:52:15 <emmanuel> I'm neutral, for sure SearchFactory and QueryBuilder are the biggest ones
17:53:10 <emmanuel> The next topic is injection of read only IndexReader
17:53:10 <hardy_> +1
17:53:20 <emmanuel> I'd say it's the same level as Analyzer
17:53:27 <emmanuel> and require @Disposes for sure
17:53:28 <hardy_> +1 for SearchFactory and QueryBuilder are the biggest ones
17:53:49 <sannegrinovero> neutral too, if I have the SearchFactory I'm not that far from an Analyzer instance. let's keep it out for now.
17:54:18 <emmanuel> #action SearchFactory and QueryBuilder are the most important wrt injectability, the others would be nice to have
17:54:24 <hardy_> it is such a rate use case anyways imo
17:55:02 <lightguard_jp> emmanuel: #info instead of #action ?
17:55:21 <emmanuel> whatever shows up in the logs is good enough :)
17:55:36 <lightguard_jp> Lol
17:55:47 <emmanuel> Injection of servicer for user provided classes in Hibernate Search (ClassBridge, FieldBridge and potentially even other services but these two are the most important
17:55:56 <emmanuel> how much do you guys think it would be
17:56:21 <emmanuel> lightguard_jp: today we instanciate user provided bridge classes via its no-arg constructpr
17:56:23 <lightguard_jp> Sorry, my usage of HSearch has been limited, what's condensed version of what those classes do?
17:56:44 <emmanuel> they let you convert a property value into a String
17:56:48 <emmanuel> that will be indexed
17:56:55 <sannegrinovero> lightguard_jp, to convert from simple types and user types to String and other Lucene - specific formats
17:57:45 <sannegrinovero> especially the user types conversion is - of course - customizable, so people will provide those classes and potentially need other utilities or services
17:57:51 <emmanuel> So the idea would be to have a "custom" ObjectFactory that could ask CDI for it (ie giveMeBeanOfType(StringBridge.class) and otherwise use the no-arg
17:58:36 <emmanuel> the problem as usual is that we need to get access to the CDI engine to ask for such object (I forgot the exact CDI API that let you access beans from types)
17:58:41 <lightguard_jp> That's something we've talked about making easier in CDI 1.1 but for now you could use the Instance class
17:59:00 <lightguard_jp> BeanManager or Instance would work
17:59:01 <sannegrinovero> emmanuel, are you implying it would be possible to bundle overrides to the default bridges? (i.e. StringBridge)
17:59:36 <emmanuel> sannegrinovero: I haven't thought about that
18:00:14 <emmanuel> I used StringBridge as an user provided example, let's replace it with TrimmedStringBridge
18:00:32 <sannegrinovero> emmanuel, I didn't think about that, but the way you mentioned it seemed cool, if there's a use case. maybe like overriding the datebridges with your custom calendar stuff.
18:01:29 <emmanuel> we can see that for later, it's not the most useful HSearch feature yet to implement
18:02:17 <emmanuel> lightguard_jp: today in frameworks, how is the BeanManager provided (assuming the framework does not use CDI and thus cannot get BM injected like in an app?
18:02:35 <emmanuel> I imagine JNDI is one way
18:03:54 <emmanuel> sannegrinovero: hardy_ can you think of useful Hibernate search driven events an application could listen to?
18:04:40 <sannegrinovero> emmanuel, not currently. I'd assume this would be an interesting subject when we make the indexing optional.
18:04:53 <sannegrinovero> (I mean per instance optional)
18:05:04 <lightguard_jp> emmanuel: Yeah, JNDI is one
18:05:19 <lightguard_jp> In Solder we have a BeanManagerAware class you can extend
18:05:53 <sannegrinovero> emmanuel, maybe some way to facilitate the Master setup? it will listen to other nodes.
18:06:35 <hardy_> what's about some events around mass indexing?
18:07:19 <hardy_> or manual indexing in general
18:08:42 <emmanuel> sannegrinovero: I'm talking about something that would become a CDI event for the app to consume
18:08:56 <emmanuel> hardy_: good idea, something like index done
18:09:02 <hardy_> right
18:09:23 <sannegrinovero> exception handling in backend?
18:09:28 <emmanuel> lightguard_jp: from beanManager you can generate an event of a given type right?
18:09:34 <emmanuel> sannegrinovero: +1
18:09:43 <emmanuel> these are awesome :)
18:10:05 <lightguard_jp> Yeah
18:10:14 <lightguard_jp> Or you could just @Inject Event<YourType>
18:10:25 <emmanuel> #action explore the idea of providing CDI Hibernate Search events for backend exceptions, mass indexing end of work etc
18:10:39 <lightguard_jp> But if you're only using the BM then you can do BeanManager.fire(EventPayload)
18:11:03 <emmanuel> lightguard_jp: right but Iw as assuming an area where we don't get managed beans from CDI (the framework)
18:11:19 <lightguard_jp> Sorry, fireEvent(Object event, Annotation ... qualifiers)
18:11:33 <emmanuel> sannegrinovero: "* injecting in filters !!" care to clarify?
18:11:50 <sannegrinovero> emmanuel, shall I quote your book :)
18:12:05 <lightguard_jp> If you can get a hold of the BeanManager via JNDI or other you can use it to fire the event.
18:12:22 <sannegrinovero> emmanuel, you mentioned at some point the capability to invoke an external webservice, for something like showing only items in stock
18:12:41 <emmanuel> ah right
18:12:52 <sannegrinovero> always thought that was a great idea, but getting a reference to this webservice isn't really trivial now
18:12:56 <emmanuel> #action let Filter implementations be managed beans like bridges
18:13:22 <emmanuel> So the last one is interesting, declaratively activate filters
18:13:30 <emmanuel> how would that one work?
18:13:44 <emmanuel> Today we activate filters on a per query basis
18:14:06 <sannegrinovero> guess: the security interceptor enables them in the context (a TL?) and they're picked up by the QueryBuilder.
18:14:09 <emmanuel> which does not fit perfectly with a bean lifecycle or a method boundary necessarily
18:15:20 <emmanuel> sannegrinovero: from a CDI PoV that would be an interceptor that would look for a @ActivateFilter(name, params)
18:15:46 <emmanuel> and would keep the context in a TL
18:16:18 <emmanuel> but this interceptor needs a little help from Hibernate Search Query implementation to property apply these filters when the TL context is populated
18:16:29 <lightguard_jp> Making them CDI Interceptors would be the most obvious fit, yes.
18:16:30 <emmanuel> lightguard_jp: would there be a better approach than a TL?
18:16:41 <emmanuel> to keep the contextual info
18:17:06 <lightguard_jp> Could create a scope to keep that stuff in just for the filter
18:17:44 <lightguard_jp> Either TL or a new scope.
18:17:57 <pmuir> lightguard_jp: sorry, missed that, yes you can inject IP into disposer method
18:19:56 <emmanuel> interesting idea a @QueryScope
18:20:07 <emmanuel> I'm not sure how that would work
18:20:19 <emmanuel> the user would ahve to have a component that is query scoped?
18:20:36 <gbadner> sebersole, ping me when convenient...
18:20:42 <sannegrinovero> shouldn't it be tightly coupled to the security stuff?
18:21:00 <emmanuel> but the big problem is that we don't have a nice notion of qhen a query scope starts and ends
18:21:12 <lightguard_jp> emmanuel: Depends on how you implement it. But if you have components in that scope it'll be created when the component is created
18:22:21 <emmanuel> lightguard_jp: sannegrinovero: sanne is right, its not a query scope, its more a @FilterScope whose (multiple) boundaries are the famous interceptor
18:23:03 <sannegrinovero> I'm always very confused by the boundaries of scopes in CDI
18:24:04 <sannegrinovero> so imho the security filter enabled the filter by name, and cleans them up. which instance of the filter (if it's up to date or what else) we leave that to Hibernate Search to deal with.
18:24:21 <lightguard_jp> You could create a scope that's started by the interceptor, but at that point it really isn't much different than a TL
18:25:21 <sannegrinovero> lightguard_jp, does the interceptor not have a scope itself? some instance variables where you can hold this in?
18:25:41 <emmanuel> lightguard_jp: Here is the code I have in mind https://gist.github.com/1049434
18:25:54 <emmanuel> do you think we should have a scope or stick to TLs
18:26:36 <lightguard_jp> sannegrinovero: No, you can keep some state in the interceptor
18:27:17 <emmanuel> lightguard_jp: well but how does Hibernate search have access to the interceptor instance to get that state?
18:27:29 <lightguard_jp> emmanuel: With something like this where there isn't a clear start and end of the scope (and would it be useful to the user?) I think a TL would be better.
18:27:40 <lightguard_jp> emmanuel: Hm
18:27:41 <sannegrinovero> I hate TLs
18:28:06 <emmanuel> lightguard_jp: well the boudaries are clear that's where @Filter is
18:28:44 <emmanuel> all query executed within this bean methods must be filtered
18:28:47 <sannegrinovero> can't we invert the thing ? we said before that filters - as emmanuel just pasted - should be able to inject CDI components, so we could say that "securityFilter" is always enabled, and it will lookup the current permissions to apply some parameters to the filter.
18:28:48 <emmanuel> accordingly
18:29:32 <lightguard_jp> emmanuel: I don't see a way of accessing an interceptor. There's http://docs.jboss.org/cdi/api/1.0/javax/enterprise/inject/spi/Interceptor.html but I have no idea how it's meant to be used
18:29:50 <sannegrinovero> and to have this filter "always enabled", that could be a feature of the managed QueryBuilder only. (so if you inject one, it will have some filters enabled by default)
18:30:12 <lightguard_jp> Well, there is BeanManager.resolveInterceptors
18:31:46 <emmanuel> sannegrinovero: I see your point, though it makes the feature behave weirdly if you happen not to inject your QB
18:31:54 <emmanuel> (weirdly as in not working at all :)
18:32:13 <sannegrinovero> right
18:32:44 <sannegrinovero> emmanuel, adding a feature for which some filters are always enabled by default?
18:32:52 <sannegrinovero> so it would be a configuration time option
18:33:10 <hardy_> guys, gtg. dinner time :-)
18:33:22 <hardy_> emmanuel: can you send the links to the protocal later?
18:33:27 <sannegrinovero> it sounds reasonable to me that to enable security on FTQueries I have to switch them on
18:33:40 <sannegrinovero> hardy_, have a nice dinner :)
18:34:03 <hardy_> thanks :-)
18:34:07 <hardy_> cu
18:34:18 <emmanuel> #action explore further the idea of a declarative fitlter activation / desactivation by annotating managed beans with @Filter and associate @Filter with a CDI interceptor https://gist.github.com/1049434 One possible implementation is to stick the list of activated filters in a thread local context and let Hibernate Search HSQueryImpl read this TL. The implementation details are still a bit unclear
18:35:10 <emmanuel> sannegrinovero: but that's the whole point of @Filter (ie to activate the filter)
18:35:27 <emmanuel> if you ened to activate them twice, forget it :)
18:36:44 <sannegrinovero> emmanuel, no just active them once, globally in the search configuration : "always enable filters: [security, whateverelse]"
18:37:15 <emmanuel> What do you gain?
18:37:33 <emmanuel> well I see your point but that's independent of CDI's integration
18:37:46 <emmanuel> and parameters are a problem
18:38:42 <emmanuel> #action hardy why is FacetManager an SPI?
18:39:26 <emmanuel> #action let Hardy think about useful injections wrt faceting. Maybe it would make sense to wait until after we have annotation driven / programmatic configuration for facet definitions
18:39:34 <sannegrinovero> well I was expecting that then this filter could "find out" via the security filter (in the security example) which parameters need to be applied
18:40:12 <emmanuel> sannegrinovero: from where?
18:40:39 <sannegrinovero> the user filter will have some specialized knowledge about the filters which are surrounding the invocation
18:40:56 <emmanuel> you lost me
18:41:23 <emmanuel> BTW parameters are problem with @Filter as I showed it on gist. In many cases, params are dynamically computed by the application
18:41:31 <emmanuel> like the security level of a user
18:41:43 <emmanuel> so @Filter is not useful in all cases
18:42:40 <sannegrinovero> well if we implement the ability from a filter to inject CDI components, then a globally enabled user-defined filterFACTORY should be able to apply the filter taking the appropriate parameters from the CDI context.
18:43:27 <sannegrinovero> (basically I'm saying the last dot in my list is useless if we provide globally enabled filter factories and allow them to reach for CDI components)
18:45:08 <emmanuel> sannegrinovero: my problem with this approach is that:
18:45:08 <emmanuel> - it only works in CDI, not in the general case
18:45:08 <emmanuel> - the idea of a globally defined filter that is activated or not based on some contextual CDI producer is not easy to grasp to Joe siz pack developer, or is it?
18:46:27 <emmanuel> #info on filters => sannegrinovero approach is to have globally enabled filters that are managed beans and get their activation and parameters injected by CDI (from scoped / qualified providers). This is elegant but does it go too far?
18:46:46 <emmanuel> lightguard_jp: from your CDI PoV is that a common pattern that people are used to in CDI?
18:47:04 <sannegrinovero> emmanuel, you lost me on the CDI producer. I'm just thinking about a simple feature in Search - not needing CDI - to have a specific set of FilterFactories always invoked on all queries. This is implemented /wo CDI but very useful if the factory is able to use CDI to find out the right parameters to apply by injecting them.
18:47:47 <lightguard_jp> emmanuel: A globally enabled interceptor?
18:49:24 <emmanuel> lightguard_jp: no, a framework asking its dynamically built scoped parameters from a few qualified producers that the user has to implement in its application
18:50:10 <sannegrinovero> ok that was my list. Are we getting 4 more lists to discuss :D ?
18:51:03 <lightguard_jp> emmanuel: I don't think it's been done. I know we don't do it in Seam and I don't think the Apache guys have done it with CODI either
18:51:09 <lightguard_jp> I don't see it being a problem though.
18:51:13 <emmanuel> sannegrinovero: I think that's a good enough start. I think we are missing some feature (I forgot to write them down myself) but that can come later :)
18:51:14 <lightguard_jp> Well, no, I take that back
18:51:23 <lightguard_jp> We do it with Seam Persistence to get the EntityManager
18:51:46 <emmanuel> lightguard_jp: fancy showing a code example (from the user PoV)
18:52:16 <lightguard_jp> https://github.com/LightGuard/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/PersistenceProducer.java
18:53:03 <lightguard_jp> They're supplying the unit to use if they have multiple and also the scope they want the EntityManager (ConversationScoped in this case) to be.
18:54:46 <emmanuel> ok
18:54:56 <emmanuel> Guys let's call it a day
18:55:10 <emmanuel> we have had a lot of good ideas and execution paths
18:55:15 <emmanuel> one last thing though
18:55:24 <emmanuel> what's the next action and who will lead that?
18:55:49 <emmanuel> I guess we need to create a hibernate-search-cdi module
18:55:57 <sannegrinovero> emmanuel, you mean implementing it all?
18:55:57 <emmanuel> and start hacking the simple stuff
18:56:05 <lightguard_jp> Do we want to prototype this somewhere and pull it into Seam when we get things a little more solidified?
18:56:15 <emmanuel> sannegrinovero: implementing it all or coordinating so that it does not drop
18:56:27 <emmanuel> lightguard_jp: seam or HSearch proper?
18:56:40 <lightguard_jp> Or even just someone's own github space.
18:56:42 <sannegrinovero> well pmuir is collecting projects, I guess he's lacking Hibernate Search medals on his wall :D
18:56:43 <lightguard_jp> We can move it later
18:57:04 <emmanuel> well moving while keeping history is a bitch
18:57:15 <emmanuel> better find the right home first
18:57:21 <lightguard_jp> GitHub implemented reassigning a repo to a different owner.
18:57:35 <lightguard_jp> But we could create a repo under Seam org
18:57:46 <emmanuel> lightguard_jp: I'm talking about merging in another repo
18:57:59 <emmanuel> I though the Drools guys for example were hosting their CDI integration in drools
18:58:07 <emmanuel> and that was a trend to be followed
18:58:10 <emmanuel> has that changed?
18:58:32 <lightguard_jp> I don't know what the deciding conditions were to have that part of drools and not Seam
18:58:40 <lightguard_jp> afaik it has not
18:59:40 <lightguard_jp> If we want it part of Seam I can create the repo, then we'd just need to add the people who want to push to it
18:59:48 <sannegrinovero> imho it's about deciding if it should bear the Seam brand. Should it? if not, then it should stay in Search.
19:00:02 <lightguard_jp> That makes sense
19:01:00 <emmanuel> lightguard_jp: fancy starting a discussion on seam-dev
19:01:05 <emmanuel> ?
19:01:13 <emmanuel> we will resolve that over this week via email
19:01:52 <lightguard_jp> Yep, will do.
19:02:01 <emmanuel> Regarldess of where it lives, it would be nice to get lightguard_jp coordinating things a bit and delegating work if needed to some HSearch team member if special integrations are needed. Does that sound fair?
19:02:20 <lightguard_jp> Yep
19:02:27 <sannegrinovero> yes
19:02:35 <emmanuel> lightguard_jp: all in all one CDI dude and one HSearch dude need to be together to execute quickly
19:02:37 <emmanuel> cool
19:02:41 <sannegrinovero> I'm ok in helping, not so much in writing the hard code CDI part as I'm not practical with it
19:02:49 <lightguard_jp> As soon as we finish with the meeting I'll send the email to mailing list (so I can include a link to the minutes)
19:03:02 <sannegrinovero> right
19:03:07 <emmanuel> #action lightguard_jp asks on seam-dev where hsearch-cdi should live (brand wise)
19:03:14 <sannegrinovero> actually, this is something cool for contributors too.
19:03:28 <sannegrinovero> Davide might want to help on this.
19:03:39 <lightguard_jp> I'm fine helping with the CDI part, but the HSearch stuff I'm not as familiar with, so I think sannegrinovero and I would be a good team.
19:03:39 <emmanuel> #action lightguard_jp takes the coordinating lead to get thinks started and delegates at will :)
19:03:53 <emmanuel> davide is a good idea
19:04:05 <sannegrinovero> yes he will ping me anyway if something isn't clear
19:04:05 <emmanuel> with sanne or me on backup
19:04:08 <sannegrinovero> sure
19:04:23 <emmanuel> ok let's end this beauty
19:04:26 <emmanuel> #endmeeting