uniform the "Composite" and "Component"
by Strong Liu
for example:
/**
* Models the notion of a component (what JPA calls an Embeddable).
* <p/>
* NOTE : Components are not currently really hierarchical. But that is a feature I want to add.
*
* @author Steve Ebersole
*/
public class Composite extends AbstractAttributeContainer {
org.hibernate.metamodel.spi.domain.TypeNature#COMPONENT
I see lots of places that uses these two
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years, 10 months
OSGI manifests for hibernate-orm
by mailing＠bibbernet.org
Hello,
because I need clean OSGI bundles for Hibernate and especially Envers, I
am working on some patches for the 4.1 branch of hibernate-orm to enable
generation of OSGI compatible jar files.
During the work I have found the following problems, and need some help
and/or feedback. The problems are:
- The package org.hibernate.engine.spi is exported by two jar files,
hibernate-core and hibernate-entitymanager, which is not possible in
OSGI. The Problem is the STYLES map in CascadeStyle in hibernate-core
which prevent that the package in hibernate-entitymanager can be
refactored from org.hibernate.engine.spi to
org.hibernate.ejb.engine.spi, to solve the duplicate export.
I think to fix this problem, the following steps should be done:
- Add a setter method to CascadeStyle to allow subclasses to add
CascadeStyles to the map STYLES
- Refactor the package org.hibernate.engine.spi in hibernate-envers to
org.hibernate.ejb.engine.spi
- Use the setter method to add the new CascadeStyle in EJB3CascadeStyle
- The package org.hibernate.tool.ant is exported by to jars,
hibernate-tools (version: 3.2.0.ga) and hibernate-envers, which is also
a duplicate export problem. The problem is that HibernateToolTask in
hibernate-tools has no getters/setters for configurationTask and thus
hibernate-envers is directly reading/modyifing the property
configurationTask. I think to fix this problem, the following steps
should be done:
- hibernate-tools should add public getters/setters for
configurationTask in class HibernateToolTask
- the package org.hibernate.tool.ant in hibernate-envers should be
refactored to org.hibernate.envers.tool.ant
- the property configurationTask should be accessed sole thru the
getters/setters .
It would be nice if someone could check and comment my planned and
already done changes.
I have already done the CascadeStyle fix, the configurationTask fix is
outstanding because I need to know against which version of
hibernate-tools I should create the fix.
In generally the following tasks are done until now:
- added configuration to gradle scripts to generate the osgi manifests
for all jar files in hibernate-orm (needs maybe some cleanup) - right
now the build files for hibernate-core, hibernate-entitymanager and
hibernate-envers are modified.
- added blueprint.xml to hibernate-entitymanager to announce the
availabillity of a javax.persistence.provider
Next steps:
- add osgi manifests to the other jars of hibernate-orm
- write integration tests with pax exam and karaf 2.2.x
- finish refactoring of hibernate-tools
- add patches for other needed dependencies
(hibernate-commons-annotations and more)
- more testing, more integration tests
Help, reviews and comments are welcome, and if someone has already done
the work or parts, please drop me a note.
Attached find a patch against the branch 4.1 of hibernate-orm.
regards
Martin Neimeier
13 years, 10 months
Re: [hibernate-dev] OSGI manifests for hibernate-orm
by Brett Meyer
Martin makes good points. I'd highly recommend moving this into JIRA.
As frequently as Hibernate gets used within OSGi contexts, following
some basic guidelines would be incredibly helpful.
+1 for enforcing package splits, as well as ensuring the manifests are
generated correctly/automatically for ALL jars. Having to rely on other
communities (Apache ServiceMix, etc.) to produce wrapper-bundles is
obnoxious and inconsistent. It'd be awesome if all Hibernate projects
supported it natively and tested the heck out of it. Automated tests
with Karaf or another OSGi runtime would be great.
Technically, OSGi bundles can get away with exporting the same package,
but dependent manifests must use "require-bundle" and the symbolic name
(rather than "import-package"). However, it's definitely best practice
to avoid "require-bundle" as much as possible. "import-package" reduces
unforeseen symptoms in the dependency tree.
Brett E. Meyer
(the new guy on Hibernate...)
On 08/15/2012 06:12 PM, Steve Ebersole wrote:
> Brett, maybe you could help comment on this overall?
>
>
> -------- Original Message --------
> Subject: [hibernate-dev] OSGI manifests for hibernate-orm
> Date: Thu, 16 Aug 2012 00:08:39 +0200
> From: mailing(a)bibbernet.org <mailing(a)bibbernet.org>
> To: Hibernate hibernate-dev <hibernate-dev(a)lists.jboss.org>
>
>
>
> Hello,
>
> because I need clean OSGI bundles for Hibernate and especially Envers, I
> am working on some patches for the 4.1 branch of hibernate-orm to enable
> generation of OSGI compatible jar files.
>
> During the work I have found the following problems, and need some help
> and/or feedback. The problems are:
>
> - The package org.hibernate.engine.spi is exported by two jar files,
> hibernate-core and hibernate-entitymanager, which is not possible in
> OSGI. The Problem is the STYLES map in CascadeStyle in hibernate-core
> which prevent that the package in hibernate-entitymanager can be
> refactored from org.hibernate.engine.spi to
> org.hibernate.ejb.engine.spi, to solve the duplicate export.
> I think to fix this problem, the following steps should be done:
> - Add a setter method to CascadeStyle to allow subclasses to add
> CascadeStyles to the map STYLES
> - Refactor the package org.hibernate.engine.spi in hibernate-envers to
> org.hibernate.ejb.engine.spi
> - Use the setter method to add the new CascadeStyle in EJB3CascadeStyle
>
> - The package org.hibernate.tool.ant is exported by to jars,
> hibernate-tools (version: 3.2.0.ga) and hibernate-envers, which is also
> a duplicate export problem. The problem is that HibernateToolTask in
> hibernate-tools has no getters/setters for configurationTask and thus
> hibernate-envers is directly reading/modyifing the property
> configurationTask. I think to fix this problem, the following steps
> should be done:
> - hibernate-tools should add public getters/setters for
> configurationTask in class HibernateToolTask
> - the package org.hibernate.tool.ant in hibernate-envers should be
> refactored to org.hibernate.envers.tool.ant
> - the property configurationTask should be accessed sole thru the
> getters/setters .
>
> It would be nice if someone could check and comment my planned and
> already done changes.
>
> I have already done the CascadeStyle fix, the configurationTask fix is
> outstanding because I need to know against which version of
> hibernate-tools I should create the fix.
>
> In generally the following tasks are done until now:
> - added configuration to gradle scripts to generate the osgi manifests
> for all jar files in hibernate-orm (needs maybe some cleanup) - right
> now the build files for hibernate-core, hibernate-entitymanager and
> hibernate-envers are modified.
> - added blueprint.xml to hibernate-entitymanager to announce the
> availabillity of a javax.persistence.provider
>
> Next steps:
> - add osgi manifests to the other jars of hibernate-orm
> - write integration tests with pax exam and karaf 2.2.x
> - finish refactoring of hibernate-tools
> - add patches for other needed dependencies
> (hibernate-commons-annotations and more)
> - more testing, more integration tests
>
> Help, reviews and comments are welcome, and if someone has already done
> the work or parts, please drop me a note.
>
> Attached find a patch against the branch 4.1 of hibernate-orm.
>
> regards
> Martin Neimeier
>
>
>
>
>
>
13 years, 10 months
SchemaManagementTool / Exportable
by Steve Ebersole
The basics of org.hibernate.service.schema.spi.SchemaManagementTool are
essentially done. There is a lot of clean up I want to do after
Configuration is gutted or removed, changing how SchemaExport, etc work
internally.
But one thing I wanted to discuss was to change up how Exportable works.
Today, its really not much different than what we used to do. The
database objects themselves know how to render themselves into SQL
CREATE/DROP/ALTER commands. What I am contemplating is externalizing
this rendering (lets call them ExportableRenderer, thought better names
welcome). This would serve 2 useful purposes:
1) Clean up the Table, Sequence, etc code clutter.
2) Allow plugging in alternate renderings for things. This could be
dialects or users or event custom SchemaManagementTool supplied.
WDYT?
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
infinispan tests
by Strong Liu
I'm seeing lots of infinispan test failures, I guess mostly relate to the jgroups, propbaly an environment issue, wondering anyone has a workaround?
java.lang.IllegalStateException: Cache at address server-15967 had 3 members; expecting 2. Members were (server-64288, server-15967, server-6121)
at org.infinispan.test.TestingUtil.isCacheViewComplete(TestingUtil.java:510)
at org.infinispan.test.TestingUtil.areCacheViewsComplete(TestingUtil.java:427)
at org.infinispan.test.TestingUtil.areCacheViewsComplete(TestingUtil.java:419)
at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:244)
at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:290)
at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:953)
at org.hibernate.test.cache.infinispan.entity.AbstractEntityRegionAccessStrategyTestCase.waitForClusterToForm(AbstractEntityRegionAccessStrategyTestCase.java:117)
at org.hibernate.test.cache.infinispan.entity.AbstractEntityRegionAccessStrategyTestCase.prepareResources(AbstractEntityRegionAccessStrategyTestCase.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:62)
ReadOnlyTestCase.testCacheConfiguration
ReadOnlyTestCase.testEvict
ReadOnlyTestCase.testEvictAll
ReadOnlyTestCase.testGetRegion
ReadOnlyTestCase.testInsert
ReadOnlyTestCase.testPutFromLoad
ReadOnlyTestCase.testPutFromLoadMinimal
ReadOnlyTestCase.testRemove
ReadOnlyTestCase.testRemoveAll
ReadOnlyTestCase.testUpdate
EntityCollectionInvalidationTestCase.testAll
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years, 10 months
Re: [hibernate-dev] Hibernate ignores 'schema' attribute of @SequenceGenerator for Oracle sequences
by Steve Ebersole
Let's keep this on-list, thanks..
I think you are missing the point that
'AvailableSettings.USE_NEW_ID_GENERATOR_MAPPINGS' is a setting that
*you* set. It tells Hibernate which strategy it should use to map JPA
generator annotations to org.hibernate.id.IdentifierGenerator
implementations. So its "always false" because you never set it to
anything else...
@SequenceGenerator maps to either org.hibernate.id.SequenceHiLoGenerator
(when flag is false) or org.hibernate.id.enhanced.SequenceStyleGenerator
(when flag is true). SequenceHiLoGenerator does *not* account for
schema/catalog; SequenceStyleGenerator does. That flag as false is
legacy behavior. Yes we could make SequenceHiLoGenerator (which is
deperecated) properly account for schema/catalog. But you could also
enable to the new generator mappings.
On 08/13/2012 02:23 AM, mutaz kabbashi wrote:
> hi steve
>
> i mean the (USE_NEW_ID_GENERATOR_MAPPINGS) always = false for example
>
> if i create the following entity class
>
> package bugs.HHH_7232;
>
> import javax.persistence.*;
>
> @Entity
> @Table(name = "test", schema = "jaseadm")
>
> @SequenceGenerator(schema="hibernate_bug",
> name="applicantSignupSequence", sequenceName="seq_applicant_signup" )
> public class SeqTest {
> @Id
> @GeneratedValue(generator = "applicantSignupSequence",
> strategy = GenerationType.SEQUENCE)
> private int id;
>
> }
>
> hibernate should use sequence from (hibernate_bug) schema but it
> doesn't because when hibernate checks
> (USE_NEW_ID_GENERATOR_MAPPINGS) consatnt @buildIdGenerator() method
> @org.hibernate.cfg.AnnotationBinder Class using the following variable
> (final boolean useNewGeneratorMappings =
> mappings.useNewGeneratorMappings() ;) which always returns false
>
> below is the body of useNewGeneratorMappings()
> method(a)org.hibernate.cfg.Configuration class
> @SuppressWarnings({ "UnnecessaryUnboxing" })
> public boolean useNewGeneratorMappings() {
> if ( useNewGeneratorMappings == null ) {
> final String booleanName = getConfigurationProperties()
> .getProperty( AvailableSettings.USE_NEW_ID_GENERATOR_MAPPINGS ); //problem
> useNewGeneratorMappings = Boolean.valueOf( booleanName );
> }
> return useNewGeneratorMappings.booleanValue();
> }
>
>
>
>
>
> On Sun, Aug 12, 2012 at 8:15 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
>> Not following what you mean "'use new id generator mappings' is false all
>> the time".
>>
>> On Aug 12, 2012 3:40 AM, "mutaz kabbashi" <mutazhkabbashi(a)gmail.com> wrote:
>>>
>>> hi all
>>>
>>> i am new here and i want to contribute to hibernate so i
>>> started with simple bug (Hibernate ignores 'schema' attribute of
>>> @SequenceGenerator for Oracle sequences HHH-7232)
>>> (https://hibernate.onjira.com/browse/HHH-7232) , after i checked the
>>> code i found out that when hibenate try to parse @SequenceGenerator
>>> annotation of Entity class it checks (USE_NEW_ID_GENERATOR_MAPPINGS )
>>> constatnt @[org.hibernate.cfg.AvailableSettings.java] which will be
>>> false all the time so hibernate will not read the sequence schema .
>>> so what is the best way to solve this problem
>>>
>>>
>>>
>>> - Change USE_NEW_ID_GENERATOR_MAPPINGS value (could make problem
>>> with backward compatibility)
>>>
>>> - create new constant
>>>
>>> - check @sequenceGenerator and get schema name (if schema is present
>>> get schema name else schema name will be null )
>>>
>>> - any suggestion
>>>
>>> thank you
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
Hibernate ignores 'schema' attribute of @SequenceGenerator for Oracle sequences
by mutaz kabbashi
hi all
i am new here and i want to contribute to hibernate so i
started with simple bug (Hibernate ignores 'schema' attribute of
@SequenceGenerator for Oracle sequences HHH-7232)
(https://hibernate.onjira.com/browse/HHH-7232) , after i checked the
code i found out that when hibenate try to parse @SequenceGenerator
annotation of Entity class it checks (USE_NEW_ID_GENERATOR_MAPPINGS )
constatnt @[org.hibernate.cfg.AvailableSettings.java] which will be
false all the time so hibernate will not read the sequence schema .
so what is the best way to solve this problem
- Change USE_NEW_ID_GENERATOR_MAPPINGS value (could make problem
with backward compatibility)
- create new constant
- check @sequenceGenerator and get schema name (if schema is present
get schema name else schema name will be null )
- any suggestion
thank you
13 years, 10 months
btyeman question
by Strong Liu
seeing this failure on our CI a lot, anyone know how to workaround it?
org.hibernate.test.annotations.xml.ejb3.OrmVersion1SupportedTest.testOrm1Support
Failing for the past 1 build (Since #14 )
Took 30 min.
edit description
Error Message
java.lang.Exception: test timed out after 1800000 milliseconds
Stacktrace
java.lang.Exception: test timed out after 1800000 milliseconds
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at org.jboss.byteman.agent.submit.Submit$Comm.readResponse(Submit.java:857)
at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:738)
at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:574)
at org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:348)
at org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:316)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:62)
Standard Output
byteman jar is /home/hudson/.m2/repository/org/jboss/byteman/byteman/1.5.2/byteman-1.5.2.jar
TransformListener() : unexpected exception opening server socket java.net.BindException: Address already in use
Standard Error
java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
at java.net.ServerSocket.bind(ServerSocket.java:328)
at java.net.ServerSocket.bind(ServerSocket.java:286)
at org.jboss.byteman.agent.TransformListener.initialize(TransformListener.java:69)
at org.jboss.byteman.agent.Retransformer.addTransformListener(Retransformer.java:204)
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:597)
at org.jboss.byteman.agent.Main.premain(Main.java:199)
at org.jboss.byteman.agent.Main.agentmain(Main.java:213)
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:597)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:348)
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years, 10 months
Test success may not mean functionality is correct
by Gail Badner
I've seen some cases where tests are passing for functionality that is not yet implemented. In these cases, generated DDL for the new metamodel is incorrect.
For example:
org.hibernate.test.annotations.genericsinheritance.GenericsInheritanceTest
Generated DDL using old metamodel:
create table ChildHierarchy1 (id bigint not null, parent_id bigint, primary key (id))
create table ChildHierarchy22 (id bigint not null, parent_id bigint, primary key (id))
create table ParentHierarchy1 (id bigint not null, primary key (id))
create table ParentHierarchy22 (id bigint not null, primary key (id))
alter table ChildHierarchy1 add constraint FK3D9D8AB8B84C10B6 foreign key (parent_id) references ParentHierarchy1
alter table ChildHierarchy22 add constraint FK7613CC99DB2D4DFB foreign key (parent_id) references ParentHierarchy22
create sequence hibernate_sequence start with 1 increment by 1
Generated DDL using new metamodel:
create table ParentHierarchy1 (id bigint not null, primary key (id))
create table ChildHierarchy1 (id bigint not null, primary key (id))
create table ParentHierarchy22 (id bigint not null, primary key (id))
create table ChildHierarchy22 (id bigint not null, primary key (id))
create sequence hibernate_sequence start with 1 increment by 1
---------------
org.hibernate.test.annotations.onetoone.OptionalOneToOneMappedByTest
Generated DDL using old metamodel:
create table Owner (id integer not null, primary key (id))
create table OwnerAddress (id integer not null, primary key (id))
create table Party (partyId varchar(255) not null, primary key (partyId))
create table PartyAffiliate (partyId varchar(255) not null, affiliateName varchar(255), primary key (partyId))
create table Person (id integer not null, primary key (id))
create table PersonAddress (id integer not null, primary key (id))
Generated DDL using new metamodel:
create table Owner (id integer not null, address integer, primary key (id))
create table OwnerAddress (id integer not null, owner integer, primary key (id))
create table Party (partyId varchar(255) not null, partyAffiliate varchar(255), primary key (partyId))
create table PartyAffiliate (partyId varchar(255) not null, affiliateName varchar(255), party varchar(255), primary key (partyId))
create table Person (id integer not null, personAddress integer, primary key (id))
create table PersonAddress (id integer not null, person integer, primary key (id))
IMO, the DDL generated using the new metamodel should be compared with that generated using the old metamodel to confirm they are consistent. IMO, a good start is to simply use what is generated by the old metamodel as a baseline.
>From what I've seen so far, I can tell that something is wrong just by looking at the DDL. If I see cases where the DDL is correct, but generated SQL is incorrect, then I would also like to see the static SQL generated by the persisters and other queries compared as well.
I understand that there will be new functionality added to the metamodel branch where this comparison will not be possible. If necessary, we can work something out for these cases; for example, creating a baseline after manually verifying the generated DDL and SQL.
There are different ways this could be accomplished. I want to pass this by everyone before digging into how it should be implemented.
WDYT?
Regards,
Gail
13 years, 10 months
