Comments for Objectopia

Comment on Weld JUnit 4 Runner by Dominik

Dominik — Wed, 20 Feb 2013 15:25:50 +0000

Thanks for that post! One question – I have simple maven JavaSE project which only prints Hello World on the console via an inject. When executed inside eclipse with a run configuration in which I specify the main class org.jboss.weld.environment.se.StartMain the program works just fine. However, when I executed a “mvn compile test” it fails. Why? I use the exec-maven-plugin to specify the mainClass for phase test/goal java.

Running asd.MainTest
23 [main] INFO org.jboss.weld.Version – WELD-000900 1.1.10 (Final)
114 [main] INFO org.jboss.weld.Bootstrap – WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
348 [main] WARN org.jboss.weld.interceptor.util.InterceptionTypeRegistry – Class ‘javax.ejb.PostActivate’ not found, interception based on it is not enabled
349 [main] WARN org.jboss.weld.interceptor.util.InterceptionTypeRegistry – Class ‘javax.ejb.PrePassivate’ not found, interception based on it is not enabled
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.541 sec <<< FAILURE!

Results :

Tests in error:
initializationError(asd.MainTest): Index: 0, Size: 0

Comment on Securing your JBoss JMX Invoker Layer by CVE-2009-5066 (jboss_community_application_server, jboss_enterprise_application_platform) | Web Security Watch

Tue, 25 Sep 2012 20:37:15 +0000

[...] Source: MISC Name: http://objectopia.com/2009/10/01/securing-jmx-invoker-layer-in-jboss/ Hyperlink: [...]

Comment on Calling Stored Procedures in JPA by amazon

amazon — Sat, 24 Mar 2012 09:05:54 +0000

amazon…

[...]Calling Stored Procedures in JPA « 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.