IdentifierGenerator, which *may* implement PostInsertIdentifierGenerator
by Jochen Wiedmann
Hi,
for some particular project, I'd like to have a custom
IdentifierGenerator, which could be thought of as an extension of the
"native" IdentifierGenerator. Basically, it ought to take the id
generated by the "native" generator, but then do some magic with it,
for example add a prefix. (Yes, I know, don't push me on that, I have
already lost my struggle against a "telling ID".)
Such an IdGenerator is easily implemented: Create a class, which
queries the IdentifierGeneratorFactory for the "native"
IdentifierGenerator and use that. (Works fine.)
The problem is, that the "native" generator is sometimes implementing
PostInsertIdentifierGenerator. Of course, I can have my generator
implement PostInsertIdentifierGenerator as well, but that means that
it will break on systems without a sequence. OTOH, I can remove the
interface, but then it won't work on the other systems.
An alternative might be, to add a new "myNative" term to the
IdentifierGeneratorFactory, but that class neither allows extension
(it's final, for whatever reason) nor does it support extending the
map of builtin types.
Any ideas?
Thanks,
Jochen
--
Germanys national anthem is the most boring in the world - how telling!
14 years, 5 months
hello
by Mail Administrator
The original message was received at Sat, 5 Dec 2009 10:14:35 -0800
from [61.247.182.237]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
14 years, 5 months
BoostStrategy issues
by Emmanuel Bernard
I think the BoostStrategy interface is not right.
You can't adjust the boost strategy according to the field name and I
think that's important (assuming dynamic boosting is used).
We probably should rework it to do
interface BoostStrategy {
void defineBoost(String fieldName, Object value);
}
WDYT?
14 years, 5 months
Re: [hibernate-dev] HSEARCH-429
by Emmanuel Bernard
Hello,
I'll review your patches today hopefully.
I am wondering if using Hg or Git could help you / us and what would
be the impact on the existing architecture.
wrt HSEARCH-429
hibernate.search.mapping_model should be both a Class and a String
(configuration). The code must account for that.
I think the code should not be in SearchConfigurationFromHibernateCore
as it is equally useful for non Hibernate Core usages. It but be next
to the core of Hibernate Search's initialization.
On 4 déc. 09, at 09:36, Amin Mohammed-Coleman wrote:
> Hi
>
> I had a go at using the @Factory and did something like this:
>
> public class SearchMappingFactory {
>
> @Factory
> public SearchMapping build() {
> SearchMapping mapping = new SearchMapping();
> ....build mapping
>
> return mapping;
> }
> }
>
> cfg.getProperties().put( "hibernate.search.mapping_model",
> SearchMappingFactory.class );
>
>
> In SearchConfigurationFromHibernateCore i changed :
>
>
> public SearchMapping getProgrammaticMapping() {
> if (getProperties().get( "hibernate.search.mapping_model" ) ==
> null) {
> return null;
> }
> Class<?> clazz = (Class<?>)
> getProperties().get( "hibernate.search.mapping_model" );
> Method[] methods = clazz.getMethods();
> SearchMapping mapping = null;
> boolean hasFactoryAnn = false;
> int count = 0;
> for (Method method : methods) {
> if (method.isAnnotationPresent(Factory.class)) {
> count++;
> hasFactoryAnn = true;
> if ( !method.isAccessible() ) {
> method.setAccessible( true );
> }
> try {
> Object instance = clazz.newInstance();
> mapping = (SearchMapping) method.invoke(instance, new Object[]
> {});
> } catch (Exception e) {
> throw new SearchException(e);
> }
> }
> }
> if (!hasFactoryAnn) {
> throw new SearchException("No @Factory method defined for
> building programmatic api.");
> }
> if (count > 1) {
> throw new SearchException("Multiple @Factory methods defined.
> Only one factory method required.");
> }
> return mapping;
> }
>
> I was going to create a patch but I've got stuff such as dynamic
> boost and classbridge mapping which would've been included in patch
> and caused mayhem!
>
>
> It's an initial idea...probably has holes i'm sure. I didn't know
> whether to send it to the entire group.
>
>
> Cheers
> Amin
>
>
>
>
> On Thu, Dec 3, 2009 at 9:26 AM, Emmanuel Bernard <emmanuel(a)hibernate.org
> > wrote:
> Sounds good.
> If you go the interface route then fine
> If you go the annotation route, use the existing @Factory annotation
> we have. You can also check the code to see how it's implemented for
> filter.
>
>
> On 2 déc. 09, at 19:29, Sanne Grinovero wrote:
>
> Hi Amin,
> no problem go ahead do some experiments and keep the list informed; to
> get that right we will need some different points of view and
> situations, my case was very situational and would have needed some
> work to integrate :-)
>
> Sanne
>
> 2009/12/2 Amin Mohammed-Coleman <aminmc(a)gmail.com>:
> Hi Sanne
> Apologies again for bothering you but I just found this issue on
> JIRA. I'm
> not sure whether to send an email to the mailing list or add a
> comment on
> JIRA but do you have any objections (unless you have started work on
> it) of
> me having a look at this? I've just finished 2 more mapping classes
> which
> Emmanuel is having a look and i'm finishing teh documentation for
> them.
> I've finished 2 job interviews so I'm free to take a look at
> things. I
> wanted to run this past you first before I made a move or started any
> coding.
>
> Cheers
> Amin
>
>
14 years, 5 months
Delivery reports about your e-mail
by Mail Delivery Subsystem
Dear user of lists.jboss.org,
We have found that your e-mail account was used to send a large amount of junk email during this week.
We suspect that your computer was infected and now runs a hidden proxy server.
We recommend you to follow instruction in order to keep your computer safe.
Virtually yours,
lists.jboss.org user support team.
14 years, 5 months
Re: [hibernate-dev] HSEARCH-429
by Emmanuel Bernard
Sounds good.
If you go the interface route then fine
If you go the annotation route, use the existing @Factory annotation
we have. You can also check the code to see how it's implemented for
filter.
On 2 déc. 09, at 19:29, Sanne Grinovero wrote:
> Hi Amin,
> no problem go ahead do some experiments and keep the list informed; to
> get that right we will need some different points of view and
> situations, my case was very situational and would have needed some
> work to integrate :-)
>
> Sanne
>
> 2009/12/2 Amin Mohammed-Coleman <aminmc(a)gmail.com>:
>> Hi Sanne
>> Apologies again for bothering you but I just found this issue on
>> JIRA. I'm
>> not sure whether to send an email to the mailing list or add a
>> comment on
>> JIRA but do you have any objections (unless you have started work
>> on it) of
>> me having a look at this? I've just finished 2 more mapping classes
>> which
>> Emmanuel is having a look and i'm finishing teh documentation for
>> them.
>> I've finished 2 job interviews so I'm free to take a look at
>> things. I
>> wanted to run this past you first before I made a move or started any
>> coding.
>>
>> Cheers
>> Amin
14 years, 5 months
Trunk failing because of infinispan tests
by Juraci Paixao Krohling
Guys,
As I know there are some Infinispan guys on this list, I'm sending it
here. It seems that Infinispan maven repo used to contain some
"-tests.jar" artifacts, but they weren't published on Nov 30, causing
Hibernate trunk build to fail (look at cache-infinispan/pom.xml).
Question is: should we remove the dependency from
cache-infinispan/pom.xml or will Infinispan guys resume publishing the
"-tests.jar" into their repository?
Path to dependency:
1) org.hibernate:hibernate-infinispan:jar:3.5.0-SNAPSHOT
2) org.infinispan:infinispan-core:test-jar:tests:4.0.0-SNAPSHOT
It tried to download this:
http://snapshots.jboss.org/maven2/org/infinispan/infinispan-core/4.0.0-SN...
- Juca.
14 years, 5 months
Re: [hibernate-dev] Exposing transient/mortality information externally
by Brian Stansberry
Be cautious about exposing cache contents (even just keys) via JMX. If
you do, make it something that people can turn off, without turning off
the basic JMX interface. Reason is the same as in recent discussions
about providing access to the cache itself via JMX. People who deploy a
JMX-enabled cache are not necessarily expecting that any code that can
access the MBean server can also inspect cache contents. For example, a
simple session id string is a likely key, and session ids are
essentially a security token that shouldn't be exposed willy-nilly.
In general, for the Hibernate 2LC use case, IMHO it's better if the
Hibernate statistics API is improved, rather than having people access
the cache directly. How the data is stored in the cache should be an
internal implementation detail that can be changed when needed. That's
part of why your addition of eviction configuration to Hibernate
Configuration properties was so nice.
All that said, if information like
> [Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
> Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
> ...]
is readily available internally, having a mechanism for authorized users
to get at it sounds pretty cool. :-)
On 11/26/2009 03:16 AM, Galder Zamarreno wrote:
> Hi,
>
> Re:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267469#4267469
>
> I think Brian has a good point here. We don't expose any internal
> information wrt each cache entry's expiry/eviction values. Brian has a
> good point that this could guide him in finding out which entries have
> been last been used, how long they've been in memory and how it could
> tweak expiration/eviction accordingly.
>
> If we don't do anything, I think we run the risk of people being forced
> to get hold of the container, looping through it and getting information
> that they need from inspecting internal classes.
>
> So, I'd suggest that we add a JMX method to CacheDelegate called
> something like:
>
> Map<String, Map<String, long>> getTransientAndMortalityInformation().
>
> (I'm open to suggestions to other names. This is the 1st thing that came
> to my mind)
>
> This would return a Map where the key is the toString form of the cache
> key and the value part is a map where individual transient/mortal
> properties are returned. I.e.
>
>
>
> We could event add calculated properties such as 'age' which is current
> - created. This would vary with each call obviously.
>
> As indicated in the forum entry, at least based on this use case, I
> don't see an immediate need to query this type of information given a
> key, although could be potentially useful for other use cases. The
> reason this would not help much right now is because it is Hibernate
> that creates the keys of 2nd level cache (i.e. CacheKey) and these are
> nor meant to be recreated externally, so it'd be hard for external apps
> to get something out of the Infinispan cache directly without going
> through the Hibernate integration layer.
>
> My suggested JMX method could allow for individual transient/mortality
> information to be queried by tools, or other client jmx code. Maybe some
> tools could use that to create a table or something like that which
> could be ordered based on a column? i.e. age. Also, tools or client jmx
> code could convert those longs into whatever they want: seconds,
> minutes...etc
>
> The reason I think JMX is a good candidate here is this is inherently
> monitoring information and it allows us to expose internal information
> via primitives without having to expose internal classes.
>
> Thoughts?
>
> Cheers,
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
14 years, 5 months
Returned mail: see transcript for details
by Returned mail
This message was not delivered due to the following reason:
Your message was not 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 likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message was not delivered within 7 days:
Host 92.215.119.4 is not responding.
The following recipients could not receive this message:
<hibernate-dev(a)lists.jboss.org>
Please reply to postmaster(a)lists.jboss.org
if you feel this message to be in error.
14 years, 5 months
