Wagner Danda Da Silva Filho

Originally posted by Anu Tilwalli:
The Enterprise bean environment mechanism tries to achieve which of the following objectives?

1) It allows to users of an Enterprise bean to customize its business logic without modifying the source code.

2) It allows an enterprise bean to modify its environment properties without knowing about them at the development time.

3) t allows an enterprise bean to customize its container in a standard way.

4) It allows an enterprise bean to locate external information without prior knowledge of how the information is named and organized in the target operational environment.

The correct answer to this question is 1,4.

Can anyone give me example of the 1. How can we modify business logic w/o modifying the code. Seconly, why is 2) not in the correct list. Are env properties same as env entries?

I've just stumbled upon the same question and I share the same confusion... Why option 1 is said to be correct? Is it really possible to an "application assembler" or "deployer" modify the source code of enterprise bean?

I guess the real question is the definition of the "customize an EJB business logic" statement... If you consider the fact that security and transaction attributes can be configured without modifying the EJB source code then that might be the reason for answer 1... Still not sure tough...
[ December 16, 2008: Message edited by: Wagner Danda ]

Thanks Guys for all your answers. I just asked those "naive" questions to confirm my understanding. When preparing for Sun exams I like to explore all possibilities I can think of.

Hi James, thanks a lot for you answer.

You explained what I really wanted to know... That although a session bean is marked as @Stateless it can still keep a internal state (instance variables) but that we all know that it should not be used as it cannot guarantee the same instance will service every time. Great answer, thanks.

Now I got another question on top of this one. Let's say I do use instance variables in a Stateless EJB (for any weird reason ). Is there a way to force the container to "reset" this bean to it's original state (whatever you call it, send it to the GC, de-construct it, etc...) so that the next time a request for that same EJB service is made the instance variable will be clean/reseted?

Think of a scenario where you use that variable to store some secure information and you want to make sure it will be deleted/reseted when the EJB service is completed...

Thanks a lot (again)!

Howdy Fellows...

I learned that a stateless session bean is not supposed to keep state between calls, right? So I did this quick test to verify that and I've found something weird...

Below is the code I used (a modification of EBJ3inAction chapter 1's example code)...

The Business Interface:
package ejb3inaction.example; import javax.ejb.Remote; @Remote interface HelloUser { void sayHelloSaveName(String name); }

The Stateless Session Bean:
package ejb3inaction.example; import javax.ejb.Stateless; @Stateless public class HelloUserBean implements HelloUser { private String savedName; public void sayHelloSaveName(String name) { System.out.println("Hello [" + savedName + " / " + name + "]"); savedName = name; } }

And here is the client code:
package ejb3inaction.example; import javax.ejb.EJB; public class HelloUserClient { @EJB private static HelloUser helloUser; public static void main(String[] args) { helloUser.sayHelloSaveName( "John" + System.currentTimeMillis() ); System.out.println("Invoked EJB successfully .. see server console for output"); } }

When I run this multiple times (inside Glassfish's appclient) here is the output I get is Glassfish's log:
[#|2008-12-15T14:17:36.790-0500|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=76;_ThreadName=p: thread-pool-1; w: 35;| Hello [null / John1229368656790]|#] [#|2008-12-15T14:17:37.118-0500|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=76;_ThreadName=p: thread-pool-1; w: 35;| Hello [John1229368656790 / John1229368657118]|#] [#|2008-12-15T14:19:32.915-0500|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=77;_ThreadName=p: thread-pool-1; w: 31;| Hello [John1229368657118 / John1229368772915]|#]

As you can see, the "savedName" variable is keeping the state although my bean is marked as @Stateless...

So, am I correct to assume that this is only happening because Glassfish is using a Object Pool (see the "thread-pool-1" string in the log)? Or is it really possible for a Stateless EJB keep it's state ?

I just want to make sure I correctly understand what a Stateless EJB can really do and what it can't do...

Thanks!
[ December 15, 2008: Message edited by: Wagner Danda ]

Considering a typical MVC web application like this:

Presentation | Controller | Service/Manager | Repository/Dao

What is the great benefit of having a "Service/Manager" layer to interface the "Controller" and the "Repository" layers?

What would be a typical example of a service provided in a "Service" layer? Let's say you answer "createAccount(...)" as a possible service, why can't this method be inside the "Account" entity itself? Too simple?

Okay, let's try something more complex... What about "generateInvoice(...)", that would require handling various entities, including "Client" and "Account". Couldn't that be in an "Invoice" entity?

The point I'm trying to understand is if I really need a service layer when designing a normal java mvc-based web-application (i.e. an online billing system).

Any insights?

Thanks,
Wagner da Silva

Josh, you may want to read this.

Originally posted by Gregg Bolinger:
This is like saying:

"I want to buy a house. Which one should I buy?"

There is absolutely no possible way to answer this question with the information given.

So which information should be given?

I think Josh wants to understand the differences between a lightweight framework such as Spring or Strut versus a more heavyweight J2EE with EJB... That seems to be a very interesting topic nowadays, specially considering the supposed "lightweight" EJB 3 available in the J2EE 5 specification.

Originally posted by Nguyen Long:
Dear Danda,

\server\default\tmp\deploy\

I deal woth this by apcking my app to an ear file, and above is a place where Jboss put tmp application file, you could copy and paste your changed jsp directly to that folder. (your application name will be tmpxxxxYOUR_APLLICATION_NAME.ear)

Thanks Nguyen. I understand your suggestion but I was expecting something more automated from Eclipse... What I expect to see is once I clicked "Save" in either a JSP (or a Java class) they would get automatically uploaded to JBOSS (I think this is called hot-swap).

Currently when I change a jsp or a java class Eclipse notice that and redeploy the two projects: an WAR file for the web project and a JAR file for the EJB. I've already tried creating an Enteprise Project that wrap the two projects and creates a EAR file, but the behavior is the same: redeployment of the whole project for any simple change (ie. change a comment in a log)! That really slows my tests...

Originally posted by Mark Garland:
What about if you tell Eclipse to deploy in an exploded fashion.

If compressed into a single WAR, the container probably notices the timestamp change and simply reloaded the app.
If exploded into a directory, perhaps the container will just reload that file.

P.S. I'm new to EJB, so sorry if this sounds a little naive.

Thanks Mark. My question then would be: where should I place my JSPs and EJB classes?

I'm also happy you posted this since I was going to ask the same question. I just tried using both @Local and @Remote annotations in a class and I got this error: "Local and Remote Interfaces cannot have duplicate interface for bean XYZ".

But I still don't understand *why* I can't have the same interface... Anybody?

Me to!!!

Hey Guys,

I'm starting to study for the SCBCD certification and I'm getting really bored when building my test cases with Eclipse+JBOSS.

The problem is that every time I make a change in the JSP (even a small one) Eclipse redeploys the entire WAR to JBOSS... And that takes a considerable time to reload...

Is there a way to avoid this WAR redeploy? I'm not hoping to avoid that with my EJBs, however, I thought there would be something faster for the JSP changes... How do you guys deal with this issue?

Thanks a lot,
Wagner
[ November 21, 2007: Message edited by: Wagner Danda ]

Hello,

I'm trying to write a IPAddress validation code, but now I'm not sure about the broadcast reserved ip concept. Can I have more than one broadcast in the same network? (Attention: I'm not saying "subnet").

For example:

Is it valid the following scenario?

Network Address: 10.0.0.0
Subnet Mask: 255.255.255.0

Valid IP Address Range:
from 10.0.0.1 to 10.0.0.254

Reserved ips:
Network Address: 10.0.0.0
Brodcast: 10.0.0.255

Thanks,
Wagner Danda
[ September 12, 2006: Message edited by: Wagner Danda ]

Originally posted by Ankur Sharma:
What I can tell you to go through the given below link and check out new feature of JDK 1.5 (Tiger)....

New Changes in JDK 1.5 Tiger Version

Also check out this link to find out the new features in JDK 1.4 from it's earlier versions.

New Features in JDK 1.4

These are good starting points, thanks!
[ July 25, 2006: Message edited by: Wagner Danda ]

Hello,

I'm trying to find a sort of comparison table with all the changes from java 1.3 to 1.5 in the certification perspective . I mean, only new features that are part of the cert exam.

Thanks!

Wagner Danda
http://wdanda.tk