[jBPM Development] New message: "Disabling Hibernate logs"
by Sakthivelmurugan K G
JBoss development,
A new message was posted in the thread "Disabling Hibernate logs":
http://community.jboss.org/message/523602#523602
Author : Sakthivelmurugan K G
Profile : http://community.jboss.org/people/kgsakthivel
Message:
--------------------------------------------------------------
Hi,
I am not sure is this the correct forum to ask this question. I am using JBPM 3.2.3.(which comes with built in hibernate 3). I have so many logs which are related to Hibernate like the one below. How to disable this? I am not using log4j.properties. It is very strange to me. Please can anyone help me on this.
010-02-02 15:37:34,735 [Thread-37] INFO org.hibernate.connection.DriverManagerConnectionProvider - autocommit mode: false
2010-02-02 15:37:34,735 [Thread-37] INFO org.hibernate.connection.DriverManagerConnectionProvider - using driver: com.mysq
l.jdbc.Driver at URL: jdbc:mysql://localhost/JBPM
2010-02-02 15:37:34,735 [Thread-37] INFO org.hibernate.connection.DriverManagerConnectionProvider - connection properties:
{user=cygnet, password=cygnet}
2010-02-02 15:37:34,753 [Thread-44] INFO org.apache.struts.util.PropertyMessageResources - Initializing, config='org.apach
e.struts.action.ActionResources', returnNull=true
2010-02-02 15:37:34,819 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - RDBMS: MySQL, version: 5.0.45-community
2010-02-02 15:37:34,819 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - JDBC driver: MySQL-AB JDBC Driver, version: m
ysql-connector-java-3.1.6 ( $Date: 2004/12/09 15:57:25 $, $Revision: 1.27.4.52 $ )
2010-02-02 15:37:34,909 [Thread-37] INFO org.hibernate.dialect.Dialect - Using dialect: org.hibernate.dialect.MySQLDialect
2010-02-02 15:37:34,920 [Thread-37] INFO org.hibernate.transaction.TransactionFactoryFactory - Using default transaction s
trategy (direct JDBC transactions)
2010-02-02 15:37:34,924 [Thread-37] INFO org.hibernate.transaction.TransactionManagerLookupFactory - No TransactionManager
Lookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
2010-02-02 15:37:34,924 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Automatic flush during beforeCompletion(): di
sabled
2010-02-02 15:37:34,924 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Automatic session close at end of transaction
: disabled
2010-02-02 15:37:34,924 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - JDBC batch size: 15
2010-02-02 15:37:34,924 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - JDBC batch updates for versioned data: disabl
ed
2010-02-02 15:37:34,942 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Scrollable result sets: enabled
2010-02-02 15:37:34,942 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - JDBC3 getGeneratedKeys(): enabled
2010-02-02 15:37:34,942 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Connection release mode: auto
2010-02-02 15:37:34,943 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Maximum outer join fetch depth: 2
2010-02-02 15:37:34,944 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Default batch fetch size: 1
2010-02-02 15:37:34,944 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Generate SQL with comments: disabled
2010-02-02 15:37:34,944 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Order SQL updates by primary key: disabled
2010-02-02 15:37:34,944 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Query translator: org.hibernate.hql.ast.ASTQu
eryTranslatorFactory
2010-02-02 15:37:34,957 [Thread-37] INFO org.hibernate.hql.ast.ASTQueryTranslatorFactory - Using ASTQueryTranslatorFactory
2010-02-02 15:37:34,958 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Query language substitutions: {}
2010-02-02 15:37:34,958 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - JPA-QL strict compliance: disabled
2010-02-02 15:37:34,958 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Second-level cache: enabled
2010-02-02 15:37:34,958 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Query cache: disabled
2010-02-02 15:37:34,958 [Thread-37] INFO org.hibernate.cfg.SettingsFactory - Cache provider: org.hibernate.cache.Hashtable
Thanks in advance.
Regards,
Sakthi
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523602#523602
14 years, 2 months
[Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"
by jaikiran pai
JBoss development,
A new message was posted in the thread "Deployment of on-demand web applications":
http://community.jboss.org/message/523592#523592
Author : jaikiran pai
Profile : http://community.jboss.org/people/jaikiran
Message:
--------------------------------------------------------------
I like the idea of keeping out (selective/unwanted) applications from initial boot process of the server. As for the implementation details:
> mailto:bstansberry@jboss.com wrote:
>
>
> h4. Usage
>
> First, I create a common/deploy folder.
> Next, I move each war in server/default/deploy to common/deploy, replacing it with an XXX-activator-jboss-beans.xml file. The wars are admin-console.war, jmx-console.war, jbossws-console.war, invoker.war and ROOT.war.
>
> A typical XXX-activator-jboss-beans.xml looks like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <deployment xmlns="urn:jboss:bean-deployer:2.0">
>
> <bean name="AdminConsoleActivator" class="org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager">
>
> <property name="profileService"><inject bean="ProfileService"/></property>
> <property name="profileFactory"><inject bean="ProfileFactory"/></property>
> <property name="onDemandContextIntegrator"><inject bean="WebServer"/></property>
>
> <property name="contextName">admin-console</property>
>
> <!-- Build a profile from the contents of this single URI -->
> <property name="singleURI">${jboss.home.url}common${/}deploy${/}admin-console.war</property>
>
> </bean>
>
> </deployment>
>
>
>
>
> The MC bean exposes some other properties in case you want to do something more sophisticated:
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <deployment xmlns="urn:jboss:bean-deployer:2.0">
>
> <bean name="JmxConsoleActivator" class="org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager">
>
> <property name="profileService"><inject bean="ProfileService"/></property>
> <property name="profileFactory"><inject bean="ProfileFactory"/></property>
> <property name="onDemandContextIntegrator"><inject bean="WebServer"/></property>
>
> <property name="profileDomain">default</property>
> <property name="profileServer">default</property>
> <property name="profileName">jmx-console</property>
>
> <property name="serviceName">jboss.web</property>
> <property name="hostName">localhost</property>
> <property name="contextName">jmx-console</property>
>
> <!-- Build a profile from the contents of these URIs -->
> <property name="URIList">
> <list elementClass="java.net.URI">
> <value>${jboss.home.url}common${/}deploy${/}jmx-console.war</value>
> </list>
> </property>
> </bean>
>
> </deployment>
>
>
>
>
> The example above doesn't actually do anything sophisticated; it shows the properties with their default values.
>
>
I was thinking if we could avoid these n number of activator configs (one each for each on-demand app).
1) Maybe we could have just a single activator-jboss-beans.xml which has a list of applications that need to activated on demand?
2) Or maybe, we could designate a specific location within the AS deploy structure hierarchy which would be considered as the deploy folder of on-demand applications? So we could just move applications like admin-console to that location.
In either of these 2 approaches, internally we would still create the same set of metadata as we would do with n XXX-activation-jboss-beans.xml. But from a end user point of view, the amount of configuration required/exposed would probably be far less.
> mailto:bstansberry@jboss.com wrote:
>
>
> h4. Issues
>
> I see a few issues with the above:
>
> 1. Need for XXX-activator-jboss-beans.xml. It would be slick to somehow configure the war such that some deployer extracts relevant metadata, detects an "on-demand configuration, wires things up with JBoss Web, and then stops the deployment before anything expensive starts, with deployment continuing when the app is requested. Nice, yes, but much harder. For now I think we should stick to the KISS principle. The "profile activation" approach used here has been in use in the AS for well over a year.
>
> 2. Integration with mod_cluster. This is a problem, as mod_cluster will know nothing about the "on-demand" context until the war is actually deployed. So, the load balancer will not know to route requests to the server. This needs fixing, perhaps with a hook into mod_cluster to allow the MC bean to tell it about the on-demand context. I don't think this is a critical problem until AS 6.0.0.CR1 though. We already configure mod_cluster to ignore all the standard apps we deploy; users have to configure ModClusterService to expose them via the load balancer. IMHO until CR1 it's OK to force users who want to expose a standard app to move it back into the deploy/ dir.
> 3. Virtual host aliases and multiple contexts associated with the same application. The attached prototype doesn't deal with this, but that shouldn't be anything technically difficult to implement.
>
An additional point to note is related to ServletContextListeners/startup servlets. I have seen applications which tend to do heavy duty stuff within a ServletContextListener/startup servlets (for example, query a DB and loading time consuming data during the start of the application). So the first access to the on-demand application is going to be real slow. Although, it depends on which approach we take for implementing on-demand - as Bela said, either activating it in the background or activating it on first access. Anyway, this probably isn't an issue at all, because we don't set user applications as on-demand by default (does admin-console have this kind of startup servlet logic?). But i guess this is something to keep in mind.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523592#523592
14 years, 2 months
[JBoss Web Development] New message: "Strange behaviour of org.xml.sax.EntityResolver.resolveEntity method on JBOSS"
by Shivey Upadhyay
JBoss development,
A new message was posted in the thread "Strange behaviour of org.xml.sax.EntityResolver.resolveEntity method on JBOSS":
http://community.jboss.org/message/523542#523542
Author : Shivey Upadhyay
Profile : http://community.jboss.org/people/Shivey
Message:
--------------------------------------------------------------
Hi,
The peice of code that i want to discuss, parses a custom XML using SAXParser. The main class contains following code:
SAXParserFactory parserFactory = SAXParserFactory.newInstance();
parserFactory.setValidating(false);
SAXParser parser=parserFactory.newSAXParser();
XMLReader reader = parser.getXMLReader();
reader.setEntityResolver(new CustomEntityResolver());
reader.setContentHandler(new MyContentHandler());
InputSource is = new InputSource(this.getClass().getResourceAsStream("my.xml"));
reader.parse(is);
The class CustomEntityResolver implements org.xml.sax.EntityResolver and gives definition for method
public InputSource resolveEntity(String publicId, String systemId) throws SAXException, IOException {
InputStream iStream = this.getClass().getResourceAsStream(systemId);
InputSource iSource = new InputSource(is);
return iSource;
}
and my.xml starts with
<? xml ver...?>
<!DOCTYPE SYSTEM "shivey.dtd">
the ARGUMENT systemId comes as "shivey.dtd" on weblogic-- as defined in XML, BUT when the same application is executed on JBOSS 4.0.2, the value for systemId comes as "" and hence I GET A http://java.sun.com/javase/6/docs/api/java/net/MalformedURLException.html.
Observation: The iStream(InputStream) object created on Weblogic is of java.io.BufferedStream, but same object is of type sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream if systemId is hardcoded(shivey.dtd) on Jboss.
I appreciate any help in advance.
Thanks again,
Shivey Upadhyay
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523542#523542
14 years, 2 months
[JBoss Microcontainer Development POJO Server] New message: "Possible bug introduced in AbstractController?"
by David Lloyd
JBoss development,
A new message was posted in the thread "Possible bug introduced in AbstractController?":
http://community.jboss.org/message/523451#523451
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
Since (I think) the MC upgrade to 2.2, there's a problem occurring with redeployment of jboss-logging.xml files in AS trunk. If you make a small change (say, add whitespace) to the file to force it to be redeployed, you get this exception:
13:16:47,987 WARN [AbstractKernelController] Error uninstalling from Create: name=Logging:CONTEXT:system state=Configured mode=On Demand requiredState=Installed: java.lang.Error: INTERNAL ERROR: context not found in previous state Create context=name=JBossLogService state=Create mode=On Demand requiredState=Installed
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1416)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
at org.jboss.dependency.plugins.AbstractController.uninstallUnusedOnDemandContexts(AbstractController.java:1629)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1543)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1451)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
at org.jboss.dependency.plugins.AbstractController.uninstallUnusedOnDemandContexts(AbstractController.java:1629)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1543)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
at org.jboss.dependency.plugins.AbstractController.uninstallUnusedOnDemandContexts(AbstractController.java:1629)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1543)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)
at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:704)
at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:617)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.undeploy(BeanMetaDataDeployer.java:228)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.undeploy(BeanMetaDataDeployer.java:58)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalUndeploy(AbstractSimpleRealDeployer.java:69)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.undeploy(AbstractRealDeployer.java:117)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.undeploy(DeployerWrapper.java:204)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doUndeploy(DeployersImpl.java:1690)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1597)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1590)
at org.jboss.deployers.plugins.deployers.DeployersImpl.uninstall(DeployersImpl.java:1552)
at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:384)
at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1980)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1536)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:892)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:602)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:811)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:654)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:409)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:294)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.Exception: STACKTRACE
... 43 more
Seems like an internal error of some sort? The referenced bean is pretty simple - it's "On Demand", simple dependency, no start/stop/create/destroy methods. Find the declaration in logmanager-jboss-beans.xml if you're curious.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523451#523451
14 years, 2 months