[hibernate-dev] New CI machine preview
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 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Should static logger classes be avoided
Hi all, I would like to get some feedback regarding https://hibernate.atlassian.net/browse/HV-780 - "Use of static loggers prevent deployment as a shared library". Given that all Hibernate I think all Hibernate projects use static loggers I was wondering what everyone thinks. According to the issue having static loggers makes it hard/impossible to configure the log levels per application in case HV is used as a library. See also https://wiki.apache.org/commons/Logging/StaticLog and https://community.jboss.org/thread/222831?tstart=0 --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Should static logger classes be avoided
I would not avoid static loggers, there are better solutions like making sure the "shared library" is loaded in the right classloader (of the container). AFAIK JBoss Modules do the right thing and BVal would be loaded in its own module, making it reusable without drawbacks. Creating logger instances on demand will use more CPU, keep more memory busy, and just overall bloat the library. Only viable alternative is to remove all logging :D Sanne On 27 March 2013 14:02, Hardy Ferentschik wrote: > Hi all, > > I would like to get some feedback regarding > https://hibernate.atlassian.net/browse/HV-780 - "Use of static loggers > prevent deployment as a shared library". > Given that all Hibernate I think all Hibernate projects use static loggers I > was wondering what everyone thinks. > > According to the issue having static loggers makes it hard/impossible to > configure the log levels per application in case HV is used as a library. > See also https://wiki.apache.org/commons/Logging/StaticLog and > https://community.jboss.org/thread/222831?tstart=0 > > > --Hardy > ___ > 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] Should static logger classes be avoided
On 27 Jan 2013, at 3:10 PM, Sanne Grinovero wrote: > I would not avoid static loggers, there are better solutions like > making sure the "shared library" is loaded in the right classloader > (of the container). ok > AFAIK JBoss Modules do the right thing and BVal would be loaded in its > own module, making it reusable without drawbacks. is that so? So multiple deployed apps can use HV and configure each Validator related log levels? How does JBoss Modules do it? --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Should static logger classes be avoided
On 27 March 2013 14:27, Hardy Ferentschik wrote: > > On 27 Jan 2013, at 3:10 PM, Sanne Grinovero wrote: > >> I would not avoid static loggers, there are better solutions like >> making sure the "shared library" is loaded in the right classloader >> (of the container). > > ok > >> AFAIK JBoss Modules do the right thing and BVal would be loaded in its >> own module, making it reusable without drawbacks. > > is that so? So multiple deployed apps can use HV and configure each Validator > related > log levels? How does JBoss Modules do it? No I don't think they can use different log levels. Is that being requested? > > --Hardy > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] unexpected warn message
seeing this when running test on master
"22:34:30,288 WARN SessionFactoryImpl:1554 - HHH08: JTASessionContext
being used with JDBCTransactionFactory; auto-flush will not operate correctly
with getCurrentSession()
"
in the method of
org.hibernate.internal.SessionFactoryImpl#buildCurrentSessionContext, even
there is no Environment.CURRENT_SESSION_CONTEXT_CLASS property set, it use the
following logic to guess
if ( canAccessTransactionManager() ) {
impl = "jta";
}
and
org.hibernate.engine.transaction.jta.platform.internal.StandardJtaPlatformResolver#resolveJtaPlatform,
if there is any JTA Impl on the classpath, the method usually returns true
canAccessTransactionManager()
-
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] Should static logger classes be avoided
On 27 Jan 2013, at 3:28 PM, Sanne Grinovero wrote: >>> AFAIK JBoss Modules do the right thing and BVal would be loaded in its >>> own module, making it reusable without drawbacks. >> >> is that so? So multiple deployed apps can use HV and configure each >> Validator related >> log levels? How does JBoss Modules do it? > > No I don't think they can use different log levels. Is that being requested? Yes, as far as I understand the whole discussion. I think it is a reasonable request, but of course moving away from static loggers (provided that really fixes the issue) might has bigger negative side effects, for example performance. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New CI machine preview
Good work, what configuration have you applied to apache? I'm asking so that I can apply that to the puppet scripts Davide On Wed, Mar 27, 2013 at 1:51 PM, Sanne Grinovero wrote: > 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 > ___ > 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] New CI machine preview
First delete all files in /etc/apache2/sites-enabled/ then create: /etc/apache2/sites-enabled/default with contents: ServerName ci.hibernate.org ProxyRequests Off http://localhost:8081/*> Order deny,allow Allow from all ProxyPreserveHost on ProxyPass / http://localhost:8081/ ProxyPassReverse / http://localhost:8081/ HTTPD modules to enable (commands to run): a2enmod proxy a2enmod proxy_http In /etc/default/jenkins change these only: HTTP_PORT=8081 PREFIX= (yes this value is empty) Then closed all ports except 80 on the AWS security group. Sanne On 27 March 2013 15:23, Davide D'Alto wrote: > Good work, > what configuration have you applied to apache? I'm asking so that I can > apply that to the puppet scripts > > Davide > > > On Wed, Mar 27, 2013 at 1:51 PM, Sanne Grinovero > wrote: >> >> 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 >> ___ >> 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
