API differences in Hibernate ORM 5.1 vs 5.3
by Gail Badner
Hi,
There were lots of differences in the compatibility report, so as a first
step, I've excluded packages/classes that I considered SPI, internal, or
"grey area". This reduced the the differences to a more manageable amount.
You can see a summary of the incompatibilities along with suggested
mitigation at [1].
The report is attached to [1], along with a zip with instructions for
running the report.
I believe there are some "false positives" in the report, and I have
documented them in the section, "False Positives?".
Feel free to comment on the article.
Thanks,
Gail
[1]
https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilityBetween51...
4 weeks
IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
4 weeks
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
3 months, 1 week
Chat migration - D minus 115 until the death of HipChat
by Yoann Rodiere
Hi,
TL;DR: please vote here if you don't want to end up having to use a chat
tool you don't like: https://doodle.com/poll/h6scc9bsh6a4ymre
HipChat Cloud will stop working on February 15th, 2019 [1]. We need to
choose an alternative before we have our back against the wall, so I'll try
to resurrect the conversation.
As a reminder, Stride is no longer an option: Atlassian cancelled the
project, and encourages users to migrate to Slack.
The discussed options so far were:
- *Moving back to IRC*. Aye: ?; nay: ?
Pros: simple as hell.
Cons: basic as hell; we won't keep the chat history.
- *Migrating to Slack* [6], as suggested by Atlassian [2]. Aye:
Christian B; Nay: ?
Pros: we will keep the chat history (I think).
Cons: not open-source; desktop client consumes a lot of resources.
- *Migrating to Zulip* [3]. Aye: Emmanuel, Yoann. Nay: Guillaume (kind
of).
Pros: Advanced conversation management thanks to the "topics" feature.
Cons: Complex to use because of the "topics" feature; we won't keep the
chat history (1).
- *Migrating to Gitter* [5] (we'll create different rooms, probably).
Aye: ?, Nay: ?
Pros: Users seem to actually go there, so we could have our "live
support" rooms next to our "internal discussion" rooms.
Cons: not open-source; we won't keep the chat history (1).
I created a poll based on the discussion we had on the thread
"[hibernate-dev] Stride". I think everyone had the time to suggest another
option.
Please vote here and now, or remain silent forever ;):
https://doodle.com/poll/h6scc9bsh6a4ymre
I'd suggest the following rules: if there's a single clear winner (a
platform that everyone would be happy with), we'll pick that one. If there
are multiple clear winners, whoever does the migration work will pick
what's easier to set up (taking into account the various integrations).
Otherwise, back to discussing it on this thread...
(1) There seems to be some work in progress on a migration tool from
HipChat to Zulip, but it doesn't seem to be ready yet [4]
[1]
https://www.atlassian.com/partnerships/slack/faq#faq-da2b66a1-53d3-4c4e-a...
[2] https://www.atlassian.com/partnerships/slack/migration
[3] https://hibernate.zulipchat.com/
[4] https://github.com/zulip/zulip/issues/10647
[5] https://gitter.im/hibernate/hibernate-orm
[6] https://slackdemo.com/
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
7 years
Loggers
by Steve Ebersole
Yes, I know no one likes talking about logging. "Its not important", until
it is ;)
TLDR I am considering moving to using "module names" for logger names
instead of Class names even for DEBUG/TRACE logging and see if anyone had
strong arguments to not do this..
Full version---
For some time I have been moving to an approach of defining message
loggers[1] using a single contract per function or "module" - e.g.:
1. the second level caching module uses the dedicated message logger
`ConnectionPoolingLogger`
2. the ManagedBeanRegistry module uses the dedicated message logger
`BeansMessageLogger`
3. etc
Each of these define a dedicate instance instance they can use. E.g.
ConnectionPoolingLogger is defined as:
````
@MessageLogger( projectCode = "HHH" )
@ValidIdRange( min = 10001001, max = 10001500 )
public interface ConnectionPoolingLogger extends BasicLogger {
ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger(
ConnectionPoolingLogger.class,
"org.hibernate.orm.connections.pooling"
);
...
}
````
I won't get into all the whys I do this unless someone cares ;)
But I am contemplating doing the same for basic loggers so I wanted to ask
everyone else's opinion since this means a change in how you'd have to
configure logging for DEBUG/TRACE output. Usually you'd use the Class name
as the logger name and use that to control logging in the back-end (log4j,
etc). If I do this, you'd have to instead use the module name.
There are quite a few reasons I am considering this, including all of the
reasons I did it for message loggers in the first place. If I am
debugging the loading of a collection or an entity, today I'd have to know
all the packages involved (there is no common root name) and list them in
my log4j.properties; that is because the process is ultimately handled by
delegates or helpers in many different packages (`org.hibernate.loader`,
`org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be
nice to just be able to say `org.hibernate.loading` or
`org.hibernate.loading.entity` or `org.hibernate.loading.collection` or ...
for a number of reasons:
1. When we need to see logging from someone it is a lot easier to tell
the module name(s) you need enabled as opposed a list of package and class
names.
2. When running JPA TCK it is essentially impossible to attach debugger
to step through code when debugging a failure - you have to rely on
debugging through output. *Well that used to be the case, but the
latest TCK broke logging to STDOUT somehow so we ended up having to try and
reproduce the failure in our testsuite - so then it does not matter either
way ;)*
3. Easier to document -
http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Loggi...
Thoughts?
[1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which
we use for user-focused log messages. Should always be logged at >= INFO
[2]
[3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for
developer-focused log messages (for debugging). Should always be logged at
DEBUG or TRACE
7 years
inSession / inTransaction
by Steve Ebersole
In tests we find our `#inSession` and `#inTransaction` methods very
useful. Which got me thinking that maybe we should support these on
SessionFactory directly:
public interface SessionFactory ... {
...
void inSession(Consumer<Session> action);
void inTransaction(Consumer<Session> action);
void inTransaction(Session session, Consumer<Session> action);
}
and maybe even:
public interface Session ... {
void inTransaction(Consumer<Session> action);
}
Objections?
7 years, 1 month
Re: [hibernate-dev] ORM 5 -> 6 first merge meeting
by Guillaume Smet
Hi Vlad,
Not sure if it's better to partially push the commits or to have them in a
list to deal with later (tests + commit).
What do the others think about it?
On Wed, Dec 19, 2018 at 6:37 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> I have merged some PRs and have some commits still left to integrate into
> 6. Indeed that some if them cannot be fully integrated because they rely on
> non-implemented functionality. But I'll add the tests in the pending tests
> folder.
>
> Vlad
>
> On Wed, 19 Dec 2018, 18:19 Guillaume Smet <guillaume.smet(a)gmail.com wrote:
>
>> Hi,
>>
>> We had the first 5 -> 6 merge meeting with Chris yesterday. We
>> cherry-picked all the simple things but there were a few more problematic
>> things:
>> - things that needs to be ported soon but weren't a simple cherry-pick
>> - things that cannot be ported right now because not yet available in 6
>>
>> We decided to push a document in the 6 tree containing the status so that
>> we have proper versioning:
>> https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc
>>
>> Andrea, Chris and Vlad each have one issue affected. Maybe let's try to
>> target the next meeting as the limit for merging them (or push them to
>> kept
>> for later), probably January 8th-9th.
>>
>> When you're done with a merge, please remove the related content from the
>> document so that we can keep track of things.
>>
>> Thanks.
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
7 years, 1 month
Re: [hibernate-dev] ORM 5 -> 6 first merge meeting
by Guillaume Smet
Well, I don't think adding the test without the fix is the right thing to
do.
When we will try to make this test work, we will have totally forgotten
that there's a fix needed for that.
That's why I listed the commits we couldn't merge for now as we will have
to merge them later, once the feature has been implemented. And if you
merge the tests and the fix at once, at least you know what you're doing.
On Wed, Dec 19, 2018 at 7:21 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> We need the tests to be available to know whether 6.0 has regressions than
> 5.x. Therefore, all the pending tests become the list of tasks to be
> integrated.
>
> Vlad
>
> On Wed, 19 Dec 2018, 19:40 Guillaume Smet <guillaume.smet(a)gmail.com wrote:
>
>> Hi Vlad,
>>
>> Not sure if it's better to partially push the commits or to have them in
>> a list to deal with later (tests + commit).
>>
>> What do the others think about it?
>>
>> On Wed, Dec 19, 2018 at 6:37 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>> wrote:
>>
>>> I have merged some PRs and have some commits still left to integrate
>>> into 6. Indeed that some if them cannot be fully integrated because they
>>> rely on non-implemented functionality. But I'll add the tests in the
>>> pending tests folder.
>>>
>>> Vlad
>>>
>>> On Wed, 19 Dec 2018, 18:19 Guillaume Smet <guillaume.smet(a)gmail.com
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> We had the first 5 -> 6 merge meeting with Chris yesterday. We
>>>> cherry-picked all the simple things but there were a few more
>>>> problematic
>>>> things:
>>>> - things that needs to be ported soon but weren't a simple cherry-pick
>>>> - things that cannot be ported right now because not yet available in 6
>>>>
>>>> We decided to push a document in the 6 tree containing the status so
>>>> that
>>>> we have proper versioning:
>>>>
>>>> https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc
>>>>
>>>> Andrea, Chris and Vlad each have one issue affected. Maybe let's try to
>>>> target the next meeting as the limit for merging them (or push them to
>>>> kept
>>>> for later), probably January 8th-9th.
>>>>
>>>> When you're done with a merge, please remove the related content from
>>>> the
>>>> document so that we can keep track of things.
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Guillaume
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
7 years, 1 month
