Huge patch for Search
by Sanne Grinovero
Hello,
I've prepared a patch for HSEARCH-458, there's nothing critically
complex inside but it's more than 3000 lines of tedious work.
It patches almost nothing in main, nearly all classes in test.
It changes the way we use Lucene's API, for each deprecated method
I've rewritten it to use the new API,
so the immediate effect will be to only reduce some warnings, but this
is going to be a requirement when switching to Lucene 3.x
(Lucene 2.9 deprecated the APIs, 3.x removed them)
ok for commit?
If you need to take a look inside, I've attached the patch to JIRA.
This is not about upgrading to Lucene3: it's still compatible with
2.9, but will make upgrade easier later.
Regards,
Sanne
16 years
Fwd: Search build failure
by Sanne Grinovero
Hi Hardy,
sorry I forgot to CC the list; yes you're confirming the same issue I
was thinking of:
---------- Forwarded message ----------
From: Sanne Grinovero <sanne.grinovero(a)gmail.com>
Date: 2010/2/6
Subject: Re: [hibernate-dev]Search build failure
To: Amin Mohammed-Coleman <aminmc(a)gmail.com>
Hi Amin,
this line is wrong:
No versions are present in the repository for the artifact with a
range (1.1,2.0)
org.eclipse.wst.css:core:jar:null
the "null" shouldn't be there; this is most likely due to a corrupt
pom definition of "5) org.richfaces.docs:highlight:jar:3.1.4.GA"
(the last on the dependency tree, which depends on org.eclipse stuf).
Delete that one from you local repository cache, so it should download
it again, hopefully a fixed version.
(it's working here)
Sanne
2010/2/6 Amin Mohammed-Coleman <aminmc(a)gmail.com>:
> Hi Sanne
>
> I've just updated HSearch and trying to build via maven and intellij and i'm getting the following:
>
> INFO] Scanning for projects...
> [INFO] artifact org.eclipse.wst.css:core: checking for updates from jboss-plugins
> [INFO] artifact org.eclipse.wst.css:core: checking for updates from jboss-snapshot-plugins
> [INFO] artifact org.eclipse.wst.css:core: checking for updates from jboss
> [INFO] artifact org.eclipse.wst.css:core: checking for updates from jboss-snapshot
> [INFO] artifact org.eclipse.wst.css:core: checking for updates from repository.jboss.com
> [INFO] artifact org.eclipse.wst.css:core: checking for updates from maven-repository.dev.java.net
> [INFO] artifact org.eclipse.wst.css:core: checking for updates from central
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> No versions are present in the repository for the artifact with a range (1.1,2.0)
> org.eclipse.wst.css:core:jar:null
>
> from the specified remote repositories:
> jboss-snapshot (http://snapshots.jboss.org/maven2),
> repository.jboss.com (http://repository.jboss.com/maven2/),
> jboss-snapshot-plugins (http://snapshots.jboss.org/maven2),
> central (http://repo1.maven.org/maven2),
> maven2-snapshots.jboss.org (http://snapshots.jboss.org/maven2),
> jboss-plugins (http://repository.jboss.com/maven2),
> maven-repository.dev.java.net (http://download.java.net/maven/1),
> jboss (http://repository.jboss.com/maven2)
>
> Path to dependency:
> 1) org.jboss.maven.plugins:maven-jdocbook-plugin:maven-plugin:2.2.0
> 2) org.hibernate:hibernate-jdocbook-style:jdocbook-style:2.0.0
> 3) org.jboss:jbossorg-docbook-xslt:jar:1.1.0
> 4) org.jboss.docs:highlight:jar:1.0.0
> 5) org.richfaces.docs:highlight:jar:3.1.4.GA
>
>
>
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Sat Feb 06 08:17:24 GMT 2010
> [INFO] Final Memory: 5M/79M
> [INFO] ------------------------------------------------------------------------
>
>
> I'll have a close look, obviously I've got a config wrong.
>
> Cheers
> Amin
>
> On 6 Feb 2010, at 08:10, Sanne Grinovero wrote:
>
>> Hi Amin,
>> according to head it shouldn't be needed to build core, as it's
>> currently depending on 3.5.0-Beta-4 :
>>
>> http://fisheye.jboss.org/browse/Hibernate/search/trunk/pom.xml?r1=18574&r...
>>
>> Maybe you just need to update? This change is just two days old.
>>
>> Sanne
>>
>> 2010/2/6 Amin Mohammed-Coleman <aminmc(a)gmail.com>:
>>> Thanks I'll give that a go!
>>>
>>> Cheers
>>>
>>> Amin
>>>
>>>
>>> On 6 Feb 2010, at 07:55, Strong Liu wrote:
>>>
>>>> try add this to your .bashrc (or others if you're not using unix-like os)
>>>>
>>>> export MAVEN_OPTS=-Xmx1024m
>>>>
>>>>
>>>> -------------------------------
>>>> Best Regards,
>>>>
>>>> Strong Liu
>>>>
>>>>
>>>>
>>>> On Feb 6, 2010, at 3:16 PM, Amin Mohammed-Coleman wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> I'm trying to build core and followed the steps mentioned and I'm getting the following exception:
>>>>>
>>>>> Failure executing javac, but could not parse the error:
>>>>>
>>>>>
>>>>> The system is out of resources.
>>>>> Consult the following stack trace for details.
>>>>> java.lang.OutOfMemoryError: Java heap space
>>>>> at com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:385)
>>>>> at com.sun.tools.javac.code.Scope.enter(Scope.java:196)
>>>>> at com.sun.tools.javac.code.Scope.enter(Scope.java:183)
>>>>> at com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:132)
>>>>> at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:509)
>>>>> at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:446)
>>>>> at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:387)
>>>>>
>>>>>
>>>>> I've added the following to the parent pom.xml (after googling around)
>>>>>
>>>>> <plugin>
>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>> <configuration>
>>>>> <source>1.4</source>
>>>>> <target>1.4</target>
>>>>> <argLine>-Xmx512m</argLine>
>>>>> </configuration>
>>>>> </plugin>
>>>>>
>>>>>
>>>>> But still no luck. Any help would be appreciated. I'm working on Hibernate Search and need to build core.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> On 4 Jan 2010, at 10:52, Galder Zamarreno wrote:
>>>>>
>>>>>> If you ever have doubts whether some VM parameters are affecting your
>>>>>> test execution, I think you might be able to add a call to
>>>>>> http://java.sun.com/j2se/1.5.0/jcp/beta1/apidiffs/java/lang/management/Ru...
>>>>>> to see what VM parameters have been passed to your test.
>>>>>>
>>>>>> On 12/21/2009 09:17 PM, Hardy Ferentschik wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> turns out that MAVEN_OPTS does not help in this case at all. The surefire
>>>>>>> plugin per default uses the forkMode 'once', meaning a new JVM gets created
>>>>>>> for running the tests. Command line arguments passed via MAVEN_OPTS only
>>>>>>> apply
>>>>>>> for the JVM running the build.
>>>>>>>
>>>>>>> To increase the heap size for surefire you have to pass the JVM options in
>>>>>>> the plugin configuration. See
>>>>>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4728
>>>>>>>
>>>>>>> I added -Xmx1024 globally in the parent pom of Core. I think that's better
>>>>>>> than
>>>>>>> just adding it to Envers alone.
>>>>>>>
>>>>>>> I have no idea why no-one else has experienced this issue. Might be some
>>>>>>> JVM specific
>>>>>>> thing.
>>>>>>>
>>>>>>> --Hardy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 21 Dec 2009 13:28:46 -0300, Adam Warski<adam(a)warski.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>> -Xmx1024 - that's what I used to have, mainly driven by the fact that
>>>>>>>>> once upon
>>>>>>>>> a time the docbook plugin needed to work.
>>>>>>>>>
>>>>>>>>> Btw, I also have the problem if I just try to run the Envers build.
>>>>>>>> That's very weird. I just ran all tests, a "clean install" took 1m 30s,
>>>>>>>> even with default maven memory settings (so no -Xmx in MAVE_OPTS).
>>>>>>>> I'm using Maven 2.2.0 on Java 1.5.0_19 (32 bit - maybe that's the
>>>>>>>> problem?)
>>>>>>>>
>>>>>>>>> Have you only recently added more tests? I used to be able to build
>>>>>>>>> everything just fine.
>>>>>>>>> Maybe the test suite can be split up? (eg by configuring two instances
>>>>>>>>> of the surefire plugin !?)
>>>>>>>>> In case it the the report generator, maybe there is a way to configure
>>>>>>>>> another generator?
>>>>>>>> Well I add some tests from time to time (basically when I fix a bug ;)
>>>>>>>> ), but nothing dramatical.
>>>>>>>> I'm not too good with maven so I don't really know if it's possible to
>>>>>>>> do a split.
>>>>>>>>
>>>>>>>> Adam
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>
>
16 years
Problems building Core
by Hardy Ferentschik
Hi,
just wondering whether someone could confirm that the reactor build of
Core is broken.
There is a sort of expected failure in
EmbeddedTypeTest.testSingularAttributeAccessByNameFailureExpected
in the entitymanager module. But even after commenting out this test I am
not able to complete the build.
I am having problems with the Envers test suite where I am getting an
OutOfMemoryError:
org.apache.maven.surefire.booter.SurefireExecutionException: Java heap
space; nested exception is java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)
at java.lang.StringBuffer.append(StringBuffer.java:225)
at
org.testng.reporters.SuiteHTMLReporter.generateMethodsChronologically(SuiteHTMLReporter.java:429)
at
org.testng.reporters.SuiteHTMLReporter.generateReport(SuiteHTMLReporter.java:67)
at org.testng.TestNG.generateReports(TestNG.java:735)
at org.testng.TestNG.run(TestNG.java:721)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74)
at
org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
--Hardy
16 years
EMF / EM properties
by Steve Ebersole
There have been a few discussions on IRC about handling getProperties()
& setProperty(..) handling in regards to the EMF and EM. I wanted to
expand this discussion here so that:
1) we get a broader audence/participation;
2) we get a record of the discussion :)
We have to consider 2 axes if you will, the first being the availability
of a particular setting for EM versus EMF and the second being JPA
defined settings versus "vendor specific" settings. For Hibernate, the
vast majority of "vendor specific" settings are available already from
org.hibernate.cfg.Environment; those happen to be EMF/SF specific for
the most part.
We've added others in the new org.hibernate.ejb.AvailableSettings. This
is a mix of JPA defined settings plus some additional
Hibernate-EM-specific settings. I like the idea of
org.hibernate.ejb.AvailableSettings specifically because it consolidates
all the setting names in a single place.
On Friday on IRC Hardy and I began discussing the idea of "Setting"s as
an internal contract that describes how a setting is applied. Take the
case of EM, there we'd have a series of named Settings that are specific
to EM. We described a pretty simplistic interface, something like:
interface EntityManageSetting {
public void apply(SessionImplementor session, Object value);
public Object determineValue(SessionImplementor session);
}
Then the pseudo-code for EM.setProperty becomes:
public void setProperty(String name, Object value) {
final EntityManageSetting setting = getSetting( name );
if ( setting != null ) {
// recognized setting
setting.apply( getSessionImplementor(), value );
}
//else {
// setting was not recognized, ignore per spec
//}
}
The EntityManager impl would then have a set of settings:
private static Map<String name,EntityManageSetting> settingHandlers
= new ConcurrentHashMap<String name,EntityManageSetting>();
static {
settingHandlers.put(
SHARED_CACHE_RETRIEVE_MODE,
new EntityManagerSetting() {
...
}
);
...
}
And something similar for EMF.
One thing I did not see an answer for is how changes to a EMF setting is
supposed to affect an existing EM. Take cache-store-mode; consider:
EntityManagerFactory emf = ...;
emf.setProperty(
"javax.persistence.cache.storeMode",
CacheStoreMode.BYPASS
);
EntityManager em = emf.createEntityManager();
// Now, by spec em should behave as CacheStoreMode.BYPASS because
// the store mode is not overridden on it
.setProperty(
"javax.persistence.cache.storeMode",
CacheStoreMode.USE
);
// Now what cache-store-mode is in effect for the em?
// Intuitively I think CacheStoreMode.BYPASS makes the most sense,
// but the spec does not say one way or the other that I saw.
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org
16 years
Slight change in the way Search is auto-registered by Annotations
by Sanne Grinovero
right it's a separate concern, so I'll change the subject, but it
would still be very nice to change this before the release of
Hiberante Core 3.5
so we can finally remove this Contextholder and cleanup that part.
If you do it later we need to keep it around to be compatible.. but as
you're breaking compatibility now it looks like a good moment to do
this, so that Search 3.2 would be clean and depending on core 3.5
only.
We could also remove all documentation about listeners, as the
hand-configured way would never be needed.
Sanne
2010/2/2 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> That's a separate concern if I understand you correctly.
> If I summarize, you want to be able to tell core to initialize one instance of a listener across a set of events provided the listener implements all the required interfaces.
>
> On 2 févr. 2010, at 00:27, Sanne Grinovero wrote:
>
>> Didn't follow the full discussion, but this looks like a good moment
>> to rise a flag
>> about HSEARCH-314: I'm still not sure if this bug is real or not,
>> but the ContextHolder could now be removed altogether, removing any
>> doubt about memory leaks:
>>
>> as core registers the listener by reflection if Search is found, and
>> this Search will need at least this version of Hibernate, registering
>> the listeners by configuration doesn't make sense anymore.
>> Also older versions of Search aren't compatible (BTW, what about
>> changing the eventlistener name and throw an exception if older
>> incompatible version is found?)
>> If you remove the ContextHolder and make sure the eventlistener is
>> initialized only once it should be fine. Core should just create a
>> single instance of the Search listener for all events, this is already
>> the case afaik.
>>
>> Sanne
>>
>> 2010/2/1 Steve Ebersole <steve(a)hibernate.org>:
>>> For Search afaict as you mentioned listeners will be the touchpoint
>>> here. So it depends on what is accessible to the listeners.
>>>
>>> At some point this just needs to be a best effort.
>>>
>>>
>>> On Mon, 2010-02-01 at 18:42 +0100, Emmanuel Bernard wrote:
>>>> Hardy,
>>>> How would it work for say a DirectoryProvider in Hibernate search (which is a plugin of HSearch which itself is a plugin of Core in a way - listener).
>>>>
>>>> Remember we have the hibernate.search.default.[customproperty] category and the hibernate.search.[indexname].[customproperty] category. What would the the impl of PropertyConsumer#collectConsumedProperties like for Hibernate Search?
>>>>
>>>>
>>>> On 1 févr. 2010, at 16:28, Hardy Ferentschik wrote:
>>>>
>>>>> The pull approach via an additional PropertyConsumer interface works for me.
>>>>> It seems to be a good trade-off. Least invasive while still getting some order
>>>>> into the properties.
>>>>>
>>>>> --Hardy
>>>>>
>>>>>
>>>>> On Mon, 01 Feb 2010 12:14:02 -0300, Steve Ebersole <steve(a)hibernate.org> wrote:
>>>>>
>>>>>> On Mon, 2010-02-01 at 09:49 +0100, Emmanuel Bernard wrote:
>>>>>>> Also "plugins" can make use of the general availability of properties.
>>>>>>> For example Hibernate Search reads everything under hibernate.search (and it's not a limited set of property names). Likewise, HSearch extensions can use whatever property name they want to configure say the custom backend or the directory providers (either custom or even one of the system properties).
>>>>>>
>>>>>> The main use case I was keeping in mind along the way was caching. I know in the JBC and Infinispan integrations they added the ability to read a lot of config information from our properties.
>>>>>>
>>>>>> As long as it is something configured by the Configuration ->
>>>>>> Settings/SessionFactory process or the something is known to
>>>>>> SessionFactory at the end of its init it is workable. For example, I
>>>>>> imagine Validator would be easy to tie in here because of the listeners;
>>>>>> they are known to the SessionFactory. Not so sure about Search, it
>>>>>> registers listeners too so maybe its ok.
>>>>>>
>>>>>> The first question is whether we want a push or pull (from perspective
>>>>>> of the things being configured) model here. For example, would the
>>>>>> ConnectionProvider tell SessionFactory about the properties it consumed
>>>>>> (push)? Or would the SessionFactory ask the ConnectionProvider for that
>>>>>> info (pull)?
>>>>>>
>>>>>> The pull approach has the advantage of being the least trade-off . We
>>>>>> could add an optional interface "PropertyConsumer" that things can
>>>>>> choose to implement. If they do, the method would be something like
>>>>>> "collectConsumedProperties(Map copy)"; they would put all the property
>>>>>> keys/values into the given map.
>>>>>>
>>>>>> Another potential "pull" approach is to not pass around j.u.Properties
>>>>>> into these things to configure themselves, but to instead wrap that in a
>>>>>> class that journals the key/values as they are requested. That is a bit
>>>>>> more invasive though as it would mean changing quite a few contracts,
>>>>>> some of which are implemented by classes outside our control.
>>>>>>
>>>>>> In the "push" strategy, the things configuring themselves somehow push
>>>>>> which properties (key/value) they are consuming. Much like the second
>>>>>> pull-approach, this is pretty invasive because we would need to pass in
>>>>>> the mechanism for these "configurables" to report back which properties
>>>>>> they are consuming. Not to mention its tedious.
>>>>>>
>>>>>> Long term I like the second pull approach. However, I personally think
>>>>>> it is too disruptive in the short term and that we should use the first
>>>>>> pull approach for now.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>
>>> --
>>> Steve Ebersole <steve(a)hibernate.org>
>>> Hibernate.org
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
16 years
subscribe
by Schuler, Peter
Met vriendelijke groet,
Peter Schuler
Ordina ICT J-technologies
tel: +31 (0)30 6637788
mob: +31 (0)6 55788758
e-mail: peter.schuler(a)ordina.nl
Disclaimer
Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Indien u niet de
bedoelde ontvanger bent, wordt u verzocht de afzender te waarschuwen en dit bericht met eventuele bijlagen direct te
verwijderen en/of te vernietigen. Het is niet toegestaan dit bericht en eventuele bijlagen te vermenigvuldigen, door
te sturen, openbaar te maken, op te slaan of op andere wijze te gebruiken. Ordina N.V. en/of haar
groepsmaatschappijen accepteren geen verantwoordelijkheid of aansprakelijkheid voor schade die voortvloeit uit de
inhoud en/of de verzending van dit bericht.
This e-mail and any attachments are confidential and are solely intended for the addressee. If you are not the
intended recipient, please notify the sender and delete and/or destroy this message and any attachments immediately.
It is prohibited to copy, to distribute, to disclose or to use this e-mail and any attachments in any other way.
Ordina N.V. and/or its group companies do not accept any responsibility nor liability for any damage resulting from
the content of and/or the transmission of this message.
16 years
