bernard amadeus

Greenhorn
+ Follow
since May 15, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by bernard amadeus

Matthew Brown wrote:Usually you wouldn't extend a Singleton class. In fact, usually a Singleton class would be designed in a way to prevent it being extended, in case extending it was used as a way to create multiple instances.


I think that the definition of a Singleton as having only one instance is misleading: better say that only one combination of values (object "state") is involved in methods implementation.
So curiously you can create a Singleton that is implemented without the calling code being aware of this property: the different instances created by client code all delegate to a single object!
and yes you can create subclasses of this façade.
12 years ago
Hello
(I'm a Groovy newbie)
by reading a groovy grammar (http://groovy.codehaus.org/jsr/spec/GroovyRecognizer.html#argument)
I do not understand the "argument" production
apparentlty there may be something like "*:" as a label .... seen nothing on the web to explain the meaning of that ...
any hint?
thanks
12 years ago
may be this already exists (I am a JMS newbie)

when receiving a message through JMS it may happen that your machine does not have the corresponding class.
is there somewhere a mechanism through which you can obtain dynamically the corresponding class and thus deserialize properly an object you receive?

(this is done for example in other technologies like JINI: for sure I could copy this but surely someone has done it already for JMS!)

thanks

Paul Clapham wrote:

bernard amadeus wrote:does it make sense?



Before we answer that, it would be necessary to understand what problem it was trying to solve. In other words, why bother? If it would solve a problem which the regular JNLP design doesn't solve, then we could discuss whether this was a good way to solve that problem.



sorry : jnlp does it perfectly and rather simply I just was not aware of it! thanks for the challenge!
13 years ago
Apparently I was not clear enough ... so let's start again.
A client machine wants its application to be up to date thru jnlp...
now it uses it "offline allowed" that is: it is possible not to have a connection to the server (for different reasons) so it happens that http connection is off.
you can use a jnlp descriptor that is fully deployed on the client machine (a jnlp file that can be "clicked" by the user)
ok 1?

now: this jnlp file is almost a copy on the one on the server: it describes all the resources needed.
if there is no connection javaws finds the resources in the cache.

ok 2?

remark: on the server you may need to change the needed resources as the application evolves... sounds logic?
naïve conclusion: it could be a good thing to have the jnlp file on the client dynamically updated ...when the connection is on (or so I think).

. In other words, why bother? If it would solve a problem which the regular JNLP design doesn't solve,


sorry I have a knack to ask irksome questions ...
13 years ago
Here is the idea:
- have a jnlp file on "client" and one on "server": offline allowed
- you can have a jnlp file on a client machine that just references the jnlp file on the server (no detailed resources description)
- the jnlp file on the server has all the resource description needed

it does work :
advantage: you maintain the resources on the server only (the jnlp file on client machine is minimum)
drawback: if the server is offline it does not work anymore

so : is it possible to have a complete jnlp file on client machine (that describes all the needed resources) and that this file is updated through jnlp itself?
(that is you download and maintain the jnlp client through Java web start)

does it make sense?
how to do that?
thanks
13 years ago
Hello all
I like the idea of splitting an application between distinct jars ... (details are beyond the point)
I like the idea of jar index: a "master" jar has a table that links a particular class to a specific jar
so this is supposed to help when dealing with multiple jars (let's say across a network) : the classLoader may load only the needed jar at runtime
(or so I suppose)
now: what if in this "master" jar there is a code that looks for a "service" (through the ServiceLoader architecture) ?
so now the ClassLoader will be obliged to scan all jars in the Class-Path of the master ... does not that defeats the above-mentionned strategy ?

thanks
13 years ago
well, well, come on experts! greenhorn only hears silence
I know I often ask questions that are not mainstream and so I get only puzzled looks
what could look "logical" for me :when an entity has a field which is a value object the fields of this member
are uploaded from the base and the correct constructor for this member is called (introspection at this level is not extraordinary difficult).
Is there something for this in JPA and implementations?

Birla Murugesan wrote:
But, In Sun java ApI docs itself recommended to use split method of string instead of StringTokenizer

what you say?



I say this: doc recommendation is misleading : try to parse something which has two consecutive "space" characters ...
split used indiscriminately and StringTokenizer won't yield the same result.

so my advice: if you just parse simple "space separated" String use StringTokenizer (using advanced pattern on split is just too cumbersome).
14 years ago

Cameron Wallace McKenzie wrote:
It has to get initialized at some point. The code you currently have must initialize it at some point. When does the current code do it? Just do it the same way.



well, as described before, the initialization takes place with the "normal" constructors (two args at least!)
since both instance members are final they have to be initialized by every constructor.
since java.util's BigDecimal and Currency have no default constructor you can only build the object by providing correct arguments to the
constructor (let's say two Strings, or two Strings and one Locale).

So let's summarize again:
- here we have an Object which is part of the persistent state (though not an entity)
- there is no way to have a no-arg constructor (or fancy "setters")
- for other reasons I am NOT going to change the final status of these members (hey aren't we supposed to use normal objects?)

now what is the theory behind the use of such objects ? there has to be something since this kind of situation is common
(when you use value objects ... OOops the term escaped from my keyboard )
- again Serialization does it no questions asked ... for sure persistence addresses different problems (such as lazy loading of values)
but the loading of such a "value" (Ooops again!) could be declared atomic, in fact tools do this for BigDecimal why not for user-defined
classes?
let's skip pesky details such as the fact that new BigDecimal() does not exist ... what is to be expected?
that the no-arg contructor is called and that later some real value for the BigDecimal will replace the bogus one?
strange!
after all the Serialization mechanism does handle this pretty well so why persistence mechanisms have to be byzantine?

Cameron Wallace McKenzie wrote:I'd be interested in seeing the exact problem. final variables can be persisted by Hibernate, I do believe. Obviously you have a challenge of initializing them some place, but doing it in a private constructor would suffice. So, with that tweak it should work. (You may need to add a private setter/getter, where the setter does nothing.)

I'd be interested in any exceptions or error messages that elute.

Good luck, and keep asking questions, Greenhorn!

-Cameron McKenzie



urgh how would you design such a constructor ? :


Very green Horn!

Cameron Wallace McKenzie wrote:I think Hibernate will save it even with the final variable. The data is still there.

Give it a try and see if you get any errors.


well I don't touch powerful magical wands ... only my friend does .... and must use JPA.
does not work there.

edit: but I am interested by the theoretical aspects of the question !

Cameron Wallace McKenzie wrote:One approach would be to create a private constructor and even some private setters for the variables. Hibernate needs a constructor, but it does not need to be public, so it will be shielded from the world.

-Cameron McKenzie


a private constructor for Price?
but since members are final you will be unable to create Price() ?

I suspect that in such cases of "values" (Oops sorry escaped me ) the columns of Price get added to the colums of Product ....
how do you do that properly while having final members?

Cameron Wallace McKenzie wrote:

Are these really value objects, or are these all part of your core domain model? Price is really a core element of your domain. I don't think it's a value object, right?

-Cameron McKenzie


I will not argue about the christening of the thing .... just as an example a Product has a Price (implemented as a special class).
members of Price are final (and should be for different reasons ... again beyond my question)
now how do you design the persistence of Product ?