date:20120810

Re: [hibernate-dev] btyeman question

2012-08-10 Thread Hardy Ferentschik

Hi,

seems you are running into https://issues.jboss.org/browse/BYTEMAN-208
See also -  https://community.jboss.org/thread/200634

We should upgrade the Byteman version. 

--Hardy

On 10 Jan 2012, at 7:32 AM, Strong Liu wrote:

> 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 180 milliseconds
> Stacktrace
> 
> java.lang.Exception: test timed out after 180 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 
> http://about.me/stliu/bio
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] btyeman question

2012-08-10 Thread Hardy Ferentschik

FYI, I created https://hibernate.onjira.com/browse/HHH-7519

--Hardy

On 10 Jan 2012, at 7:32 AM, Strong Liu wrote:

> 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 180 milliseconds
> Stacktrace
> 
> java.lang.Exception: test timed out after 180 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 
> http://about.me/stliu/bio
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] packages

2012-08-10 Thread Steve Ebersole

I am noticing some inconsistencies in packages that i wanted us all to 
talk through.  Mainly what I have seen has related to services and that 
sometimes they are put in o.h.services and sometimes in more "natural" 
packages.  Though, also, I think that some of this boils down to what 
"engine" means as in o.h.engine.

For example, take JDBC-related stuff.  Yes, dealing with JDBC is just a 
lot of code for us.  But we have JDBC related code spread throughout 
multiple packages.

org.hibernate.jdbc - I am not too concerned with as it is somewhat 
special, because it is JDBC related stuff that we expose to the use (API).

But org.hibernate.engine.jdbc and org.hibernate.service.jdbc feel like 
they should be in the same package structure.

Initially I had intended o.h.services to be home for just the code 
related to the registry and service infrastructure, but not home for 
actual services.  Not sure why we got off track with that tbh.  I 
remember initially putting some "essential" services (what eventually 
became bootstrap services) in here because they did not seem to fit 
anywhere else (though we do now interestingly have org.hibernate.boot).

Just wanted to get a discussion started about it...


-- 
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] SchemaManagementTool / Exportable

2012-08-10 Thread Steve Ebersole

What is everyones thoughts on having Exporter contain methods for 
create, drop and alter scenarios versus getting Exporter per each of 
those actions?

interface Exporter {
public String[] sqlCreateStrings(T exportable, Dialect dialect);
public String[] sqlDropStrings(T exportable, Dialect dialect);
public String[] sqlMigrationStrings(T exportable, Dialect dialect);
}

+

Exporter gerTableExporter() {
return ...;
}



versus

interface Exporter {
public String[] sqlExportStrings(T exportable, Dialect dialect);
}

Exporter gerTableExporter(Exporter.Action typeOrExport) {
return ...;
}

I think the first is simpler for our use cases, but I can see how the 
seconds might be simpler for custom ones.

On Fri 10 Aug 2012 01:49:48 AM CDT, Gail Badner wrote:
> +1
>
> - Original Message -
>> From: "Strong Liu" 
>> To: "Steve Ebersole" 
>> Cc: "Hibernate hibernate-dev" 
>> Sent: Thursday, August 9, 2012 9:15:32 PM
>> Subject: Re: [hibernate-dev] SchemaManagementTool / Exportable
>>
>>
>> +1
>>
>> On Aug 10, 2012, at 12:38 AM, Steve Ebersole 
>> wrote:
>>
>>> 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?
>>>
>>> --
>>> st...@hibernate.org
>>> http://hibernate.org
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> -
>> Best Regards,
>>
>> Strong Liu 
>> http://about.me/stliu/bio
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>

--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] SchemaManagementTool / Exportable

2012-08-10 Thread Strong Liu

the first one looks simpler and more clear I think

On Aug 11, 2012, at 12:29 AM, Steve Ebersole  wrote:

> What is everyones thoughts on having Exporter contain methods for create, 
> drop and alter scenarios versus getting Exporter per each of those actions?
> 
> interface Exporter {
>   public String[] sqlCreateStrings(T exportable, Dialect dialect);
>   public String[] sqlDropStrings(T exportable, Dialect dialect);
>   public String[] sqlMigrationStrings(T exportable, Dialect dialect);
> }
> 
> +
> 
> Exporter gerTableExporter() {
>   return ...;
> }
> 
> 
> 
> versus
> 
> interface Exporter {
>   public String[] sqlExportStrings(T exportable, Dialect dialect);
> }
> 
> Exporter gerTableExporter(Exporter.Action typeOrExport) {
>   return ...;
> }
> 
> I think the first is simpler for our use cases, but I can see how the seconds 
> might be simpler for custom ones.
> 
> On Fri 10 Aug 2012 01:49:48 AM CDT, Gail Badner wrote:
>> +1
>> 
>> - Original Message -
>>> From: "Strong Liu" 
>>> To: "Steve Ebersole" 
>>> Cc: "Hibernate hibernate-dev" 
>>> Sent: Thursday, August 9, 2012 9:15:32 PM
>>> Subject: Re: [hibernate-dev] SchemaManagementTool / Exportable
>>> 
>>> 
>>> +1
>>> 
>>> On Aug 10, 2012, at 12:38 AM, Steve Ebersole 
>>> wrote:
>>> 
 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?
 
 --
 st...@hibernate.org
 http://hibernate.org
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> 
>>> -
>>> Best Regards,
>>> 
>>> Strong Liu 
>>> http://about.me/stliu/bio
>>> 
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> 
> 
> --
> st...@hibernate.org
> http://hibernate.org

-
Best Regards,

Strong Liu 
http://about.me/stliu/bio

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] btyeman question

Re: [hibernate-dev] btyeman question

[hibernate-dev] packages

Re: [hibernate-dev] SchemaManagementTool / Exportable

Re: [hibernate-dev] SchemaManagementTool / Exportable

5 matches

Site Navigation

Mail list logo

Footer information