The message was undeliverable due to the following reason(s):
Your message could not be delivered because the destination computer was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most like
I created issue HHH-4643 [1] to expose the audit default schema and
catalog as SQL placeholders. A patch (against trunk) is provided which
is up-to-date with Adam's good work in Envers. I'd appreciate it if
someone could review it. Please direct all feedback to the ticket for
tracking purposes.
[1
Hi,
I definitely see the usefulness of the feature. It's just that constraint
implementors should see clearly, when they are leaving BV spec territory.
How about having the HV annotation processor issue a warning at such
advanced validator type definitions?
Gunnar
2009/12/8 Emmanuel Bernard
Hi Guys
I can take a look at trying to implement something that covers option
3. Also saearchmapping builder uses the getProgrammatic method from
searchconfiguration so it can't be removed unless the use in
searchmapping builder is removed.
Cheers
Amin
Sent from my iPhone
On 8 Dec 2009, a
Well, I am not asking for a preference so much. I was asking for a
solution on how to achieve that :)
Emmanuel
On 8 déc. 09, at 14:11, Hardy Ferentschik wrote:
> I go for 3. I think its nice to not need this additional jar.
>
> --Hardy
>
> On Tue, 08 Dec 2009 08:30:13 -0300, Sanne Grinovero
>
I go for 3. I think its nice to not need this additional jar.
--Hardy
On Tue, 08 Dec 2009 08:30:13 -0300, Sanne Grinovero
wrote:
> Both options 1 and 3 are good for me:
> while it's nice to not need an additional jar, I always use it.
>
> Sanne
>
> 2009/12/8 Emmanuel Bernard :
>> SearchMappin
That was my fault. I am still working on that issue amd just missed a
file in the intermediate commit. I have committed it now.
Sorry
On Mon, 2009-12-07 at 19:57 -0500, Scott Marlow wrote:
> Is anyone else seeing a NPE in idTest (31 other tests failed also)
> during unit testing?
>
> Caused b
Both options 1 and 3 are good for me:
while it's nice to not need an additional jar, I always use it.
Sanne
2009/12/8 Emmanuel Bernard :
> SearchMapping has a dependency on Solr's analyzer package which was
> optional in 3.1. The current configuration design makes mandatory as
> the SearchMapping
Also does it make sense to keep
SearchConfiguration#getProgrammaticMapping now that we have the
property approach?
On 8 déc. 09, at 11:58, Emmanuel Bernard wrote:
> SearchMapping has a dependency on Solr's analyzer package which was
> optional in 3.1. The current configuration design makes ma
SearchMapping has a dependency on Solr's analyzer package which was
optional in 3.1. The current configuration design makes mandatory as
the SearchMapping is now used by the SearchFactoryImpl.
Three solutions:
- make the analyzer optional dependency mandatory
- make SearchMapping reflexive
The problem was not so much to implement the feature (which was
reasonably easy) but to standardize it which was very time consuming.
Every time you add a switch, you divide the usefulness of a tool by
two, so be careful :) It's like the number of mathematic formulas in a
book and its correl
11 matches
Mail list logo
