Help coderanch get a
new server
by contributing to the fundraiser

E Armitage

+ Follow
since Mar 17, 2012
Merit badge: grant badges
For More
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 Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by E Armitage

Welcome Sam Newman! Following up on Stephan's comment and reference to Martin Fowler's monolith-first suggestion, does your book or other publications address how to identify the bounded contexts upon which to slice the application when the application is being developed from scratch?

8 years ago

Akaine Harga wrote:..
You mean I should forget about property binding and manually use jQuery for data fetching and view updates? And that without mentioning the stateless views. But wouldn't that multiply the required time for coding, code complexity in several times and render the best JSF's feature (variable binding) just useless? I'm not entirely against the idea, I just need time to get used to it, I guess.

As I said, you use that approach for pages that require that approach not for the whole application.

Akaine Harga wrote:
Actually, guys, one of the purposes of my post was exactly this:
Is JSF (or any other "automated" WebMVC) good for heavy views? Or am I actually hitting the limits here? I was considering to move to JavaFX8 for some time by now. As far as I understand I won't have any of these problem there. Or even forget Java completely and move to .Net SOA based apps. Because the idea of spending weeks of jQuery coding for a relatively simple functionality doesn't appeal to me as the most optimal (time/cost) solution.
Any thoughts?

I don't know what heavy views means here but generally JSF is very good for views where users capture data and you need to keep state in various scopes through their interaction. If your pages are only displaying data with no state being maintained e.g dashboard views, public websites, e.t.c then you are better off using stateless frameworks (JSF 2.2+ is trying to support more stateless paradigms as well but obviously not as mature as purely stateless frameworks). With any framework, the way you use it determines if you are going to spend weeks on technical code vs business logic.
9 years ago
I would suggest that you create a class that holds all that data you are passing to your page so that you only set one attribute (they are all related if you think about it).
Then as to your problem, does the productlist JSP display some parts except for the data part or is the whole page failing to display? Are you able to access any another attributes you are sending apart from the productList?
9 years ago

Akaine Harga wrote:..The apps look nice, they require little coding, but they are slow. And with the Internet connection becoming faster each year people will start complaining more and more..

First do some measurements to confirm that it is really JSF which is slowing down your application rather than something else which won't become fixed when you stop using JSF.
9 years ago

Monica Shiralkar wrote:

Your relationship should really be owned by Product

I did not understand what does 'owned by' means over here.

The owning side is very important to decide in any mappings that you do. It is the entity where the relationship is defined and more importantly for XtoOne relationships it's the side where the foreign key will be created in the database. For your tables you will have a Product table and a category table. there will be nothing in the Category table that says that this table is related to the Products table. The products table will have a foreign key to the Category table. So the Product table owns the relationship. If you use a bidirectional relationship the Category side of the relationship must state that it doesn't own the relationship by specifying the ownedBy property pointing to the Product which owns the relationship.

Monica Shiralkar wrote:

Your relationship should really be owned by Product

. My main confusion at this stage is that how to decide whether bidirectional relationship should be used when the same thing is being achieved in unidirectional mapping too. Is there anything which cannot be achieved in unidirectional mapping which can be achieved only using bidirectional mapping? As per the discussion so far in this thread we have talked about no such thing which is possible only in bidirectional and not possible in unidirectional mapping.


If you have a bidirectional relationship you are able to do both product.getCategory() and category.getProducts(). With a unidirectional relationship you can only do one of those.
Your relationship should really be owned by Product (it's the one whose table will have a foreign key to category ). In my reply I had assumed that that's where it is and I see now that it isn't. So unidirectional relationship will be on the Product entity. Then apply the statements I said above.

sanket jani wrote:sorry but its a html page not JSP

So use action as "../Registration"
What happens if you change your form action to "${pageContext.request.contextPath}/Registration"?

Monica Shiralkar wrote:
So if he adds products, the parent (Category) should also be saved.I want to use the cascading such that on saving the child table, the parent too gets saved.(cascade = CascadeType.ALL)

That's taken care of by cascade regardless of whether your relationship is unidirectional or bidirectional so don't use the cascade requirements to decide whether your relationship should be unidirectional or not. Rather think about how you are going to be using this relationship in your application.
Will you be needing to have/use a method category.getProducts(). If you do then you need your category entity to know about products, if not then you don't need a bidirectional relationship.

Marsoni Hutao wrote:
In Servlet i initialized an object

You should not have instance variables in Servlets so you should create that object in the doGet or doPost methods and use it there only. You must not assume that new requests will use the same Servlet object with state from previous requests.
In that case you would need to first where your JMX application is going to live, will it also be a standalone java application or will that be deployed to some container.
Then to monitor the desktop application is pretty similar to monitoring an application deployed in a server. In both instances you need to make sure that the java command was started with options that enable JMX (remote) monitoring.
You would only be able to access MBeans exposed by the Java runtime in a standalone application (what you would normally see using jconsole) so if you need extra info/methods to be exposed you would have to change the application you are monitoring to add the required mbeans.
9 years ago
Instead of fetching records into your 'box',s memory, rather create a database instance on that box and setup replication so that your box is a slave that gets updated with data (setting this up is trivial for databases like mysql ). Then use database mechanisms to build the report and write it to disk.
9 years ago
you should not be including any jars that implement servlet specification inside your application. The exception says that you have a jar geronimo-servlet_3.0_spec-1.0.jar in your application.
Also Tomcat 6 implements the servlet 2.5 specification so you better not be trying to use servlet 3 features with it.
9 years ago
Did you actually deploy the application from eclipse? Right Click ->Run As->Run on Server -> Select Tomcat? Also check your logs/console when you do this to see that the application is actually deploying successfully.