dave taubler

Ernest,

Thanks so much for your response. I did a quick check, and it seems indeed this will solve my issue.

Best regards,
Dave

FYI, I spent a lot of time trying to figure out where I was using inappropriate slang in my last post. When I tried to submit my post I was prevented, and was told I was using "u" as a silly English abbreviation for "you". Finally, I figured out that referring to the U.S. was the offending line. Maybe abbreviating the United States to the U.S. is silly, but I tend to believe that it's a failure of the validation engine, and that it's far sillier to have to use CODE tags to refer to the U.S..

Just FYI.

Dave

Hi,

I'm trying to do something that I thought would be common and trivial, but after hours of googling, appears to be neither. Basically, I am simply trying to determine whether a given String represents a valid integer (or decimal, in some cases) for a given locale.

First, I checked simply to see if methods like Integer.parseInt() accept a Locale; they do not. Then, I thought I could retrieve the decimal-separator and group-separator (e.g. a comma--as in 1,000--in the US) from either the Locale or the NumberFormat object and do my own validation of the String, but I cannot retrieve that information either. So finally I decided to try a brute force approach just try to parse the String and if it works, the String is valid, and if an Exception is thrown, it is not valid:

public boolean test(String value, Locale locale) { boolean retVal = true; try { NumberFormat nf = getNumberFormat(locale); nf.parse(value); } catch (Exception e) { retVal = false; } return retVal; }

But it turns out that you can pass pretty much any String in, and the NumberFormat will force it into a number. Seriously, "1asdsad" successfully converts to 1.

My last option, I guess, is to simply parse the String and validate that every character is either a number, or '.', '\'', ' ', or ','. But that hardly seems accurate, and would cause a lot of false negatives. So I think I must be missing something. What I'm trying to do has got to be commonplace, but I can't find any examples anywhere.

Does anyone know of a proper approach?

Thanks in advance.

Hi,

I'm trying to minimize trips to the database (aren't we all?) My scenario is that I have an entity of type MyObject that I am retrieving as part of a composition of another object. In other words, the MyLargeCompositeObject instance that I am retrieving contains an instance of MyObject. Later on (but in the same transaction/session) I want to update fields in MyObject and then persist those updates.

The unfortunate twist is that at that point, I no longer have a reference to the instance of MyObject that I retrieved from the database.

However, my understanding is that Hibernate's session cache still contains that instance. So I tried a little experiment. My experiment kind of worked, but also provided an unusual result. So I'm hoping someone can explain what is happening.

The clip below is part of the method I use to once again obtain a reference to the MyObject, so that I can update its fields and persist it. ("id" is a Long representing the primary key of the MyObject that I want).

SQLQuery sqlQuery = (SQLQuery) this.hibernateTemplate.getSessionFactory().getCurrentSession().getNamedQuery(GET_BY_ID); sqlQuery.setLong(arg1_label, id); sqlQuery.setCacheable(false); List results = sqlQuery.list(); // database activity is logged if ((results != null) && (results.size() > 0)) { OrderProcStatus ob = (MyObject)results.get(0); }

When sqlQuery.list(); executes, Hibernate logs SQL activity, so I know it's hitting the database. That's not what I want. So then I added a test line to see if I could get a reference without hitting the database, by using load() rather than executing a query:

// my test MyObject ob2 = (MyObject)this.hibernateTemplate.getSessionFactory().getCurrentSession().load(MyObject.class, id); // No database activity logged! // end my test SQLQuery sqlQuery = (SQLQuery) this.hibernateTemplate.getSessionFactory().getCurrentSession().getNamedQuery(GET_BY_ID); sqlQuery.setLong(arg1_label, id); sqlQuery.setCacheable(false); List results = sqlQuery.list(); // database activity is still logged here if ((results != null) && (results.size() > 0)) { OrderProcStatus ob = (MyObject)results.get(0); boolean b = (ob == ob2); // b is true, when testing for identity. Why aren't they two different objects? }
My experiment worked; Hibernate appeared to retrieve the ob2 object from the session cache, rather than hitting the database. But I left the other code in place as well, and so Hibernate then hits the database to get another instance of the MyObject entity. Except... the instance is actually the same one via the load() method.

So... does anyone know what Hibernate is doing here? Or am I mis-interpreting something? Thanks in advance.

Ah ha! I did as you suggested (opening the Run dialog and checking the runner) and it indeed was JUnit 3. I'd assumed that since I set my project build path to contain JUnit 4.4 instead of JUnit 3, I'd assumed that the tests would all run as JUnit 4 when I right-clicked and chose Run As -> JUnit Test. Guess I was wrong!

Anyway, thanks a bunch! I ran the test from the Debug dialog and stopped at a breakpoint, and verified that it's running as SpringJUnit4ClassRunner, s oI think I'm good to go.

Hi,

The crux of my problem is that the new JUnit 4.4. annotation, @RunAs, seems to have no effects whatsoever. Since in my Googling, I've found plenty of examples of code that uses the annotation, I must be doing something wrong.

I'm using Hibernate 3, Spring 2.5, and JUnit 4.4 What I am attempting to do is to write unit tests for my Hibernate DAOs. Although in production they do not create their own transactional context (rather, a transactional context is created for them) I need them to create their own transactional context while running as unit tests.

To do this, it seems that the best approach is to annotation my unit tests using Spring's @Transactional annotation. In order for that to work, the tests need to run under SpringJUnit4ClassRunner. However, annotating my test class with

@RunWith(SpringJUnit4ClassRunner.class)

has no effect. When I debug the unit test, stop at a breakpoint, and look at the stack trace, I see that the test is always being run with JUnit's RemoteTestRunner.

It may be worth noting that I am running my JUnits within Eclipse (right-click on the class, and choose Run As -> JUnit Test).

I've tried running as other JUnit runners (@RunWith(Suite.class), for example) to see if that would have any effect; it did not. The tests still ran with RemoteTestRunner.

What on earth could I be doing wrong? At this point I'm not even concerned with creating the transactional boundaries; I just want to figure out why I can't tell JUnit what to Run As.

Code is below:

@TestExecutionListeners({}) @RunWith(SpringJUnit4ClassRunner.class) public class VendorStubEventXrefDAOTest extends BaseDAOTest { //ApplicationContext appContext; @Test @Transactional public void testFindbyEventId() { ApplicationContext appContext = SpringContextLoader.getInstance(); Object o = appContext.getBean("vendorStubEventXrefDAO"); VendorStubEventXrefDAO vsedao = (VendorStubEventXrefDAO)o; VendorStubEventXref vse = vsedao.findByEventId(484110L); assertNotNull(vse); vse = vsedao.findByEventId(0L); assertNull(vse); } }

Hi,

Other people have had to have had this problem. I am trying to run a Spring application to do basic Spring/Hibernate transaction management/AOP stuff. My Spring config file can't be parsed because apparently the XML parser being used by Spring is not namespace aware. I've tried the same application running within Orion and Tomcat, both resulting in the same problem.

Here's the error:
org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'aop:config'. org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(Unknown Source) org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(Unknown Source) org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source) org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source) org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) org.apache.xerces.parsers.XMLParser.parse(Unknown Source) org.apache.xerces.parsers.DOMParser.parse(Unknown Source) org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:78) org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:361) org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:313) org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:290) org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:142) org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:158) org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:184) org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:112) org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:79) org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:97) org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:411) org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:338) org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:122) org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:66)

Here are relevant lines from my config file that I am trying to read in via

private static ApplicationContext appContext = new ClassPathXmlApplicationContext("com/taubler/shareware/biz/config/spring-biz-context.xml");

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:aop="http://www.springframework.org/schema/aop" xsi:schemaLocation="http://www.springframework.org/schema/beans <a href="http://www.springframework.org/schema/beans/spring-beans-2.5.xsd" target="_blank" rel="nofollow">http://www.springframework.org/schema/beans/spring-beans-2.5.xsd</a> <a href="http://www.springframework.org/schema/tx/spring-tx-2.5.xsd" target="_blank" rel="nofollow">http://www.springframework.org/schema/tx/spring-tx-2.5.xsd</a> <a href="http://www.springframework.org/schema/aop" target="_blank" rel="nofollow">http://www.springframework.org/schema/aop</a> <a href="http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">" target="_blank" rel="nofollow">http://www.springframework.org/schema/aop/spring-aop-2.5.xsd"></a> ... <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <aop:config> <aop:advisor pointcut="execution(* *..DAO*(..))" advice-ref="txAdvice" /> </aop:config> <tx:advice id="txAdvice" transaction-manager="txManager"> <tx:attributes> <tx:method name="insert" propagation="REQUIRED" /> <tx:method name="update" propagation="REQUIRED" /> <tx:method name="upsert" propagation="REQUIRED" /> <tx:method name="delete" propagation="REQUIRED" /> <tx:method name="list*" propagation="REQUIRED" /> <tx:method name="get*" propagation="SUPPORTS" read-only="true /> </tx:attributes> </tx:advice>

I've tried swapping parsers in and out of the classpath for the app servers, to no avail. But I figure this has to be a common issue. Are there any ways around this?

Thanks for the tip. It would probably mean digging into the JToolBar's ToolBarUI implementation to do something like that, but hey, I guess I'm up for the challenge.

Hi,

Does anyone know if there is a minimum size for JDialog that Swing itself enforces?

I am attempting to create a toolbar similar to one that you'd find in, say, Photoshop (the Photoshop tools palette, specifically). I want the width to be pretty narrow; like the Photoshop tools palette, it should be just two small buttons wide. When my toolbar is "docked", the width is just the way I want it. But when the user drags the toolbar away and it becomes floating, the width is too wide, despite my best efforts.

As an experiment, I also created a simple app with a JDialog, and set the JDialog's preferred, minimum, and maximum width to 20 pixels (IIRC, JToolbar uses a JDialog instance when it becomes floating). However, the JDialog still appeared much wider than that.

The same issue occurs for me in both Windows XP Java 5 and 6, and Mac OSX Java 5.

So does anyone know if Swing enforces a minimum size for JDialogs? And can anything be done about it?

Thanks in advance.

Hi,

I have a simple question for folks who have strong experience with using Hibernate. My question relates to best practices in terms of unit testing Hibernate code, particularly when the DAO pattern is used. In general, should unit tests be written just for the DAOs, just for the entities, or for both?

We are beginning a project, and I want to ensure that we provide good test coverage, while at the same time not spending more time than we need. I'd imagine that one answer to my question is "if you want complete coverage, then test the entity and the DAO layer", but I'm curious if, in practice, anyone has found it more efficient to omit tests for one or the other.

Thanks in advance!

Thanks for the responses; they help a lot.

I suspected that a solid understanding of detached objects would be important, so that will probably be the next area that I explore. Also, Mark, your point about swapping out UI implementations is well-taken; in fact, at some point I'm figuring I'll work it into a web application anyway.

I'm still in the learning phase of Hibernate; having gotten the basics down, I've moved on to figuring out some best practices.

The sample app them I'm using to explore Hibernate is a Swing app. I know that in the real world, most Hibernate apps I'll encounter will likely be web apps, but hey, this is how I decided to learn! That being said, I figured I should approach my sample app as if I want to implement it correctly for what it is: a potentially-long-running desktop app.

A primary difference between my app and a typical web app is the lack of request/response cycles. So I feel like I'm approaching unchartered territory when it comes to managing my Sessions. In a webapp, it seems that typically one Session per request/response cycle would be used, with the Session being closed thereafter. Entities wouldn't tend to linger in memory for too long; instead, the request would cause them to be fetched from the database, and the response would [resent them to the user. Session done.

With my Swing app, though, my entities will stick around in memory for quite some time. I'm trying to follow the recommendations of my (web-app-oriented) tutorials, and closing my Sessions after doing something meaningful (e.g. reading from or writing to the database). But I find it hard to avoid certain errors. For example, at the moment I am experiencing this one:

org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [com.me.movies.model.Movie#1]

when I call session.saveOrUpdate() on an existing Movie entity, that I had originally read from the database via an older, now-closed Session. I suspect that the new Session isn't aware that the Movie already exists, and thus is SAVEing rather than UPDATEing.

I've also been playing whack-a-mole with these guys:

org.hibernate.HibernateException: Illegal attempt to associate a collection with two open sessions

So with all that, does anyone have any best-practices for Hibernate Sessions with apps such as mine? Should I still be striving to close my Sessions after db reads/writes? Or should I consider the lifecycle of my Swing app to be equivalent to a session, and therefore open and reuse a single Hibernate Session for the life of my app?

Thanks in advance for any advice.

Threads and JProgressBars are tricky. They're tricky primarily because by their nature, JProrgessBars are used whenever some long-running activity is occurring (because the whole purpose of a JProgressBar is to inform the user of the progress of such an activity).

The root of the problem is if the activity occurs on the Event Dispatch thread, then calling a method to update the JProgressBar won't have any visible effect; the Event Dispatch thread--which is usually the thread that is tasked with redrawing the JProgressBar--is already busy with the activity. In your case, the activity is the for loop.

Your approach to forcing jProgressBar1 to repaint by using another thread works, but is considered "incorrect". Components should *always* be updated by the Event Dispatch thread, to ensure that data corruption does not occur. It's a little too lengthy to go into here, but you can probably Google "awt event dispatch thread" or something like that and find various discussions on the issue. Understanding the Event Dispatch thread is key to doing good Swing/AWT programming, particularly with an issue like the one you're describing.

The best approach is to have your long-running activity--again, the for loop in this case--execute in a separate thread. Then, you call SwingUtilities.invokeLater() to update your JProgressBar, something like:
new Thread( public void run() { try { for (int i=0; i <100 ; i++) { if(!(SwingTestView.cancel)) { SwingUtilities.invokeLater( new Runnable() { public void run() { jProgressBar1.setValue(i); Thread.sleep(50); } } ); } else { System.out.print("HAIII"); } } } catch (InterruptedException ex) { Logger.getLogger(AnotherClass.class.getName()).log(Level.SEVERE, null, ex); } }).start();
The call to SwingUtilities.invokeLater(Runnable r) puts r on the Event Dispatch thread, where it belongs.
[ December 10, 2007: Message edited by: dave taubler ]

I feel like I'm talking to myself here...

Anyway, in case anyone stumbles across this in the future with a similar issue, what I wound up doing is creating my own DataFlavor and declaring the data type as an ArrayList thusly:
DataFlavor widgetListDataFlavor = new DataFlavor(DataFlavor.javaJVMLocalObjectMimeType + ";class=java.util.ArrayList");
I soon realized that this would be tricky, since the JVM would serialize all of the widgets being copied. First, I had to go through and make all widgets implement Serializable (no big deal) and ensure that they all had serialVersionUID set. But soon I realized that my widgets weren't as decoupled from my app as I'd thought, and that I'd probably wind up serializing an instance of pretty much every class in my app. I started going through and marking some fields as transient, but for various reasons I determined that approach wouldn't work out.

I already have methods to output my widgets as XML, so that's the next and apporach I took. My DataFlavor now looks like this:
DataFlavor widgetListDataFlavor = new DataFlavor(DataFlavor.javaJVMLocalObjectMimeType + ";class=java.lang.String");
(changing java.util.ArrayList to java.lang.String). The data that gets copied is now--rather than an ArrayList of widgets--actually a String/XML representation of the widgets. When the user pastes, I do something like:
String xml = (String)clipboardContents.getTransferData(widgetListDataFlavor);
I then parse xml to derive the widgets to be pasted.

Alrighty, after some research, I'm going to create my own DataFlavor and specify that it's a JVM local type, via the DataFlavor constructor that takes a String that contains DataFlavor.javaJVMLocalObjectMimeType. It looks like that's the right approach to take, and we'll see if it solves by Leopard problem as well.