Claude Moore

Ranch Hand
+ Follow
since Jun 24, 2005
Claude likes ...
IBM DB2 Java Netbeans IDE
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

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) ?
6 hours 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...
7 hours 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.

8 hours 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.
1 day ago
I'm struggling to found a solution to a problem that I started to think it's above me. To be honest, I wonder if the problem itself is well-defined and it makes sense.

Scenario: I'm gonna build a large application based upon spring boot. I will use several Services, and , to avoid strictly coupling beetwen services, besides heavily using interfaces i want to slice the whole codebase in more maven projects.
I will have a core project in which I will define all business interfaces (which will be implemented by @Service classes), value objects and some commons utilities, plus a number of separated projects where I will implement actual services and that will act as application modules.
Each single "application module" will depend on "core" module, and the whole resulting application will ultimately be composed by both core and  application modules.

The key idea behind this approach is to "start monolithic, and be prepared for microservices".
I want to be able, eventually, to deploy each application module in a separated JVM (if necessary, of course) with minimal efforts.

Because each service will inject interfaces and it will always have the core module as dependency, where all interfaces are defined, at least at compile-time I could separate modules without any issue.

The problem of course it's at during runtime because I cannot find a way to :

- autowire a "local" implementation of a given service interface,  if it's available in the application classpath;
- autowire a remote proxy for a given interface, if no implementing class it's available in the application classpath.

So I have two question for you, guys:

a) what do you think of the whole approach ?
b) do you have any advice about the problem of developing a "dynamic autowiring" mechanism ?

Thanks in advance !

2 days ago
Being stick to really obsolete java version is a problem. Anyway, I wonder if the adoption of a really fast update pace will be an advantage for Java. We're passing from a situation where Java changed really slowly, to a scenario where Java 9 isn't widely adopted yet and I already hear about Java 10...
Believe it or not, the project is STILL stuck at design stage. It has been suspended and resumed I cannot count how many times. By the end of next month, I should present a 'definitive proposal' of the general architecture of the project. Meanwhile, I observed how microservices architectures evolved, but at the very end I don't think that we will adopt this architectural style, at least not immediately. Main goal is to keep modules loosely coupled as much as we can, but the effort needed to adopt a 'pure' microservices-based approach (which implies to deal with multiple, maybe containerized applications, single simple applications )  exceeds the benefits we'll be able to get, being a rather small team of developers. So, more likely, we will adopt Spring in a monolithic-old-styled application, taking care to avoid as much as possible strict coupling between software modules.
1 month ago
Interesting question. My humble opinion is that no ANN or other deep learning algorithms are really needed to try to predict the outcome of a football match. What do you need, generally speaking, is a way to measure how much a football team is strong in a given moment of the championship, and, because I don't think that the ability to play football can be measured in absolute terms, you need a way to measure a team strength with respect to competitors. Somehow similar to ELO points used in chess. ELO points are based upon the concept that the more the difference of ELO points between two players is,  the more likely is that the player with higher ELO score will win the match. ELO score is adjusted after each match: you get an increment or a decrement of your score proportionally to the difference of your ELO and your opponent's, so that you won't get many points if you are strong and defeat a weak opponent, while you will loose more points if you are defeated by a weaker opponent.
Building an ELO-like score may be enough, and you may try to create such rating by a) assigning  to each team an initial score b) update for each team its score using the recent historical series of match outcomes.

Tim Holloway wrote:

If STS is an Eclipse plugin, then there's likely an OSGi bundle involved.

Yes, it's possible; anyway for what I have read, OSGi and Spring don't play well together.Some times ago, Spring offered Dynamic Modules (or a similar name, sorry I don't remember well), but for some reason that package was deprecated.

Tim Holloway wrote:
I haven't had that much problem with Docker myself.  Using the "docker exec" command I can get into most containers and diagnose problems. The worst cases are the really minimalistic ones where you need netstat or curl and they're not installed and neither is the package manager. The cure for that is to use the offending container as a base for a self-designed container that has the necessary tools installed.

I agree that docker it's an excellent way to deploy applications in a 'controlled' environment. I think it's a bit overwhelming -at least for me, but at the very end it's all matter to get in the habit of using it - during development stage, especially when compared do sping dashboard - really, really fast.
A little weakness I see in Spring Boot is that it's too much cloud oriented. Ok, this may seem a total nonsense, but I personally miss something similar to old fashioned "application containers" like appserver are:a place where you can deploy, start, stop, update your applications - in this case, your spring Boot applications. I tried to use an external Tomcat as container, an approach that worked but gave me the feeling I forced the hand a bit. Spring tools suite (STS) offers an excellent Dashboard to collect, run, restart spring Boot apps, but unlikely it is provided only as eclipse feature, it's not something you can run in production. And with docker containers, development is all but straightforward...This is why using an osgi runtime like Apache Felix seems appealing to me.
Reading here and there on internet about microservices architectures, I sometimes read some articles (or blog posts) where this or that guy suggest to start your path towards microservices based architectures using OSGI.
I have to admit that there aren't so many IT architects suggesting OSGI nowadays. You know, usually when you heard about microservices and Java platform, you have to expect to hear about Spring boot.
Honestly, Spring Boot is definetly a very important, if not the most , player in microservices world; so I was initially a bit puzzled reading about OSGI as a viable approach, but the more I think about it , the less I think it's a bad idea.
With OSGI, one could develop a single microservice as a bundle; the OSGI platform (when well used) forces you to keep your code as more modular as possible.
Moreover, withing an OSGI container you have dinamic modules, you got hot redeploy feature for free, you can let the single bundles exposes services communicating each other easily and in a clean way (without going with REST even for "internal" communication) and so on.
Of course a similar approach would not be considerated koshir: for example all of your services would run in a single JVM, they may be more strongly coupled than they should be, but nevertheless OSGI may be a way to go.
Main drawbacks I can see is that OSGI isn't so much popular nowadays and, with respect to Spring, seems to be less "modern" and up-to-date. Moreover, the learning curve is steeper (at least in my opinion).
What do you think, guys ?

Welcome to the ranch!
Did you configure tcp IP transport settings in Websphere to listen to 9080 port as well?
1 month ago

Campbell Ritchie wrote:
Several people gave a better answer still, “Don't take a job there.”

Well, a riddle is a riddle after all...I suppose that  no one in real life would write such a tricky code !
Recently I came across this question on twitter:

"Javascript expression (a==1 && a==2 && a==3) could ever evaluate to true ?"

The answer was clever and elegant - and yes, definitely above my knowledge of JS 

I thought it would be nice to propose the same riddle here...
During a software selection process done for a customer, I've seen a vendor candidate  (not sure I can name it, sorry) offering a "web based access" for its application - a traditional Windows Desktop application. In a nutshell, the user would be able to use the very same client via web browser, and I guessed that some kind of "rendering machine" was running under the hood.

Just for sake of curiosity, I'd like to know if anyone here may have a more precise idea about a similar techology. Is it just a proprietary software solution, or does exist a general purpose desktop-to-web renderer in commerce ?
2 months ago