Win a copy of OCP Java SE 8 Programmer II Exam Study Guide this week in the OCP forum!

Claude Moore

Ranch Hand
+ Follow
since Jun 24, 2005
Claude likes ...
IBM DB2 Java Netbeans IDE Spring
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Claude Moore

Hi Elizabeth,

the Eight Puzzle may have no solution at all, so no matter if you implementation is or is not correct, execution would end in an endless execution.
Googling a bit you can find that there's an exact algorithm to verify if an Eight puzzle is solvable or not - basically, you need to verify how many tiles inversion you have in the start state.

I suggest you, just to check if your algorithm implementation is working, to start from the final state (i.e, the solution) and apply random moves to tiles. This way, you will end having a "start state" that necessarily is solvable.
Hence, you can apply your algorithm.

Hope this help !

PS. For moderators: this topic should be moved to AI forum.
2 days ago
I think I've found a solution myself.

My mistake was to believe that a JTA Transaction manager will always use a XATransaction when using XADatasource. But that assumption is false. An XADatasource is only capable of support XA Transactions, but also can be used within a local transaction as well.
Moreover, using a XADatasource doesn't imply that the Transaction Manager is aware of it. One has to wrap the specific XADataSource for a given Database using an helper class that is able to enlist a connection (or better, a resource) within an active transaction, otherwise datasources will be treated as non-XA resources.
That explains why I need to use an AtomikosDataSourceBean to wrap an underlying MySQL datasource.
Exactly the same results are achieved with Bitronix implementation of a XADatasource wrapper; if I wrap my datasource using PoolingDataSourceBean (provided by Bitronix library) I get the warning "executing transaction with 0 enlisted resource " go away.

1 month ago
I need your precious help to understand how JTA transactions do actually work in Spring Boot; no matter how much I try, there's always something that sounds weird to me.

As you may know, with Spring Boot you may use one of the supported out of the box JTA transaction managers, namely Atomikos, Bitronix and Narayana, simply adding a spring-boot-starter-jta-xxx dependency in your POM file. This way, SpringBoot automagically wires all required beans
to run a JTA transaction manager. Because I need more than a single Datasource, I cannot simply use "default" JPATransactionManager . Under the hood, I'm going to use Hibernate.

First, I've defined my Hibernate configuration this way:

where CustomJTAPlatform is the following helper class, aimed to provide to Hibernate a reference to actual Transaction manager and UserTransaction istances (actual instances will be provided by spring jta starter package via autoconfiguration)

The following pieces of code define datasources and EntityManager configurations:

Last, in a service class, I delete and persist a simple Entity (Person) on two different databases, in a transactional way:

The above code actually works; data are committed and if I throw an exception after the second savePerson method invocation, data are rollbacked. The problem is that I can't understand what really happens. For example, if I use Atomikos JTA provider, I can read in the logs:

And this makes me think that a transaction is used.  Now, if I change my Datasource definition using an AtomicSpecific wrapper for XA datasources:

I get a long log list where XA resources are enlisted.

This fact makes me think that here I have a XA transaction, while, in the first case, despite the fact entities were committed or rolledback, a local transaction took place, not an XA transaction.

This hypotesis seems to be confirmed if I change Atomikos with Bitronix : the log is more explicit:

It's obvious that, even entities are persisted, only a local transaction is performed.
Can anyone help me to understand what I'm missing ?

1 month ago

Joshua Bloch wrote: I think it (the language, not the trademark) is more popular on the client side than it's ever been before, thanks to Android.

You're right ! Not being an app developer, with 'GUI side' I still mean only desktop applications.... My fault.
Thanks for the reply !
1 month ago
Hi Joshua,

in your opinion what features Java language should have that have not  still added ? 

Thanks in advance.
1 month ago
I take advantage of this interesting Bear's question to ask you if you think that with Java "withdrawal" from GUI side of application, in favour of a mainly server-centric usage, may or not slowly undermine Java's popularity in favour of other language runtimes.
I'm thinking about the rise of Node.js (or similar technologies) which allows you to use the very same programming language on both server and client side (the so called isomorphic applications).
1 month ago
I'm afraid that Java for desktop application  is fading away rather quickly.
If you build desktop-based apps, you need a way to deploy and update them without much effort. If I'm not wrong, even Java web start support will be dropped in the near future.
1 month ago
Honestly, I'm not really happy of the name change, but that's a matter of personal taste. Java is a language more than twenty years old, and in my humble opinion Jakarta EE isn't an attractive name (or brand, not sure how to define it): it makes me think back at Java origins, when most - if not all - of the most promising and innovative project  in Java ecosystem were hosted at Apache Foundation.
Something linked to a far past time.
I would have preferred something more brilliant... as I said before, these are just my humble opinions.
As far as I know,  there are three ways to define Producers for a given bean:

a) you can annotate with @Service a POJO, and the POJO would be produced as singleton

b) you can define a Bean , annotate or not with Component (or other specialized annotations), and define a producer method in a @Configuration annotated class:

c) you may define a FactoryBean<T> extending class

What are, if any, the key differences between these approaches ?

2 months ago

Tim Holloway wrote:Yes, if you introduce a custom bean factory into your mix you can make it decide whether to return a remote interface object or a local object, sure. No problem.

Thanks. And  does the returned bean follow the whole lifecycle of a "normally" injected bean ? (i.e: could its methods be declared @Transactional, can it have a scope etc) ?
2 months ago
Initial typo apart, the following code:

Of course the injected object IS an instance of the class SampleService - no abstract objects at all.
A more complex use case may involve a FactoryBean:

Sorry if I bother you...
2 months ago

Tim Holloway wrote:
The one thing that did stick out is your confusion about auto-wiring local and remote interfaces. Spring is based on a bean factory and wires bean instances. You cannot manufacture and instantiate an interface, only a bean that implements that interface. Likewise you cannot inject an interface. An interface is an abstraction and Spring deals in concretes.

I admit that i'm rather a newbie with Spring, so that terminology I use won't be the best, but I suppose that working with interfaces instead of wiring directly concrete class is a paradigm that Spring supports well (even if I don't know if encourages to do so).
I'm afraid that what I'm trying to do with Spring may not be a good programming practice, so please help me to better undestand.

Let's suppose I have a trivial class which extends an interface:

In Spring I can inject a concrete instance of SampleService , but at the same time, I'm formally  working with an interface:

and AFAIK this code is perfectly valid. What I want to achieve is a way to inject a different concrete instance of ISampleService dinamically, and treat my services like "plugins" so that:
- if a concrete class is available in the classpath of my application, a concrete local instance will be injected;
- otherwise, a stub to call remote instances will be created (and injected)

Is there anything wrong with this ?

Thanks in advance.

2 months ago
Pete, thanks for your reply and for your advices. Starting with microservices is intriguing, but honestly I prefer to begin with the old fashioned monolithic approach, as Martin Fowler suggests to do. Starting with microservices would not give me many advantages: the project will be made of of rather strictly dependent modules, and honestly I'm afraid that orchestrating all modules as microservice already at time zero would be an unuseful approach (at least for mine scenario). At the same time, I cannot ignore that modularization of moder software is a must. So I'm trying to organize my codebase accordingly with modular software principles.

Good idea to use JMS for integration. I think I'll use an AMQP-based RPC schema between modules (when modules won't be co-located in the same JVM, of course). I dropped the idea to use REST-based APIs even for modules intra-communication. All modules are going to be written in Java language, so I can't see the point to use REST API; moreover,  whenever modules will be deployed within separated JVM instances, I think that they will be deployed in the same LAN (with very low latency), so using a lightweight communication protocol won't be a key requirement.

Thanks again for your help.
2 months ago