Comments for Objectopia

Comment on Hibernate and sets – use at your peril by Chris Clark

Chris Clark — Tue, 06 Dec 2011 08:48:38 +0000

Hi Christian,

Thanks for the comment, I’m humbled that someone such as yourself would take the time to respond. Like you say in your blog mapping a collection is a feature and what I’m pointing out in this post is that using this feature has a side effect, which I’ve not seen documented and it can have some massive performance overhead. I don’t see why when using a ORM I should loose the ability to treat objects as objects without having to call a DAO to get related objects.

Thanks

Chris

Comment on Hibernate and sets – use at your peril by Christian Bauer

Christian Bauer — Tue, 06 Dec 2011 06:46:26 +0000

“I understand why sets are used”

I’m not sure you do. There are two reasons why you’d have a @OneToMany(mappedBy):

You have a legacy Java codebase or bad architecture and you HAVE to iterate through a collection of TaxComponents, you can’t execute a query (call a DAO method) to access that data.

The second reason is that you can do some fancy query tricks (batch fetching) with such a collection. As you are having problems with queries, well, let’s just say whoever created the @OneToMany probably didn’t think about that either.

So remove the @OneToMany and the collection. It’s not doing you any good and it’s not necessary (mappedBy).

See: http://in.relation.to/1395.lace

Comment on Weld JUnit 4 Runner by Ales

Ales — Tue, 31 May 2011 10:16:20 +0000

It’s just a matter of adding the right (additional) deps to the classpath.
Wrt the test, it’s pretty much the same, WeldJUnit4Runner –> Arquillian.
While then you can properly test your stuff, not just in mock-ed up embedded Weld container,
but real runtime env; JBossAS, GF, Tomcat, Jetty, … all with exactly the same code.

But that doesn’t mean I don’t like how you did it, as it nicely shows true power of JUnit and CDI.

Comment on Weld JUnit 4 Runner by Chris Burnley

Chris Burnley — Tue, 31 May 2011 10:08:14 +0000

I could … but why bother making something simple complicated ?

Comment on Weld JUnit 4 Runner by Ales

Ales — Mon, 30 May 2011 13:34:22 +0000

Or you could use Weld + its Arquillian container.
A bit more work wrt jars + classpath,
but you could then easily pass the same test around between diff containers.

Comment on Securing your JBoss JMX Invoker Layer by Technical Related Notes » Blog Archive » links for 2011-03-22

Technical Related Notes » Blog Archive » links for 2011-03-22 — Mon, 18 Apr 2011 09:59:19 +0000

[...] secure jboss (tags: jboss) [...]

Comment on Securing your JBoss JMX Invoker Layer by Slava

Slava — Sun, 03 Apr 2011 04:34:03 +0000

for those who find this topic by search: There is a community courtesy notification for a severe security issue affecting some of the JBoss projects and products. Default security settings in web.xml protect only GET and POST protocols leaving another ones open. Please refer to the following Red Hat KBase article for more information: JBoss Products & CVE-2010-0738 Only when you apply the solution you can be sure that your JMX Console is protected. Please note that Web Console has the same issue, and you need to apply the solution to it as well. Also it is recommended to hash passwords in the config files. Read about how to do it in JBoss Getting Started guide.

Comment on Calling Stored Procedures in JPA by Java Developers: Make the Database Work for You! « AMIS Technology blog

Java Developers: Make the Database Work for You! « AMIS Technology blog — Wed, 12 Jan 2011 09:43:25 +0000

[...] http://objectopia.com/2009/06/26/calling-stored-procedures-in-jpa/ [...]

Comment on Joda with JPA by skhanzada

skhanzada — Sat, 28 Aug 2010 05:38:39 +0000

http://skhanzada.wordpress.com/2010/07/29/hibernatejpa-annotations/

Comment on Securing your JBoss JMX Invoker Layer by Jon Court

Jon Court — Sun, 28 Feb 2010 00:22:19 +0000

Nice – thanks for picking this up Gilles,

I had meant to contribute this back actually – somehow it dropped off my radar.

Regards,
Jon