Cor Takken

I think you can clarify your question even more if you can show us the code snippet showing where you persist your parent and particularly where you place the child "in" the parent... And perhaps some of the setter methods of the child, but that depends on how how link the child to the parent.

Richard Reese wrote:Cor,

I share your frustration. Sorry but the book does not contain that information. Netbeans and Glassfish were used for the examples and there are some details on how to use these tools. Other than those two products there is nothing that would point you to other products.

Hi Richard,

Well... it was more like wishful thinking than real expectations. I will look out for your book at my local supplier.

Hi,

In the last year or so I have tried to make JMS connections happen on various application servers. However I have found that for various application servers the setup of JMS is not always as straight forward as I was expecting it to be.
By spending a relatively huge amount of time searching the manuals of the writers of the application servers and another huge amount of time using google (other search engines also available) I have found that there is very little specific information available. Does your book have a section with suggested "search engine magic words" and links to the websites of application server producers, so that those people who want to look for more specific information can find it (and with that save a lot of time and frustration)?

I understand that you are focusing on EJB3.1 and cannot explain the implementations thereof on all available (or major brands of) application server, but I think your audience would appreciate any help for their specific brand of app. server.

Thanks and good luck with the book.

Cor

I appreciate the huge amount of effort that must have gone in the writing of the book. Looking out to reading it.

Kind regards,

Cor

p.s. this was meant as a separate entry in the "welcome"-thread, however somehow it seems to have ended up in the main EJB forum and I see no way of deleting an entry...

I think I have a case for my very own resource loader.
Let me first explain the circumstances:
I am working in an environment where information must be retrieved from a server which involves making contact with the server, sending over the request and then waiting for an answer. It somewhat resembles an RMI or webservice. I had a brainwave in which I thought: "Well, if I can direct file I/O by using the file: prefix, http by using the http: prefix why can't I make a resourcelocator which gets the response from the server as a resource reacting on my very own prefix (for the sake of argument I refer to that as 'myown:').

Now, making the class implement the ResourceLoader interface was absolutely no problem, however what I am now facing is how to get Spring to activate my own ResourceLoader implementation once it finds a resource starting with the prefix 'myown:'?

To be even more precise: I want to be able to configure the application context using XML, and within the context of Spring Batch. The reason for the XML-route is that this will make batch redesign more flexible (i.e. no coding and redeploying necessary).

I am fairly new with Spring, but searching the internet I get plenty references and hints that this should be possible, I have yet to find an example on how exactly to make it the way I want.

If anybody is out there willing to help or point me in the right directions I would be very thankful.

Kind regards,

Cor

Again, congratulations with the paper version of the book.

My question: In your view, what will be the next thing Camel will point its attention to to take it to the next level?

Finally, finally the Camel in Action book is available on paper! Congratulations to all involved. And congratulations to all who are not in the posession of an e-reader as this book is truely well written and the field Camel is used in is a very interesting one.

Great to have a book out on Hibernate. However from the extract given on Amazone, I could not find much added value from this book compared to other books already brought out. Surely you are able to tell us what sets this book apart from all these other books.
Every other book has an explanation on how 1:1, 1:n, etc. works, and an explanation on HQL, and so forth. But what is the added value which makes it work to go out and order this book?

Kind regards,

Cor

It is with great joy (and relief) that I see that Spring finally has seen the light and made a tighter coupling between definition (formerly only to be found in hardly readable XML files) and the Pojo. I was a firm believer that one of the greatest disadvantages of Spring (pre 2.5 that is) was the fact that the Java code was detached from one of the most influencial part regarding its behaviour (the XML which wired the components). Although I can see a valid point of those who say that this gives the framework the additional flexibility (e.g. to provide a separate test- and production-setup). In my view the disadvantages (wondering whether I had setup the configuration correctly, having to simultaneously view XML and Java, the additional maintenance) didn't weigh up to the advantages. However, these disadvantages have been reduced significantly.

Now for my questions:
- In what direction will the Spring framework be developed after 3.0 in the view of the author?
- What will the effect of the ever stronger growing EJB framework be on Spring and will Spring continue to add any added value besides supporting a large installed base?
- What licencing structure will Spring be available under? In the past this used to be a more or less GPL-typed licence.

And to be complete: here is the answer as given by mr. Ed Burns:

Cor Takken wrote:I am a firm believer in separating the presentation layer from the calculation layer. (As an aside: I acknowledge that there are more official terms for these principles, however for the sake of argument I will use these terms). In that believe I have a bit of a problem having for-loops, if-constructions etc. in the presentation layer. This makes the presentation layer no longer pure presentation but now also contains some form calculation and that has a risk of creap (pun intended) of business logic in the presentation layer. However, this I have noticed in the field that this creep is commonplace in JSF and I (will have to) accept the fact that the presentation layer in JSF does contain some programming logic.

You are right to be cautious about using logic in Facelet pages. In fact, I have been touting the complete absence of scriptlets in Facelets as one of its selling points. There are still a few corner cases that remain unresolved in using JSTL conditionals or iterators in Facelet pages, mostly revolving around state that changes between requests. As far as patterns or practices to refactor an existing occurrence of the use of conditionals and iterators I do have some suggestions.

Let's take conditionals and iterators separately. First, conditionals. The most common use of conditionals is to show/hide portions of the page. This usage is generally safe, especially when you value bind to the view scope.

Next on to iterators. If at all possible, use ui:repeat instead of c:forEach. ui:repeat is backed by an actual JSF component, while c:forEach is a tag handler. Because ui:repeat is a JSF component, it does a better job of managing its state.

If anyone else has something to share on this, please do!

Thanks for your interest.

Ed

I am a firm believer in separating the presentation layer from the calculation layer. (As an aside: I acknowledge that there are more official terms for these principles, however for the sake of argument I will use these terms). In that believe I have a bit of a problem having for-loops, if-constructions etc. in the presentation layer. This makes the presentation layer no longer pure presentation but now also contains some form calculation and that has a risk of creap (pun intended) of business logic in the presentation layer. However, this I have noticed in the field that this creep is commonplace in JSF and I (will have to) accept the fact that the presentation layer in JSF does contain some programming logic.

Is there to the knowledge of the authors one or a number of patterns which will help us reduce the number of these constructions or helping the developers limitting these constructions to the ones which will have the least risk of changing once the application is in production? My fear (backed by some experience) is that when once an application is in production the impact of maintenance is worsened by the presence of logic in the presentation layer.

This topic is already answered in the welcome topic, however I would like to be eligible for the receipt of the book

Bear Bibeault wrote:
It is spelled out in bold text in the very first entry in this topic. I'm not sure how much more clear it could have been made.

Let us say that it wasn't that apparant to me. If it was there, my apologies (my bad).

Just click the New Topic button.

My suggestion: add that to the bold text, just to avoid any mistakes or assumptions.

Indeed. The book promotions on JavaRanch are very informative and useful.

And we are thankful for that

Bear Bibeault wrote:Please remember that this topic is for welcoming the authors -- not for asking questions. Please ask questions in a separate topic,

Posts in this topic are not eligible for the book promotion!

This is very regrettable, but the procedures do leave room to ask questions in all sincerity to be asked in this topic. I would like to offer a suggestion to mention this in the first 'welcome'-message with, if possible, a link to the correct topic or to the page specifying how to create such a topic. I asked my question in the honest believe that this was the correct procedure and regret that my contribution will not be eligible. On the other hand, I am very grateful for the honest and insightful answer the author has given me.

First of all: I welcome every piece of information regarding JSF, so I thank the authors for sharing their knowledge with us.

Now for my question: I am a firm believer in separating the presentation layer from the calculation layer. (As an aside: I acknowledge that there are more official terms for these principles, however for the sake of argument I will use these terms). In that believe I have a bit of a problem having for-loops, if-constructions etc. in the presentation layer. This makes the presentation layer no longer pure presentation but now also contains some form calculation and that has a risk of creap (pun intended) of business logic in the presentation layer. However, this I have noticed in the field that this creep is commonplace in JSF and I (will have to) accept the fact that the presentation layer in JSF does contain some programming logic.

Is there to the knowledge of the authors one or a number of patterns which will help us reduce the number of these constructions or helping the developers limitting these constructions to the ones which will have the least risk of changing once the application is in production? My fear (backed by some experience) is that when once an application is in production the impact of maintenance is worsened by the presence of logic in the presentation layer.

Thanks for taking the time to answer this question.

Cor

Okay,

Ahmed: You bring forward that Spring allows you to use IoC, AOP and Security. This however is now available through EJB3.0 as well (at least in a server environment). You can have the container inject resources, ejbs and loads of other stuff thereby effectively (in my view) establishing an IoC (or at least very near) situation. One has to keep in mind that IoC is a means to an end, not the goal. Security in a server environment can be established using JAAS; I am still trying to find the hooks into AOP. Here I have to conclude that my question has not be answered to the full yet.

Again: in a stand-alone situation Spring acts as the application container offering these services and that is very useful, my question was about Spring in a webserver. Which brings me to the following.
Vyaz: Aren't you just replacing the complexities of a webcontainer with the complexities of configuration in Spring? I can fully understand the choice in certain sitations.

Anyway, I am still very curious about an answer to my original question.

Cor