In discussing the new metamodel, John and I came to a discussion of
entity modes and how to represent them which invariably leads to a
discussion of how to handle them in the runtime apis. We initially
threw the current set up together in a rush to be quite honest and just
assumed a better design
On Thu, 09 Sep 2010 15:17:51 +0200, Sanne Grinovero
wrote:
> So we still load the class, and also try to invoke it's default
> constructor, but if we fail we try loading the alternative.
Ok, and that implies that we actually rename the "alternative"
implementations.
I guess this could work a
2010/9/9 Emmanuel Bernard :
> Can't do that easily. The VM won't load your annotation so you will have to
> read the .class file.
you don't have to remove Solr from the classpath; actually we might
reuse all implementations which don't need to be fixed, overriding
only what is needed.
So we still
Right, I see where you are coming from, but I still think it is
problematic.
Yes we instantiate the factory somewhere in SolrAnalyzerBuilder, but my
point is
that because the Solr class is referenced in my entity, it also has to be
on the classpath.
If the main class loader cannot find
org
Can't do that easily. The VM won't load your annotation so you will have to
read the .class file.
On 9 sept. 2010, at 15:00, Sanne Grinovero wrote:
> What I mean is that when you read the annotation having
> @TokenizerDef(factory =
> org.apache.solr.analysis.StandardTokenizerFactory.class)
>
>
absolutely, that's why I'm proposing to try loading what the user said
first, and only in case of failure try our patched version.
So the day Solr will have an updated package, our mad loading logic
will become harmless as I suppose the loading will work fine at first
try, and you'll get the nice S
What I mean is that when you read the annotation having
@TokenizerDef(factory = org.apache.solr.analysis.StandardTokenizerFactory.class)
you could try starting it, but if it doesn't work you do
factory.getName().replace("org.apache.solr",
"org.hibernate.search.analysis")
and then use the new one l
On Thu, 09 Sep 2010 14:07:57 +0200, Gustavo Fernandes
wrote:
> I agree with Sanne regarding the hiding of Solr framework behind an
> adaptor or whatever, even better if it'd possible to provide Solr
> integration
FYI, we are talking about these classes:
ArabicLetterTokenizerFactory
Arabic
On Thu, 09 Sep 2010 12:45:35 +0200, Sanne Grinovero
wrote:
> So if the Solr packages are renamed, I'd do it once and for all,
> pointing to delegators we could fix in case of need, or as we do
> control the class loading ourself, we could "translate" the requested
> package name to the new one?
I agree with Sanne regarding the hiding of Solr framework behind an adaptor or
whatever, even better if it'd possible to provide Solr integration
as a separate module in HS (ex. hibernate-search-analyzers.jar), so that if
someone wants it, just add the right jar, and Solr analyzers won't prevent
it's not clear to me what was decided, but *if* you decide to change
the packages, backwards compatibility will be broken anyway, so this
raises the doubt if we could just avoid supporting these analyzers at
the moment.
So if you choose for renaming the packages, it should be done in some
way to p
On 8 sept. 2010, at 18:23, Steve Ebersole wrote:
> On Wed, 2010-09-08 at 18:05 +0200, Emmanuel Bernard wrote:
>> On 8 sept. 2010, at 10:35, Hardy Ferentschik wrote:
>>
>>> - So far I haven't renamed any package names. This has the advantage our
>>> existing users don't have to change their cod
On 9 sept. 2010, at 09:25, Hardy Ferentschik wrote:
> On Wed, 08 Sep 2010 18:05:12 +0200, Emmanuel Bernard
> wrote:
>
>
>>> - If we release hibernate-search-solr-analyzers, should we really make it
>>> obsolete once Lucene 3.1 is out or keep this module as sort of buffer?
>>
>> I'm inclined
On Wed, 08 Sep 2010 18:05:12 +0200, Emmanuel Bernard
wrote:
>> - If we release hibernate-search-solr-analyzers, should we really make
>> it
>> obsolete once Lucene 3.1 is out or keep this module as sort of buffer?
>
> I'm inclined to the buffer approach.
But what does buffer mean in this ca
Validator had also problems with different versions of JAXB between Java 5
and 6.
A solution could be to explicitly define a JAXB dependency with provided
scope.
I commented on the blog as well.
--Hardy
On Wed, 08 Sep 2010 23:07:06 +0200, Steve Ebersole
wrote:
> Would love some feedback
15 matches
Mail list logo
