Re: [hibernate-dev] Stride

[Radim Vansa]

Just out of curiosity, when choosing a replacement for HipChat, have you 
considered Zulip?

Infinispan uses that for about a month now and besides being too 
colourful (similar to HipChat) there's been positive feedback, 
especially due to the threading feature.

Radim [trying to lure everyone to the same client]

On 05/18/2018 12:16 AM, Sanne Grinovero wrote:
> On 17 May 2018 at 20:32, Guillaume Smet  wrote:
>> By the way, you say it’s clear we don’t want to stay on HipChat.
>>
>> When did we decide that? I don’t remember a discussion about it.
> I didn't say it was decided, but I think we're working on that since
> Steve asked about it today. To which I agree *because* it seems clear
> to me that we don't want to stay on it - a notion I inferred from
> multiple previous discussions.
>
> Steve pointed out multiple flaws e.g. the native client packaging
> broken on Fedora, to which Atlassian pretty much replied by letting us
> know they won't invest in HipChat as the future is Stride. We can
> choose when to switch but staying doesn't look sensible to me as it
> certainly won't improve; it's also likely that they'll want everyone
> migrated eventually so to shut the existing service down.
>
> I for one gave up as well installing the native client and have been
> using the web client since setting up my new workstation, as I was
> expecting Stride to arrive soon.
>
> The other day some people tried to join and gave up because of login
> complexity - that's IMO a very bad sign: not welcoming community
> people means it's failing its primary requirements.
>
> And let's not forget all authentication nonsense; especially days that
> I'm working more on the WildFly side of things and need to login to
> multiple instances I really look forward to a better system (hopefully
> it is!?).
>
> Question, since you want a decision: are you only suggesting to delay
> or suggesting that you should rather stay on HipChat?
>
> Personally, I'm fine delaying a bit even though I can live happily
> without Jenkins notifications, but let's hear the others as well.
>
> Thanks,
> Sanne
>
>
>> For sure, we probably won’t have a choice because there’s a good chance 
>> Atlassian will close the service but what are the problems that make a 
>> migration so urgent?
>>
>>> Le 17 mai 2018 à 20:16, Sanne Grinovero  a écrit :
>>>
>>> lol, I was writing about the same to the team list.
>>>
>>> +1 to have people register, it's better for them anyway. I checked
>>> it's easier to self-register.
>>>
>>> +1 to migrate quickly. It's clear we don't want to stay on HipChat, if
>>> this doesn't work out we'll see.
>>>
>>> Refer to my parallel email for Fedora instructions.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
 On 17 May 2018 at 19:03, Steve Ebersole  wrote:
 I got an email from Atlassian this morning about the migration from HipChat
 to Stride.  Basically they have not gotten Stride feature-complete in terms
 of HipChat which is the trigger for the mass migration.  However, they are
 reaching out to all waiting teams to see if any want to migrate anyway.
 The list of missing features they sent me are:


1. Guest access
2. Some admin controls and compliance settings
3. Integrations with Atlassian server products (the Jira Server app is
currently in beta and coming soon) and some other popular integrations. 
 See
all available Stride integrations

 
.
4. User management via API
5. Dark mode

 I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
 but not blocker IMO assuming it gets added at some point.

 I think (1) is the only one that is concerning.  Though TBH for myself
 personally, I do not think registering is a big deal.

 Unless I hear otherwise, I plan on asking them to proceed with our
 migration to Stride.
 ___
 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 mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa 
JBoss Performance Team

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

Re: [hibernate-dev] Cache region names are not prefixed in 5.3

[Radim Vansa]

On 05/18/2018 02:54 AM, Gail Badner wrote:
>
>
> On Thu, May 17, 2018 at 5:24 PM, Gail Badner  > wrote:
>
> I see that HHH-11356 removed prefixes from region names used by
> Hibernate.
>
> I also noticed that entity regions are unprefixed and the package
> name is removed.
>
>
> Actually, the package names are being included in the region names. 
> The test I was looking at did not have a package.
>
>
> I've created 2 issues:
> HHH-12599 to add Javadoc to make it clear that region names are
> unprefixed;
> HHH-12598 to add the package onto entity region names.
>
>
> I've rejected HHH-12598.
>
>
> Should I create an ISPN issue for hibernate-infinispan (or
> whatever it's referred to now) to add the prefixes?
>

I take it as confirmed that RegionFactory is supposed to do this. 
Created https://issues.jboss.org/browse/ISPN-9174

R.

>
> On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero
> mailto:sa...@hibernate.org>> wrote:
>
> On 17 May 2018 at 12:09, Radim Vansa  > wrote:
> > I basically agree with Sanne here that having the prefix
> isolated opens
> > space for performance improvements, though if certain call
> is prefixed,
> > RegionFactory can always drop that prefix. The important
> thing is to mention
> > if the region name is prefixed or not in javadocs. I would
> also prefer if
> > *all* region names that RegionFactory is supposed to access
> followed the
> > same strategy (prefixed/not-prefixed).
> >
> > 5.1 included method
> >
> >     QueryResultsRegion buildQueryResultsRegion(String
> regionName, Properties
> > properties)
> >
> > where StandardQueryCache did the prefix for us, the change
> in 5.3 to
> >
> >     QueryResultsRegion buildQueryResultsRegion(String
> regionName,
> > SessionFactoryImplementor sessionFactory)
> >
> > does not indicate that the prefix won't be there and the
> javadoc is missing
> > completely.
> >
> > Also, DomainDataRegionConfig.getRegionName() has no javadoc and
> > RegionFactory does not add the prefix.
> >
> > @Steve could you please amend the javadoc and confirm if RF
> should prefix
> > region names?
> >
> > @Sanne while cache manager per deployment is an obvious way
> to distinguish
> > regions@deployments, CM holds some heavy resources (e.g.
> threads) - so I
> > while we are supposed to scale number of caches up to
> thousands (and we've
> > fixed some problems that arise when you have for example ~3k
> caches), ATM
> > you're not supposed to scale CMs. And I don't think that
> we'll focus in this
> > direction since the bright future lies in microservices :)
>
> Right, good points. It's a possible optimization I'd like to see
> eventually but it's not trivial to get there yet.
>
> Yet assuming a microservices scenario, this does become trivial to
> benefit from: the container knows there's a single deployment, a
> single CM. So no need to isolate them at all, just need to
> possibly
> isolate multiple PUs defined in the same service.
>
> So it will be easy to run hundreds of isolated microservices
> on the
> same physical CPU and kill each other via process contention :P
>
> >
> > Radim
> >
> >
> > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
> >>
> >> On 17 May 2018 at 11:11, Sanne Grinovero
> mailto:sa...@hibernate.org>> wrote:
> >>>
> >>> I think this is the RegionFactory's responsibility, as
> Hibernate ORM
> >>> alone can't know if this is necessary.
> >>>
> >>> Prefixing is one of many options to isolate caches; a
> Cache technology
> >>> might wish to use a different approach by implementing a
> custom
> >>> `org.hibernate.cache.spi.CacheKeysFactory`.
> >>
> >> Hum, I regret how I wrote the above paragraph.
> >>
> >> I actually meant that a Cache technology could implement
> isolation in
> >> many different ways.
> >> Using a custom `CacheKeysFactory` is just an example, there
> are many
> >> other options as well. In fact, I believe a good choice for
> >> application servers would be to have an independent
> CacheManager for
> >> each deployment. Then it can safely inspect the deployment,
> see if
> >> there are multiple Persistence Units using the same caching
> >> technology, and implement further isolation only if necessary.
>   

Re: [hibernate-dev] Cache region names are not prefixed in 5.3

[Radim Vansa]

One thing I've stumbled upon: it seems that RegionFactory should call 
its method qualify(String regionName) to produce the prefixed region 
name. Following Hibernate's implementation I use RegionNameQualifier for 
this, which uses prefix + '.' + regionName.

In previous versions the dot was missing from the qualifier - is this 
something that could break backwards compatibility? E.g. in WF to let 
2LC use specific cache configuration you need to set 
`hibernate.cache.infinispan.deployment#entity.name.cfg` - I wonder if 
the qualified region name becomes deployment#.entity.name now...

Radim

On 05/18/2018 09:02 AM, Radim Vansa wrote:
> On 05/18/2018 02:54 AM, Gail Badner wrote:
>>
>>
>> On Thu, May 17, 2018 at 5:24 PM, Gail Badner > > wrote:
>>
>>     I see that HHH-11356 removed prefixes from region names used by
>>     Hibernate.
>>
>>     I also noticed that entity regions are unprefixed and the package
>>     name is removed.
>>
>>
>> Actually, the package names are being included in the region names. 
>> The test I was looking at did not have a package.
>>
>>
>>     I've created 2 issues:
>>     HHH-12599 to add Javadoc to make it clear that region names are
>>     unprefixed;
>>     HHH-12598 to add the package onto entity region names.
>>
>>
>> I've rejected HHH-12598.
>>
>>
>>     Should I create an ISPN issue for hibernate-infinispan (or
>>     whatever it's referred to now) to add the prefixes?
>>
>
> I take it as confirmed that RegionFactory is supposed to do this. 
> Created https://issues.jboss.org/browse/ISPN-9174
>
> R.
>
>>
>>     On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero
>>     mailto:sa...@hibernate.org>> wrote:
>>
>>     On 17 May 2018 at 12:09, Radim Vansa >     > wrote:
>>     > I basically agree with Sanne here that having the prefix
>>     isolated opens
>>     > space for performance improvements, though if certain call
>>     is prefixed,
>>     > RegionFactory can always drop that prefix. The important
>>     thing is to mention
>>     > if the region name is prefixed or not in javadocs. I would
>>     also prefer if
>>     > *all* region names that RegionFactory is supposed to access
>>     followed the
>>     > same strategy (prefixed/not-prefixed).
>>     >
>>     > 5.1 included method
>>     >
>>     >     QueryResultsRegion buildQueryResultsRegion(String
>>     regionName, Properties
>>     > properties)
>>     >
>>     > where StandardQueryCache did the prefix for us, the change
>>     in 5.3 to
>>     >
>>     >     QueryResultsRegion buildQueryResultsRegion(String
>>     regionName,
>>     > SessionFactoryImplementor sessionFactory)
>>     >
>>     > does not indicate that the prefix won't be there and the
>>     javadoc is missing
>>     > completely.
>>     >
>>     > Also, DomainDataRegionConfig.getRegionName() has no javadoc 
>> and
>>     > RegionFactory does not add the prefix.
>>     >
>>     > @Steve could you please amend the javadoc and confirm if RF
>>     should prefix
>>     > region names?
>>     >
>>     > @Sanne while cache manager per deployment is an obvious way
>>     to distinguish
>>     > regions@deployments, CM holds some heavy resources (e.g.
>>     threads) - so I
>>     > while we are supposed to scale number of caches up to
>>     thousands (and we've
>>     > fixed some problems that arise when you have for example ~3k
>>     caches), ATM
>>     > you're not supposed to scale CMs. And I don't think that
>>     we'll focus in this
>>     > direction since the bright future lies in microservices :)
>>
>>     Right, good points. It's a possible optimization I'd like to see
>>     eventually but it's not trivial to get there yet.
>>
>>     Yet assuming a microservices scenario, this does become 
>> trivial to
>>     benefit from: the container knows there's a single deployment, a
>>     single CM. So no need to isolate them at all, just need to
>>     possibly
>>     isolate multiple PUs defined in the same service.
>>
>>     So it will be easy to run hundreds of isolated microservices
>>     on the
>>     same physical CPU and kill each other via process contention :P
>>
>>     >
>>     > Radim
>>     >
>>     >
>>     > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>>     >>
>>     >> On 17 May 2018 at 11:11, Sanne Grinovero
>>     mailto:sa...@hibernate.org>> wrote:
>>     >>>
>>     >>> I think this is the RegionFactory's responsibility, as
>>     Hibernate ORM
>>     >>> alone can't know if this is necessary.
>>     >>>
>>     >>> Prefixing is one of many options to isolate caches; a
>>     Cache technology
>>     >>> might wish to use a different approach by implementing a
>>     cust

Re: [hibernate-dev] Cache region names are not prefixed in 5.3

[Radim Vansa]

Ignore me, panicked too quickly... the dot is added there in 5.1 as well.

On 05/18/2018 09:37 AM, Radim Vansa wrote:
> One thing I've stumbled upon: it seems that RegionFactory should call 
> its method qualify(String regionName) to produce the prefixed region 
> name. Following Hibernate's implementation I use RegionNameQualifier 
> for this, which uses prefix + '.' + regionName.
>
> In previous versions the dot was missing from the qualifier - is this 
> something that could break backwards compatibility? E.g. in WF to let 
> 2LC use specific cache configuration you need to set 
> `hibernate.cache.infinispan.deployment#entity.name.cfg` - I wonder if 
> the qualified region name becomes deployment#.entity.name now...
>
> Radim
>
> On 05/18/2018 09:02 AM, Radim Vansa wrote:
>> On 05/18/2018 02:54 AM, Gail Badner wrote:
>>>
>>>
>>> On Thu, May 17, 2018 at 5:24 PM, Gail Badner >> > wrote:
>>>
>>>     I see that HHH-11356 removed prefixes from region names used by
>>>     Hibernate.
>>>
>>>     I also noticed that entity regions are unprefixed and the package
>>>     name is removed.
>>>
>>>
>>> Actually, the package names are being included in the region names. 
>>> The test I was looking at did not have a package.
>>>
>>>
>>>     I've created 2 issues:
>>>     HHH-12599 to add Javadoc to make it clear that region names are
>>>     unprefixed;
>>>     HHH-12598 to add the package onto entity region names.
>>>
>>>
>>> I've rejected HHH-12598.
>>>
>>>
>>>     Should I create an ISPN issue for hibernate-infinispan (or
>>>     whatever it's referred to now) to add the prefixes?
>>>
>>
>> I take it as confirmed that RegionFactory is supposed to do this. 
>> Created https://issues.jboss.org/browse/ISPN-9174
>>
>> R.
>>
>>>
>>>     On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero
>>>     mailto:sa...@hibernate.org>> wrote:
>>>
>>>     On 17 May 2018 at 12:09, Radim Vansa >>     > wrote:
>>>     > I basically agree with Sanne here that having the prefix
>>>     isolated opens
>>>     > space for performance improvements, though if certain call
>>>     is prefixed,
>>>     > RegionFactory can always drop that prefix. The important
>>>     thing is to mention
>>>     > if the region name is prefixed or not in javadocs. I would
>>>     also prefer if
>>>     > *all* region names that RegionFactory is supposed to access
>>>     followed the
>>>     > same strategy (prefixed/not-prefixed).
>>>     >
>>>     > 5.1 included method
>>>     >
>>>     >     QueryResultsRegion buildQueryResultsRegion(String
>>>     regionName, Properties
>>>     > properties)
>>>     >
>>>     > where StandardQueryCache did the prefix for us, the change
>>>     in 5.3 to
>>>     >
>>>     >     QueryResultsRegion buildQueryResultsRegion(String
>>>     regionName,
>>>     > SessionFactoryImplementor sessionFactory)
>>>     >
>>>     > does not indicate that the prefix won't be there and the
>>>     javadoc is missing
>>>     > completely.
>>>     >
>>>     > Also, DomainDataRegionConfig.getRegionName() has no 
>>> javadoc and
>>>     > RegionFactory does not add the prefix.
>>>     >
>>>     > @Steve could you please amend the javadoc and confirm if RF
>>>     should prefix
>>>     > region names?
>>>     >
>>>     > @Sanne while cache manager per deployment is an obvious way
>>>     to distinguish
>>>     > regions@deployments, CM holds some heavy resources (e.g.
>>>     threads) - so I
>>>     > while we are supposed to scale number of caches up to
>>>     thousands (and we've
>>>     > fixed some problems that arise when you have for example ~3k
>>>     caches), ATM
>>>     > you're not supposed to scale CMs. And I don't think that
>>>     we'll focus in this
>>>     > direction since the bright future lies in microservices :)
>>>
>>>     Right, good points. It's a possible optimization I'd like to 
>>> see
>>>     eventually but it's not trivial to get there yet.
>>>
>>>     Yet assuming a microservices scenario, this does become 
>>> trivial to
>>>     benefit from: the container knows there's a single 
>>> deployment, a
>>>     single CM. So no need to isolate them at all, just need to
>>>     possibly
>>>     isolate multiple PUs defined in the same service.
>>>
>>>     So it will be easy to run hundreds of isolated microservices
>>>     on the
>>>     same physical CPU and kill each other via process contention :P
>>>
>>>     >
>>>     > Radim
>>>     >
>>>     >
>>>     > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>>>     >>
>>>     >> On 17 May 2018 at 11:11, Sanne Grinovero
>>>     mailto:sa...@hibernate.org>> wrote:
>>>     >>>
>>>     >>> I think this is the RegionFactory's responsibility, as
>>>    

Re: [hibernate-dev] Stride

[Guillaume Smet]

Hi,

On Fri, May 18, 2018 at 12:16 AM, Sanne Grinovero 
wrote:

> Steve pointed out multiple flaws e.g. the native client packaging
> broken on Fedora, to which Atlassian pretty much replied by letting us
> know they won't invest in HipChat as the future is Stride. We can
> choose when to switch but staying doesn't look sensible to me as it
> certainly won't improve; it's also likely that they'll want everyone
> migrated eventually so to shut the existing service down.
>

Well, "multiple flaws" is AFAIK:
1/ the packaging of the native client (well, native is a big word, it's
just a packaged webapp);
2/ the guest access/registration.

For 1/, did someone install the Stride client to be sure it's better?

2/ We don't have any guest access on Stride for now, WDYM by self
registration is better? IMHO, it would be nice to have GitHub/Google
authentication integration. I expect most people won't want to create an
account just to ask a quick question.

And let's not forget all authentication nonsense; especially days that
> I'm working more on the WildFly side of things and need to login to
> multiple instances I really look forward to a better system (hopefully
> it is!?).
>

Will it be better? Shouldn't we coordinate with WildFly to see where they
want to go?

If they don't go with Stride, it won't solve your issue.

The only way to fix this issue is to coordinate with all the projects you
have an interest in and choose the same tool (and check that the tool
allows authentication on several instances at once or has a centralized
instance).

AFAICS from Radim's email, Infinispan has already chosen another tool...


> Question, since you want a decision: are you only suggesting to delay
> or suggesting that you should rather stay on HipChat?
>

I say that we know HipChat sort of works for us as a daily coordination
tool (not talking about discussions with external people). We have no idea
Stride will.

And this recent comment
https://jira.atlassian.com/browse/STRIDE-1973?focusedCommentId=1796169&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1796169
makes me think it's still half baked. It's only one comment but I don't
think there are lots of people already migrated there.

Frankly, the fact that moving to Stride is a one way street and we will
lose our coordination tool if it doesn't work well makes me feel
uncomfortable.


> Personally, I'm fine delaying a bit even though I can live happily
> without Jenkins notifications, but let's hear the others as well.
>

I just want to be able to do my job. That's basically my only requirement.

>From my point of view, it seems like a rushed decision that won't solve the
issues we have, and will potentially create others as we will be migrating
to beta software.

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

Re: [hibernate-dev] Stride

[Steve Ebersole]

You can't "do your job" without yet another way to get notified of CI job
status?  I'm confused - did Jenkins remove all of its other forms of
notification?  ;)  Seriously though,  I've never understood this desire to
have yet another communications "inbox" spammed by automated notifications
- and its even worse in Hip Cat because I can never hide them.  So it is
hard for me to incorporate this into the argument against moving.

Y'all really wanted to move to Hip Chat in the first place even though to
me it always felt (and feels) half-baked itself.  When you have a
communications client that does not even have a working install for the OS
well over half the team using it uses... well, to me that is far bigger
problem than not having a 13th way to see Jenkins notifications ;)  And if
the web client is as good as the native client, I assume you use the web
client instead?

So to me it really comes down to what are the blockers to not making this
move now.  So far I hear:

   1. No Jenkins notifications - see above
   2. Guest access - meh - If having to have an account to join the
   discussion is bad then we should immediately make our forums
   guest-accessible again as well ;)
   3. There may be better options out there - at some point can we just
   pick one and use it?  Is one "inbox" really that much better than another
   "inbox"?  And clearly I am not even tied to Hip Chat - I was one of the
   people wanting to not move there.  Radim, what makes Zulip so amazing?
   4. "Coordination tool"?  Not really sure what this one is about.  Is
   this back to Jenkins notifications?  If you mean a communications tool, of
   course it works.  They are largely the same.  Andrea, Sanne and I have
   played with it, so we in fact do have some idea if it will (spoiler: it
   does)
   5. We should go where WildFly goes (?).

The bottom line is that this is the way Atlassian is going.  Hip Chat is
beyond deprecated - to the point where they won't even fix the smallest of
bugs like the RPM package even though Red Hat employees spent hours doing
all the work for them in terms of investigation and solution.  They
literally just need to add the suggested RPM metadata changes.  But they
wont.  That tells you all you need to know.



On Fri, May 18, 2018 at 4:23 AM Guillaume Smet 
wrote:

> Hi,
>
> On Fri, May 18, 2018 at 12:16 AM, Sanne Grinovero 
> wrote:
>
>> Steve pointed out multiple flaws e.g. the native client packaging
>> broken on Fedora, to which Atlassian pretty much replied by letting us
>> know they won't invest in HipChat as the future is Stride. We can
>> choose when to switch but staying doesn't look sensible to me as it
>> certainly won't improve; it's also likely that they'll want everyone
>> migrated eventually so to shut the existing service down.
>>
>
> Well, "multiple flaws" is AFAIK:
> 1/ the packaging of the native client (well, native is a big word, it's
> just a packaged webapp);
> 2/ the guest access/registration.
>
> For 1/, did someone install the Stride client to be sure it's better?
>
> 2/ We don't have any guest access on Stride for now, WDYM by self
> registration is better? IMHO, it would be nice to have GitHub/Google
> authentication integration. I expect most people won't want to create an
> account just to ask a quick question.
>
> And let's not forget all authentication nonsense; especially days that
>> I'm working more on the WildFly side of things and need to login to
>> multiple instances I really look forward to a better system (hopefully
>> it is!?).
>>
>
> Will it be better? Shouldn't we coordinate with WildFly to see where they
> want to go?
>
> If they don't go with Stride, it won't solve your issue.
>
> The only way to fix this issue is to coordinate with all the projects you
> have an interest in and choose the same tool (and check that the tool
> allows authentication on several instances at once or has a centralized
> instance).
>
> AFAICS from Radim's email, Infinispan has already chosen another tool...
>
>
>> Question, since you want a decision: are you only suggesting to delay
>> or suggesting that you should rather stay on HipChat?
>>
>
> I say that we know HipChat sort of works for us as a daily coordination
> tool (not talking about discussions with external people). We have no idea
> Stride will.
>
> And this recent comment
> https://jira.atlassian.com/browse/STRIDE-1973?focusedCommentId=1796169&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1796169
> makes me think it's still half baked. It's only one comment but I don't
> think there are lots of people already migrated there.
>
> Frankly, the fact that moving to Stride is a one way street and we will
> lose our coordination tool if it doesn't work well makes me feel
> uncomfortable.
>
>
>> Personally, I'm fine delaying a bit even though I can live happily
>> without Jenkins notifications, but let's hear the others as well.
>>
>
> I just want to be able to do my job. That's basicall

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Steve Ebersole]

There could conceivably be multiple MetadataBuilderContributor instances
needing to be integrated.  CDI (and therefore ManagedBeanRegistry) do not
work well in this situation.  MetadataBuilderContributor should be done via
ServiceLoader (via ClassLoaderService)

When I mentioned ManagedBeanRegistry, I was talking specifically about just
contributing functions - but MetadataBuilderContributor is more
generalized, which is fine.. it just won't fit into the CDI paradigm




On Thu, May 17, 2018 at 1:35 PM Vlad Mihalcea 
wrote:

> I named it MetadataBuilderContributor because you can do more than just
> registering SqlFunctions. While implementing it, I realized that, this way,
> it's going to be very flexible to customize the Hibernate-native Metadata
> while doing the JPA bootstrap.
>
> Related to ManagedBeanRegitry, I'm trying to convert to using it, but
> stumbled on this issue.
>
> If I try to get a Bean like this:
>
> managedBeanRegistry.getBean( MetadataBuilderContributor.class );
>
> And there is no BeanContainer set via
> "hibernate.resource.beans.container", then the FallbackContainedBean is
> used, which tries to instantiate the provided interface:
>
> beanType.newInstance();
>
> But since I provide an interface, the call will fail.
>
> The only workaround I found is this:
>
> ManagedBeanRegistry managedBeanRegistry = standardServiceRegistry
> .getService( ManagedBeanRegistry.class );
>
> BeanContainer beanContainer = managedBeanRegistry.getBeanContainer();
>
> ManagedBean
> metadataBuilderContributorManagedBean = null;
> if ( beanContainer != null ) {
> metadataBuilderContributorManagedBean = managedBeanRegistry
> .getBean( MetadataBuilderContributor.class );
> }
>
> MetadataBuilderContributor metadataBuilderContributor =
> metadataBuilderContributorManagedBean
> .getBeanInstance();
>
> Am I using it the wrong way, or do we need to check the BeanContainer
> first to make sure it's not null before getting a Bean from the
> ManagedBeanRegistry?
>
> Vlad
>
>
> On Thu, May 17, 2018 at 9:07 PM, Steve Ebersole 
> wrote:
>
>> Personally I think both a contributor and CDI integration
>> (ManagedBeanRegitry) make sense here.  Btw, the name for the contributor
>> should not be SqlFunctionContributor - it should reflect the ultimate goal
>> here which is SqmFunctionTemplate; I can see SqmFunctionContributor or just
>> FunctionContributor.  This is an example of what I meant about waiting for
>> 6...
>>
>> On Thu, May 17, 2018 at 12:50 PM Vlad Mihalcea 
>> wrote:
>>
>>> Sure thing. I'll try to adapt it to using the Bean registry.
>>>
>>> Vlad
>>>
>>> On Thu, 17 May 2018, 20:07 Chris Cranford,  wrote:
>>>
>>> > I personally agree with Christian, I don't see the use of the
>>> > ManagedBeanRegistry being a problem.  The new interface certainly opens
>>> > the door for a variety of builder settings to be contributed easily and
>>> > using the registry allows for a versatile way to provide that bean,
>>> > whether it be through some CDI/Spring environment or the fallback
>>> > solution where we instantiate it ourselves.  I believe the code as you
>>> > have it can easily be adapted to use the registry by replacing the
>>> > "newInstance()" call with a call into getting the bean from the
>>> > registry.  The registry itself internally should handle getting the
>>> bean
>>> > from the container or returning you a new instance we instantiate
>>> > ourselves.
>>> >
>>> > On 05/17/2018 12:25 PM, Christian Beikov wrote:
>>> > > The functions could be contributed via a CDI/Spring bean which might
>>> not
>>> > > be such a bad idea I think. In a test environment there could be a
>>> > > different contributor active than in production. Of course, this
>>> could
>>> > > also be handled by passing in different configuration property
>>> values,
>>> > > but that's why I was saying I'm not sure about it. Maybe someone else
>>> > > has an idea if using ManagedBeanRegistry might make sense?
>>> > >
>>> > >
>>> > > Mit freundlichen Grüßen,
>>> > >
>>> 
>>> > > *Christian Beikov*
>>> > > Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
>>> > >> Hi,
>>> > >>
>>> > >> Looking at the SessionFactoryImpl class, the only way to provide an
>>> > >> SqlFunction is either via the Dialect or via the
>>> SessionFactoryOptions:
>>> > >> this.sqlFunctionRegistry  =new SQLFunctionRegistry(
>>> > jdbcServices.getJdbcEnvironment().getDialect(),
>>> > options.getCustomSqlFunctionMap() );
>>> > >> I'm not sure if the ManagedBeanRegistry would have helped in this
>>> case
>>> > >> without requiring more code changes.
>>> > >>
>>> > >> Vlad
>>> > >>
>>> > >> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov
>>> > >> mailto:christian.bei...@gmail.com>>
>>> wrote:
>>> > >>
>>> > >> It looks ok to me although I'm not sure if it wouldn't be more
>>> > >> appropriate to instantiate the contributor via
>>> ManagedBeanRegistry.
>>> > >>
>>> > >>
>>> > >> Mit freundlichen Grüßen

Re: [hibernate-dev] Stride

[Scott Marlow]

Does Zulip have a Fedora (native) client that can be installed by Fedora 
dnf tool?

I've been using Zulip in a browser [1] (as I do with hipchat) and it 
seems at least as good as hipchat.

Has anyone looked at the Zulip multiple organization (team) support [2]?

Scott

[1] https://infinispan.zulipchat.com/
[2] https://zulip.readthedocs.io/en/1.7.1/prod-multiple-organizations.html

On 05/18/2018 02:57 AM, Radim Vansa wrote:
> Just out of curiosity, when choosing a replacement for HipChat, have you
> considered Zulip?
> 
> Infinispan uses that for about a month now and besides being too
> colourful (similar to HipChat) there's been positive feedback,
> especially due to the threading feature.
> 
> Radim [trying to lure everyone to the same client]
> 
> On 05/18/2018 12:16 AM, Sanne Grinovero wrote:
>> On 17 May 2018 at 20:32, Guillaume Smet  wrote:
>>> By the way, you say it’s clear we don’t want to stay on HipChat.
>>>
>>> When did we decide that? I don’t remember a discussion about it.
>> I didn't say it was decided, but I think we're working on that since
>> Steve asked about it today. To which I agree *because* it seems clear
>> to me that we don't want to stay on it - a notion I inferred from
>> multiple previous discussions.
>>
>> Steve pointed out multiple flaws e.g. the native client packaging
>> broken on Fedora, to which Atlassian pretty much replied by letting us
>> know they won't invest in HipChat as the future is Stride. We can
>> choose when to switch but staying doesn't look sensible to me as it
>> certainly won't improve; it's also likely that they'll want everyone
>> migrated eventually so to shut the existing service down.
>>
>> I for one gave up as well installing the native client and have been
>> using the web client since setting up my new workstation, as I was
>> expecting Stride to arrive soon.
>>
>> The other day some people tried to join and gave up because of login
>> complexity - that's IMO a very bad sign: not welcoming community
>> people means it's failing its primary requirements.
>>
>> And let's not forget all authentication nonsense; especially days that
>> I'm working more on the WildFly side of things and need to login to
>> multiple instances I really look forward to a better system (hopefully
>> it is!?).
>>
>> Question, since you want a decision: are you only suggesting to delay
>> or suggesting that you should rather stay on HipChat?
>>
>> Personally, I'm fine delaying a bit even though I can live happily
>> without Jenkins notifications, but let's hear the others as well.
>>
>> Thanks,
>> Sanne
>>
>>
>>> For sure, we probably won’t have a choice because there’s a good chance 
>>> Atlassian will close the service but what are the problems that make a 
>>> migration so urgent?
>>>
 Le 17 mai 2018 à 20:16, Sanne Grinovero  a écrit :

 lol, I was writing about the same to the team list.

 +1 to have people register, it's better for them anyway. I checked
 it's easier to self-register.

 +1 to migrate quickly. It's clear we don't want to stay on HipChat, if
 this doesn't work out we'll see.

 Refer to my parallel email for Fedora instructions.

 Thanks,
 Sanne


> On 17 May 2018 at 19:03, Steve Ebersole  wrote:
> I got an email from Atlassian this morning about the migration from 
> HipChat
> to Stride.  Basically they have not gotten Stride feature-complete in 
> terms
> of HipChat which is the trigger for the mass migration.  However, they are
> reaching out to all waiting teams to see if any want to migrate anyway.
> The list of missing features they sent me are:
>
>
> 1. Guest access
> 2. Some admin controls and compliance settings
> 3. Integrations with Atlassian server products (the Jira Server app is
> currently in beta and coming soon) and some other popular 
> integrations. See
> all available Stride integrations
> 
> 
> .
> 4. User management via API
> 5. Dark mode
>
> I am not really sure exactly what is missing WRT (2).  (3) is 
> nice-to-have,
> but not blocker IMO assuming it gets added at some point.
>
> I think (1) is the only one that is concerning.  Though TBH for myself
> personally, I do not think registering is a big deal.
>
> Unless I hear otherwise, I plan on asking them to proceed with our
> migration to Stride.
> ___
> 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] Stride

[Radim Vansa]

On 05/18/2018 03:56 PM, Scott Marlow wrote:
> Does Zulip have a Fedora (native) client that can be installed by 
> Fedora dnf tool?

No, they don't have RPM, I use the provided AppImage. Yes, nuisance 
(updates are not automatic). Issue [1] from 2015 looks stale.

htop tells me that it's consuming 114 MB of RES memory and 12% CPU (!) 
when idle, though - I was hoping for better.

[1] https://github.com/zulip/zulip/issues/41

> I've been using Zulip in a browser [1] (as I do with hipchat) and it 
> seems at least as good as hipchat.
>
> Has anyone looked at the Zulip multiple organization (team) support [2]?

Client supporting multiple organizations was among the key requirements; 
noone likes the situation around isolated WF & Hibernate HipChats.

R.

>
> Scott
>
> [1] https://infinispan.zulipchat.com/
> [2] 
> https://zulip.readthedocs.io/en/1.7.1/prod-multiple-organizations.html
>
> On 05/18/2018 02:57 AM, Radim Vansa wrote:
>> Just out of curiosity, when choosing a replacement for HipChat, have you
>> considered Zulip?
>>
>> Infinispan uses that for about a month now and besides being too
>> colourful (similar to HipChat) there's been positive feedback,
>> especially due to the threading feature.
>>
>> Radim [trying to lure everyone to the same client]
>>
>> On 05/18/2018 12:16 AM, Sanne Grinovero wrote:
>>> On 17 May 2018 at 20:32, Guillaume Smet  
>>> wrote:
 By the way, you say it’s clear we don’t want to stay on HipChat.

 When did we decide that? I don’t remember a discussion about it.
>>> I didn't say it was decided, but I think we're working on that since
>>> Steve asked about it today. To which I agree *because* it seems clear
>>> to me that we don't want to stay on it - a notion I inferred from
>>> multiple previous discussions.
>>>
>>> Steve pointed out multiple flaws e.g. the native client packaging
>>> broken on Fedora, to which Atlassian pretty much replied by letting us
>>> know they won't invest in HipChat as the future is Stride. We can
>>> choose when to switch but staying doesn't look sensible to me as it
>>> certainly won't improve; it's also likely that they'll want everyone
>>> migrated eventually so to shut the existing service down.
>>>
>>> I for one gave up as well installing the native client and have been
>>> using the web client since setting up my new workstation, as I was
>>> expecting Stride to arrive soon.
>>>
>>> The other day some people tried to join and gave up because of login
>>> complexity - that's IMO a very bad sign: not welcoming community
>>> people means it's failing its primary requirements.
>>>
>>> And let's not forget all authentication nonsense; especially days that
>>> I'm working more on the WildFly side of things and need to login to
>>> multiple instances I really look forward to a better system (hopefully
>>> it is!?).
>>>
>>> Question, since you want a decision: are you only suggesting to delay
>>> or suggesting that you should rather stay on HipChat?
>>>
>>> Personally, I'm fine delaying a bit even though I can live happily
>>> without Jenkins notifications, but let's hear the others as well.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
 For sure, we probably won’t have a choice because there’s a good 
 chance Atlassian will close the service but what are the problems 
 that make a migration so urgent?

> Le 17 mai 2018 à 20:16, Sanne Grinovero  a 
> écrit :
>
> lol, I was writing about the same to the team list.
>
> +1 to have people register, it's better for them anyway. I checked
> it's easier to self-register.
>
> +1 to migrate quickly. It's clear we don't want to stay on 
> HipChat, if
> this doesn't work out we'll see.
>
> Refer to my parallel email for Fedora instructions.
>
> Thanks,
> Sanne
>
>
>> On 17 May 2018 at 19:03, Steve Ebersole  wrote:
>> I got an email from Atlassian this morning about the migration 
>> from HipChat
>> to Stride.  Basically they have not gotten Stride 
>> feature-complete in terms
>> of HipChat which is the trigger for the mass migration. However, 
>> they are
>> reaching out to all waiting teams to see if any want to migrate 
>> anyway.
>> The list of missing features they sent me are:
>>
>>
>>     1. Guest access
>>     2. Some admin controls and compliance settings
>>     3. Integrations with Atlassian server products (the Jira 
>> Server app is
>>     currently in beta and coming soon) and some other popular 
>> integrations. See
>>     all available Stride integrations
>> 
>>     .
>>     4. User management via API
>>     5. Dark mode
>>
>> I am not really sure exactly what is missing WRT (2). (3) is 
>> nice-to-have,
>> but not blocker IMO assuming it gets added at s

[hibernate-dev] Is bytecode enhancement enabled by default in 5.3?

[Gail Badner]

I don't think it is, just need to confirm.

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

Re: [hibernate-dev] Is bytecode enhancement enabled by default in 5.3?

[Luis Barreiro]

I don't get your question.

Hibernate does not enhance the entities by itself, you have to 
explicitly use one of the build tool plugins (maven, gradle, ant) to 
perform that step.

Even then, the plugins have all the features disabled by default.

The support for enhanced entities in hibernate is not something you can 
enable or disable.

The only thing configurable is the bytecode provider, and that is 
something that has indeed changed for 5.3. AFAICT the generated bytecode 
should be identical.

Luis Barreiro

Middleware Performance Team



On 05/18/2018 08:38 PM, Gail Badner wrote:
> I don't think it is, just need to confirm.
>
> Thanks,
> Gail
> ___
> 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