Re: DelegatingConnection and getInnerMostConnection() not working
Hi, I also tried unsuccessfuly to access the underlying connection to physically close it using the Connection = ds.getConnection(); Connection dconn = ((DelegatingConnection) conn).getInnermostDelegate(); dconn.close(); I managed to physically close a connection, but I wasn't able to recreate it after, and I destroyed the counter for number of max active sessions. So, I think you will have the same issue once you have solved your ClassCastException. see http://mail-archives.apache.org/mod_mbox/commons-user/200810.mbox/[EMAIL PROTECTED] I changed the approach by - creating my own MyBasicDataSourceFactory extending BasicDataSourceFactory - creating my own MyBasicDataSource extending BasicDataSource - creating my own MyGenericPool extending GenericObjectPool then overriding the returnObject method which will in some cases call the **invalidateObject** method. hope this helps, Cyrille. Ziggy a écrit : Hi, I am trying to get to the underlying connection from the Tomcat pool but having some problems. I used this document to configure the pool http://commons.apache.org/dbcp/configuration.html The connection pool works fine if i dont try to get the underlying connection. I have the following configuration App server = Tomcat5.5 jdbc driver = Type 4 Resource name=jdbc/testdb auth=Container type=javax.sql.DataSource driverClassName=oracle.jdbc. driver.OracleDriver url=jdbc:oracle:thin:@10.10.10.10:1521:testdb username=testuser password=testuser maxActive=20 maxIdle=10 maxWait=-1 accessToUnderlyingConnectionAllowed=true/ And here is what i am trying to do (and where i get an exception) Connection = ds.getConnection(); Connection dconn = ((DelegatingConnection) conn).getInnermostDelegate(); When i try to get the underlying connection i get the following error Throwable:org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper java.lang.ClassCastException: org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper at oracle.sql.ArrayDescriptor.createDescriptor(ArrayDescriptor.java:149) at oracle.sql.ArrayDescriptor.createDescriptor(ArrayDescriptor.java:115) at com.bt.ccs21.data.accessors.ConsignmentDAO.submitDeclaration(ConsignmentDAO.java:251) at com.bt.ccs21.presentation.events.consignment.search.SubmitDeclaration.midAction(SubmitDeclaration.java:107) at com.bt.ccs21.presentation.events.CCS21EventAction.execute(CCS21EventAction.java:67) at org.apache.struts.chain.commands.servlet.ExecuteAction.execute(ExecuteAction.java:58) at org.apache.struts.chain.commands.AbstractExecuteAction.execute(AbstractExecuteAction.java:67) at org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:51) at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190) at org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:304) at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190) at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) I have the following libraries in $TOMCAT_HOME/common/lib - commons-dbcp-1.2.2.jar - oracle_jdbc14.jar I dont know why it is giving me this error. Any help will be greatly appreciated.
Re: Common DbUtils
But I have only one paramter in query. I can't pass an array parameter.
Again, the number of parameter is unknown and for this I use the IN statement
in sql.
Thanks,
Pietro
Try:
String[] params = {1, 2};
Hen
On Mon, Aug 25, 2008 at 2:12 PM, Pietro Santurelli [EMAIL PROTECTED] wrote:
Hi all,
I'm using common DbUtils 1.1 to execute this query:
SELECT column1 FROM table WHERE id_table IN (?).
Java fragment code is:
String params = 1,2;
String query = SELECT column1 FROM table WHERE id_table IN (?);
QueryRunner qRunner = new QueryRunner();
ArrayListStore stores =
(ArrayListIncasso)qRunner.query(connection,query, params, new
BeanListHandler(Store.class));
The ArrayList obtained is populated only with stores with id = 1. In other
words, the stores with id = 2 aren't retrieved. The semicolon seems to be
the problem.
Is this a bug of common DbUtils?
Thanks in advance,
Pietro
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache DBCP Question
John Jason Brzozowski schrieb:
try {
logger.info(Loading MySQL driver);
Class.forName(com.mysql.jdbc.Driver);
logger.debug(Connecting to + mDbUrl + as + mDbUser +
/(Password not displayed));
mconn =
DriverManager.getConnection(jdbc:apache:commons:dbcp:foo);
if(!mconn.isClosed()) {
logger.trace(Connected to MySQL database);
}
...
}
}
} catch (Exception e) {
logger.fatal(e);
e.printStackTrace();
}
When I print the number of connections active and idle I get the following:
TRACE [main] (?:?) - Connection pool idle connections, 0, active
connections, 1
The number of active connections never increases past one. I thought the
following would cause 10 connections to be created:
gkopc.maxActive = 10;
Any comments on what I missing would be greatly appreciated. To provide
additional context I wish to use connection pooling when making large
quantities of database updates. Most examples I see are for SELECTs not
INSERTs.
It's been a long time since I've used DBCP. But as no-one has answered,
I'll offer a suggestion.
That maxActive looks like a *maximum* setting.
Try this:
Connection[] conns = new Connection[20];
for(int i=0; i8; ++i) {
conns[i] = DriverManager.getConnection();
}
then dump the output.
I would expect that then you will see 8 active connections reported.
And if you increate the loop to 10, then it will probably hang, as the
attempt to fetch the 11th connection will block until someone returns
one of the existing ones. Which would happen in a threaded app, but
won't happen here in a single-threaded test.
Regards, Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Files Last modified time
snpuvi schrieb:
Hi,
How can I find the actual, file created/modified time using FTP schema.
When I used FTP schema to find the files's last modified time returns the
same time for closely created files. But When I checked the modified time on
the file properties( Windows XP) showed few seconds differences between the
files.
(works fine with SMB schema)
FileSystemManager fsManager = VFS.getManager();
FileObject ftpFile = fsManager.resolveFile(ftp://User:[EMAIL
PROTECTED]/ftpShare);
FileObject[] file = ftpFile.findFiles(new MyFileSelector(my pattern));
for (int i=0; i file.length;i++)
{
System.out.println( last updated time
+file[i].getContent().getLastModifiedTime());
}
Have you tried using ftp to connect to your server, doing an ls or
dir or modtime and seeing what timestamp is displayed? That is the
information that VFS has available to it
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Call me a moron, but I just can't make it work!
Michael Robinson schrieb: Hi, I'm writing a program that must load, search, edit and save Mac OS X plist files. I was attempting to use apple's NS* foundation classes, but I couldn't work out how to write to the plist files (maybe I'm just stupid). I searched around the internet and was overjoyed to find apache.commons.configuration. I've played with it for the past few days, trying to figure out how I'm meant to get data out of the plist files I'm working with. Have you looked at the unit tests for the configuration project? Commons projects generally have pretty good unit test coverage, which means that there is almost certainly an example of reading a plist file and extracting a value from it in there somewhere. In general, the unit tests for a project are a good source of examples when the explicit user examples and tutorials don't cover what you need to do. The unit tests can be fetched from the Apache subversion system using the url that is in the left-hand navigation bar. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Contention for DriverManager when initializing multiple datasources WAS: Re: dbcp blocked on webapp startup
or feature (why do we see loadInitialDrivers in the first trace above?) c) a driver bug Any thoughts on this? Why is the first thread RUNNABLE, but apparently hung? JDK is Java HotSpot(TM) 64-Bit Server VM (1.6.0-b105 mixed mode): - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath] JXPath 1.3 Status
Search the myfaces dev email list archives. The release candidates will have been posted on a developer's site; they are deliberately not uploaded to the world-wide mirrors as it would be a waste of bandwidth and disk space to mirror them. Or check out the source from svn and build it. No destabilising changes are going in while the release work is in progress, so trunk is fairly safe. Regards, Simon Matt Accola schrieb: Please forgive my ignorance. I cannot find any 1.3 release candidates or nightly builds from the project page, http://commons.apache.org/jxpath/. The release candidates do not appear to be published in the archives, http://archive.apache.org/dist/commons/jxpath/. The Nightly Build link, http://cvs.apache.org/builds/jakarta-commons/nightly/commons-jxpath/, does not resolve. Where can I find a relatively stable, post 1.2 build? Matt -Original Message- From: Matt Benson [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2008 10:46 AM To: Commons Users List Subject: Re: [jxpath] JXPath 1.3 Status Yes, JXPath 1.3 has actually had three release candidates cut; a fourth should come very soon. So JXPath 1.3 should be released sometime in July. -Matt --- Matt Accola [EMAIL PROTECTED] wrote: Is JXPath still an active project? I see the last release was 1.2 in August 2004. I see 46 of 46 JIRA issues for the 1.3 release have been marked completed but no official 1.3 release. Is the nightly build stable enough for production use. The issue I am facing is that I am experiencing what appears to be a concurrency issue with JXPath and would like to test if the patches applied to 1.3 resolve the issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange performance issues seen with Log.isDebugEnabled()
Jean-Philippe Daigle schrieb: Replacing it with just this assignment (to a public var so it's not optimized away): _dbg_str = String.format(appack id=%s res=%s, id, ack_r); Gives me the fast throughput case. I wasn't too surprised to hear that your custom Log implementation was causing a difference when it was doing IO (writing the message out). Any IO operation requires a call into the operating system kernel which can then trigger a context switch. But the fact that you see a difference just when calling String.format is rather surprising. I've had a brief look at the implementation of String.format and don't see any operations that would require a call to the kernel, or thread synchronization operations. Nevertheless it does look like there is some thread scheduling issue involved here, and that something that String.format call is doing is affecting which threads are running and which are blocked, and that in turn is affecting the throughput of your application. And of course you *are* running this on Windows. Good luck trying to tune this; if it is indeed a thread-scheduling issue then you may well find that changes to OS version, JVM version, and apparently unrelated parts of the app cause performance to alter. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange performance issues seen with Log.isDebugEnabled()
Jörg Schaible schrieb:
Jean-Philippe Daigle wrote:
[snip]
Ah, so there's one more thing I hadn't tried, which I just did, and
explained a bit of the situation: completely removing the
logging block
(don't check isDebugEnabled(), don't call .debug(), etc.
Removing the whole logging block results in getting the same slow
throughput case that I was blaming on isDebugEnabled().
Replacing it with just this assignment (to a public var so it's not
optimized away):
_dbg_str = String.format(appack id=%s res=%s, id, ack_r);
Gives me the fast throughput case. Wow. So apache commons logging is
blameless, what determines whether you get the fast or the
slow message
throughput case is actually _slowing down the thread calling the
ackMessage() method_. Slowing down this frequently-called method with
useless String.format() work results in more than double the
throughput.
I have no idea why (it's counterintuitive), I suspect I need
to get more
visibility into the interactions between threads here.
Thanks to everyone that read this thread, looks like the problem's
somewhere else in my code. (Though if you DO have any suggestions that
could explain what I'm seeing, let me know, even if this is
no longer a
logging issue :) )
Can you stip it down to detect the real call that is responsible for the
speed-up?
1/ _dbg_str = ack_r.toString();
or
2/ _dbg_str = String.valueOf(id);
or even
3/ ack_r.toString();
alone?
What's implemented with ack_r.toString() ? What kind of implementation is ack_r
? A proxy ?
Yes, good point. I missed that ack_r.toString will be triggered.
I wonder what happens if you replace the String.format call with just this:
synchronized(this) {
++dummy;
}
where dummy is a public int member, just so the synchronized block isn't
optimised away. The synchronization operation will have a number of
side-effects, including entering the OS kernel, flushing CPU caches and
allowing the OS scheduler to run.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow roadmap
Torsten Curdt schrieb: Seems like quite some people are using it - but helping hands are still very rare. Seems to be a common problem. Open source use has boomed, but the contributor pool has not grown much. For example Apache Myfaces has tens of thousands of users, but about 10 regular committers. Hopefully the wider community (esp. companies that use open source libs) will eventually evolve to be contributors as well as users. Or (my favourite) governments could give OSS development grants; giving 1% of the amount that they pay for commercial software licenses would make a big difference. And it could go to their own citizens. In the meantime, all contributions are very welcome! *notch* *notch* notch ?? :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FileUpload - the download's md5 does not match apache's md5
Hi, The FileUpload download page here: http://commons.apache.org/downloads/download_fileupload.cgi says: ...you must verify the integrity of the downloaded files using signatures downloaded from our main distribution directories. I downloaded the file: Binary ---1.2.1.tar.gz from 4 different mirrors and the md5 of the downloads does not match apache's md5. I retrieved apache's md5 by clicking on the md5 link beneath the 1.2.1.tar.gz link: Binary 1.2.1.tar.gz ---md5 Is anyone aware of this problem? ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Turning off commons logging
John B. Moore schrieb: I searched carefully the entire classpath (JBuilder has a view that shows you the entire classpath used on startup) and I did find A general logging.properties file in the: Versions/1.5.0/Home/lib/logging.properties .. with the following settings.. #== # Default global logging level. .level= INFO # default file output is in user's home directory. java.util.logging.FileHandler.pattern = %h/java%u.log java.util.logging.FileHandler.limit = 5 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter # Limit the message that are printed on the console to INFO and above. java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter # .. which does not seem to be in effect with commons because I'm seeing DEBUG output.. And that's a java.util.logging configuration file. The default layout for java.util.logging looks quite different from log4j; from the output examples you showed, I'm pretty confident that it is log4j that is generating that output, not java.util.logging. The only other properties files I could find in that path had no mention of logging in general or log4j in particular.. (I also used SpotLight which searched the entire hard drive and only found what I expected to find and where I expected to find it..) Ok, worth a try. As a last resort, you could edit that commons-logging.properties file to specify NoOpLog rather than Log4JLog. That should block all messages logged via commons-logging, although all messages logged directly to log4j will not be affected. That isn't the best solution of course. That worked.. But you are right not a good solution.. Is there something else I could put in that file that would allow only ERROR messages to come through..? Well, I suppose you could try configuring commons-logging.properties to use the org.commons.logging.impl.SimpleLog implementation, then set a system property to configure SimpleLog. However that's still a hack. Really, you do want to pass messages through to log4j rather than use the (deliberately dumb) SimpleLog class. Commons-logging's job is specifically to find the appropriate underlying log instance to pass messages onto, and try to do as little else as it possibly can. Even finding the underlying log instance turns out to be quite complicated when strange classloader hierarchies are involved. Commons-logging specificically does NOT do any filtering of messages it passes through to the underlying logging implementation. So there is no option for it to filter messages by threshold while still using log4j. Is this problem occurring when you run your webapp from the commandline, or are you always running it from within JBuilder? If you are always using JBuilder, then maybe JBuilder sets up some odd classloader hierarchy that includes a log4j config file from jbuilder itself.. I also know that the JBoss classloader specifically looks for commons-logging and treats it as a special case, returning a class from an unexpected classloader. This wasn't the brightest move on their part. But I think you're just using plain tomcatif so then there is no problem as tomcat has no hacks like this. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Turning off commons logging
Pierre Brico schrieb: Hi all, I have a similar problem with my application. This is a java application (not using any application server). I use commons-logging for logging puposes and log4j as implementation. This is working (I mean I got the log) but it is impossible to deactivate the log. All log informations go to a file named extern.log in the directory from which the application is launched. The log level is always DEBUG (however I mentioned ERROR in the log4.xml) and the format is the same as 2008-05-29 12:57:30,829.1 [main] DEBUG com.tsdsoftware.ouat - Environment used for the WS call: T24JBDEV I have create a commons-logging.properties file to force it to use the log4j implementation and avoid the discovery procedure but it didn't change anything to the log level. As my application is running on Windows with jdk1.6, I tried to trace all API calls to the system with Processmonitor ( http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx?PHPSESSID=d926) and I saw that the JVM accessed to the log4j.xml configuration file. But the level stays DEBUG and the output file stays extern.log. (I'm wondering where this filename comes from. I searched all source files of log4j and commons-logging but didn't find this 'default' name). Any idea ? Well I can promise you 100% that filename is nowhere within commons-logging or any commons library. And I very much doubt it is anywhere within log4j; log4j defaults to doing nothing when not configured (except for writing two lines of text to stderr). As I don't have your environment, I cannot guess what might be setting this. But something is. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Turning off commons logging
John B. Moore schrieb: I'm using a number of org.apache.commons libraries in a web project and I need to turn off the logging that is occurring within the commons. I must confess that, though I have used Log4j for years, I only use it at a very basic level and still rely on a very basic property file. (shown at the bottom of this message) The commons libraries are generating massive amounts of output and I need to shut that off. I keep my log4j.properties file for a given webapp in: ../tomcat/webapps/applicationroot/conf/log4j.properties My first guess wast that it is seeing my core instance of Log4j and using that.. but when I add log4j.logger.org.apache.commons=ERROR ..it has no effect.. which makes me question that it is seeing my configuration file. Anyone have some hints as to getting the commons logging turned off without affecting my application logging. Thanks.. John.. current log4j property file contents === log4j.rootLogger=DEBUG, A1, R1 # A1 is a Console Appender log4j.appender.A1=org.apache.log4j.ConsoleAppender # R1 is a Rolling file appender log4j.appender.R1=org.apache.log4j.RollingFileAppender log4j.appender.R1.File=application.log # File Size log4j.appender.R1.MaxFileSize=100KB # Keep one backup file log4j.appender.R1.MaxBackupIndex=2 # Output Patterns log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%-4r [%t](%F:%L) %-5p - %m%n log4j.appender.R1.layout=org.apache.log4j.PatternLayout log4j.appender.R1.layout.ConversionPattern=%-4r [%t](%F:%L) %-5p - %m%n I presume that your apps are using log4j directly, and are being controlled by the config file you posted above, but libs that use commons-logging are not? Are the commons lib messages getting the ConversionPattern that you specify in your config file? If yes, then the right config file is being seen, and you've just not got the log4j command to set the threshold right. Interestingly, the default logging level for almost all logging libs is INFO, and commons libs don't log much at INFO level or above. Yet you say that you are getting massive amounts of logging. So it would appear that somehow you have a config file in your environment that is forcing logging to a level lower than the default. You could try putting a file named commons-logging.properties in your app's classpath with the following contents: | org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger |This disables the auto-discovery feature of commons-logging, and ensures that log4j is always used. I would have expected that commons-logging would detect and use log4j automatically, but this will guarantee it. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache commons inter-dependencies
Brett Hitzel schrieb: Hello, On our Tomcat installation we are utilizing the following jar files (among others): commons-httpclient-2.0.2.jar commons-beanutils-1.6.jar commons-codec-1.3.jar commons-collections-2.1.1.jar commons-dbcp-1.2.1.jar commons-discovery-0.2.jar commons-el.jar commons-lang-1.0-b1.jar commons-logging-1.0.1.jar commons-pool-1.2.jar These are mostly all some degree of outdated I know, unfortunately that is out of necessity right now, due to some legacy applications. We have identified the need to upgrade commons-httpclient to version 3.1. Due to the rather precarious nature of our system, we prefer to NOT upgrade the remaining common libs if we do not have to. I have read all through the documentation and I wasn't able to find much information on the inter-dependencies of the commons files, but based on what I've read it seems that the individual components are built in such a way that their respective versions shouldn't matter much. Is there a matrix out there that details what versions of what components will work together and which ones won't? Is this even something I should be worried about? No, there is no matrix of that sort. It would be useful, but the vast amount of work that would be required to test all possible combinations and document the results is just too much (and too boring). If I understand right, you just want to upgrate httpclient. None of the other libs depend on httpclient, so all you need to worry about is whether httpclient will work with the older libs you have. It is *possible* that commons-httpclient still works with those older libs, but you'll need to do the work to figure out if that is true or not. The maven2 pom.xml declares what dependencies are needed; the version numbers in there are the recommended versions (and these are the ones that are tested via the unit tests before release). I see here: http://hc.apache.org/httpclient-3.x/dependencies.html that codec and logging are the only runtime dependencies (this is the same info that is in the pom file). I would suggest checking out the httpclient source, editing the pom.xml file to specify the codec and logging versions you want to use, then running the unit tests. If they pass then that's a pretty good indication that httpclient will work with your older lib versions. Logging certainly will not be a problem (the API is very stable), but I don't know about codec. Note that the httpclient project recently moved from being part of the commons project to being part of the http components project. So questions about httpclient should probably be sent to the httpclient email list rather than here.. The source for the 3.1 release of httpclient can be downloaded via svn from here: http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/tags/HTTPCLIENT_3_1/ Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] implementation of String-Date for xs:dateTime
Christopher Schultz schrieb: Sebb, sebb wrote: | Here is the implementation that I developed [for an xs:dateTime converter]. Oddly, | it seems that sometimes the TimeZone is incorrectly set (though the | normalized time appears to be correct) in the resulting Date. Any tips | would be appreciated. | | Apologies for the poor formatting. | | | Could you please create a JIRA enhancement issue and attach the code there? Certainly. Should I log it against digester (where it is most useful) or beanutils (where all the stock Converters actually live)? Not against Digester please. Digester doesn't do any data conversion itself, just invokes BeanUtils. BeanUtils seems the appropriate place for this. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL] Problem send Html email
Hi folks, I just started using commons-email 1.1 and I'm trying the examples of the User Guide. I'm trying to send the email as in the example in a web application (Tomcat 6 + Spring + Stripes) but I've got some error as I receive the message: - subject header: empty - to header: undisclosed-recipient - html message: shown as plain text (with MIME boundary) in the message body I'm just setting all as in the example but it doesn't work! Same code of the example put into a Stripes ActionBean... All needed libraries are included as well and the project is managed with Maven... From a simple Java project everything works right, so it's not a problem of my smtp server. Anyone who experienced something similar? Something to configure in my Tomcat + Spring + Stripes environment? Thank you in advance, Ema - Scopri il Blog di Yahoo! Mail: trucchi, novità, consigli... e la tua opinione!
[Email] Problem send Html Email
Hi folks, I just started using commons-email 1.1 and I'm trying the examples of the User Guide. I'm trying to send the email as in the example in a web application (Tomcat 6 + Spring + Stripes) but I've got some error as I receive the message: - subject header: empty - to header: undisclosed-recipient - html message: shown as plain text (with MIME boundary) in the message body I'm just setting all as in the example but it doesn't work! Same code of the example put into a Stripes ActionBean... All needed libraries are included as well and the project is managed with Maven... From a simple Java project everything works right, so it's not a problem of my smtp server. Anyone who experienced something similar? Something to configure in my Tomcat + Spring + Stripes environment? Thank you in advance, Ema - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester - DynamicDigester?
tim robertson schrieb: Hi, I would like to configure some form of DynamicDigester to parse generic XML that contains repeatable content into a List of Map. Each repeating element means a new map, and the map is keyed on the pattern, with the value being the digesting value. So considering: ... record nameTim/name age21/age /record record nameTom/name age22/age /record ... I would like to configure it with patterns */name and */age and also with the pattern for the repeating element */record. Then after digesting I would like a ListMapString, String representing: [name:Tim][age:21] [name:Tom][age:22] Can anyone help me with this? Be aware that I want to digest different XML schemas with the same Digester, but just register different patterns for the items of interest and the marker for the repeating element. So really, I am thinking a pattern to push onto the stack a new HashMap for each repeat element, and then register patterns to put the Pattern as the key and the result as the value. Unfortunately I can't work out how to get the Pattern in a Rule firing... Thanks for any help or advice! Have you looked at the digester examples that are included in the source download, or that can be accessed directly here? http://svn.apache.org/repos/asf/commons/proper/digester/trunk/src/examples/ Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help - Log4JLogger does not implement Log
listenboss schrieb: Hello All, I'm getting the following error. I'm using jboss 4.0.2 app server to deploy ear which contain war file inside. [StandardPipeline] Can't register valve [EMAIL PROTECTED] org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log at org.apache.commons.logging.impl.LogFactoryImpl.newInstance( LogFactoryImpl.java:532) Please ensure that both your app and jboss are using commons-logging 1.1.0 or later (1.1.1 is the most recent release). Don't forget to check the shared libs directories in the jboss install for copies of commons-logging. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Configuration
The org.apache.crimson parser *is* the default parser for java 1.4. It
was only in 1.5 that they moved to Xerces.
The question is whether this is
(a) something in the input that crimson just doesn't handle, or
(b) something in the way that Configuration is setting up the xml parser
that crimson doesn't like
The best test would be to try to process test.plist.xml directly with
crimson, eg just read it and count the number of elements. If that
doesn't work, then there isn't much that Configuration can do about it.
Regards,
Simon
Emmanuel Bourg schrieb:
Hi,
Did you try with Java 5 instead ? Is there another XML parser in the
classpath besides the default one of Java 1.4 ?
Emmanuel Bourg
comctrl6 a écrit :
Hello,
The following code sample adapted from the Configuration
test suite, throws a NullPointerException. The exception seems to be
thrown from the crimson XML parser, but I'm not sure what the problem
is exactly. Any idea what is going on?
Note: - The file
test.plist.xml exists and it could be referenced from the Java file.
The file is taken from the Configuration test cases.
- The following
libraries are included in the classpath: commons-collections,
commons-configuration, commons-lang-2.3, commons-logging.
- Compiling against Java 1.4.
- Mac OS X 1.4.11
public static main(String[] args) {
try {
FileConfiguration config = new XMLPropertyListConfiguration();
config.setFileName(test.plist.xml);
config.load();
} catch (ConfigurationException e) {
e.printStackTrace();
}
}
Exception is as follows:
org.apache.commons.configuration.ConfigurationException: Unable to
parse the configuration file
at
org.apache.commons.configuration.plist.XMLPropertyListConfiguration.load(XMLPropertyListConfiguration.java:247)
at
org.apache.commons.configuration.AbstractHierarchicalFileConfiguration$FileConfigurationDelegate.load(AbstractHierarchicalFileConfiguration.java:443)
at
org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:356)
at
org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:322)
at
org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:285)
at
org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:217)
at
org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:195)
at
org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.load(AbstractHierarchicalFileConfiguration.java:164)
at ConfigTester.main(ConfigTester.java:19)
Caused by: java.lang.NullPointerException
at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:691)
at org.apache.crimson.parser.Parser2.parse(Parser2.java:337)
at
org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448)
at
org.apache.commons.configuration.plist.XMLPropertyListConfiguration.load(XMLPropertyListConfiguration.java:243)
... 8 more
Thanks.
Looking for last minute shopping deals? Find them fast with Yahoo!
Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
