Re: Access SQL Server 2005 and 2000 on same machine
Probably the answer is just in jTDS FAQ in http://jtds.sourceforge.net/faq.html Check the answer to What is the URL format used by jTDS? My .2 E- On 4/22/08, Alexander Diedler [EMAIL PROTECTED] wrote: No, the Services on the same Port and same IP. SQL Server allow up to 99 Instances on one machine. Only the Instance Name is important to identify the correct Instance. But how I can Access a SQL Server by Instance with Tomcat? Alex From: David Smith [mailto:[EMAIL PROTECTED] Sent: Tue 4/22/2008 12:50 PM To: Tomcat Users List Subject: Re: Access SQL Server 2005 and 2000 on same machine Ok... how do you get two services on the same port? Are they bound to different IPs? They can't both respond on the same address and port. --David Alexander Diedler wrote: Hello, We have installed a SQL 2000 and SQL 2005 Server Express on the same server and same Port (1433) Now we have no chance to tell the Tomcat in Conf Directory, which SQL Server Version and Database has to be choosen for the Application. I know, that there are Instance Names like 127.0.0.1\sqlexpress or 127.0.0.1\default but how use it in Tomcat 6.0.14 on Windows 2003 Server? Here a Example from /conf/Catalina/localhost/root.xml Resource name=jdbc/jTDS auth=Container type=javax.sql.DataSource maxActive=100 maxIdle=30 maxWait=1 username=sa password=xxx removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true driverClassName=net.sourceforge.jtds.jdbc.Driver url=jdbc:jtds:sqlserver://testsqlserver:1433/tecracer4;charset=Cp1252 / - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
To see how standard and legal this usage is, you can try enabling the security manager (the only way to control writing to system properties - which are always JVM wide, so since Tomcat uses JAXP, Tomcat cannot avoid being affected to some extent when a webapp changes the parser factory - is to use the security manager) :) The other problem is that this by defeinition won't behave the same in different VMs (1.4, and same if you have a 5.0 VM with the compatibility pack for TC 5.5). Not allowing the application to modify this system property is not an option for me. You can send me a WAR to test however, I would be interested to look at this alleged difference in behavior. I've filled a bug report to which I attached a simple web app for reproducing the issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=41759 Etienne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Migration from 5.5.20 to 6.0.10: parser issue on application deployment
Hi, I'm facing a small issue when migrating a production server from 5.5.20 to 6.0.10 (see the exception below). One of the web app running on that server includes xercesImpl.jar and use it through modifying the system property javax.xml.parsers.SAXParserFactory. This was not a problem in 5.5.x, but with 6.0.10, it seems that tomcat loads its instance of the parser after web initializations. It is then affected by the web app that modified the system property. I've been able to 'fix' that by copying the xercesImpl.jar into tomcat lib directory. Shall this be considered as a regression as in that case tomcat configuration is somehow altered by a web app? (in that case I'll fill a bug in bugzilla)) Regards, Etienne GRAVE: Erreur lors du déploiement du répertoire portal de l'application web javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:134) at org.apache.tomcat.util.digester.Digester.getFactory(Digester.java:487) at org.apache.tomcat.util.digester.Digester.getParser (Digester.java:692) at org.apache.tomcat.util.digester.Digester.getXMLReader(Digester.java:900) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1581) at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDiges terSource.execute (MbeansDescriptorsDigesterSource.java:227) at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDiges terSource.loadDescriptors(MbeansDescriptorsDigesterSource.java:210) at org.apache.tomcat.util.modeler.Registry.load (Registry.java:753) at org.apache.tomcat.util.modeler.Registry.loadDescriptors(Registry.java :865) at org.apache.tomcat.util.modeler.Registry.loadDescriptors(Registry.java :843) at org.apache.tomcat.util.modeler.Registry.findDescriptor (Registry.java :907) at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java :627) at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java :962) at org.apache.tomcat.util.modeler.Registry.registerComponent (Registry.java :793) at org.apache.catalina.core.StandardWrapper.registerJMX(StandardWrapper.java :1801) at org.apache.catalina.core.StandardContext.registerJMX(StandardContext.java :5200) at org.apache.catalina.core.StandardContext.start (StandardContext.java :4374) at org.apache.catalina.core.ContainerBase.addChildInternal( ContainerBase.java:761) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:741) at org.apache.catalina.core.StandardHost.addChild (StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java :920) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java :883) at org.apache.catalina.startup.HostConfig.deployApps (HostConfig.java:492) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent ( LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1023) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1015) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start (StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) 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.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
On 3/3/07, Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Etienne Giraudy [mailto:[EMAIL PROTECTED] Subject: Migration from 5.5.20 to 6.0.10: parser issue on application deployment One of the web app running on that server includes xercesImpl.jar and use it through modifying the system property javax.xml.parsers.SAXParserFactory. That behavior looks rather questionable to me. Having a webapp modify a global property that has the potential of affecting everything running in that JVM - including other webapps and the container - seems like a very risky strategy, raising serious compatibility and operability issues. The fact that it happened to work in one version of one container doesn't imply that it's an appropriate thing to do. I guess that the point that is questionnable here is the way the API is designed: modifying the system property 'legal' and, AFAIK, it is the only way to choose the parser implementation we want to use (http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParser.html). From that point of view, shouldn't Tomcat protect itself against bad-designed standard APIs usage? Etienne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Oracle Jsdk 1.5
You will find an answer on OTN ( http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/index.html). * classes12 packages are for use with JDK 1.2 1.3 * ojdbc14 packages are for use with JDK 1.4 1.5 Etienne On 1/9/06, Tomas [EMAIL PROTECTED] wrote: My first question is : can we use jsdk 1.4 in place of jsdk1.5 ? Have you checked out JDK 1.4 Compatability Package, http://tomcat.apache.org/download-55.cgi? -Tomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
