Todor Mollov

Ranch Hand
+ Follow
since Jan 13, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
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 Todor Mollov

Thank you Jim,
Everything is fine except year 0000(BC and AD). I can't make Calendar to 'show' the birthday of Christ!?!?
Any comments on this code ,

and the output of it ?
IV 16 19:43:35 0001 AD
III 16 19:43:35 0001 AD
II 16 19:43:35 0001 AD
I 16 19:43:35 0001 AD
XII 16 19:43:35 0001 BC
XI 16 19:43:35 0001 BC
X 16 19:43:35 0001 BC
IX 16 19:43:35 0001 BC
VIII 16 19:43:35 0001 BC
VII 16 19:43:35 0001 BC
VI 16 19:43:35 0001 BC
V 16 19:43:35 0001 BC
19 years ago
Thank you for your reply !

May be I discovered the warm water again but I found how it works.

prints :
Tue May 16 01:08:23 EET 2004
BC!!!
19 years ago
I want to make calendar that shows date period 01/01/3000 BC - 01/01/3000 AD. But unfortunately
returns 1.
On the other hand

prints Fri May 15 15:18:21 EEST 292277998.
How could I take Calendar instance for the period when Egyptians built the pyramids ?
19 years ago
Hi Sudhir,
of course you are rigth but I was thinking in the context of the current thread.
So the question is : Why this EJB-QL is wrong

SELECT s.name FROM Student s, Program p where s.subjectid=p.subjectId


and the spec says on p.232

Because finder methods cannot return arbitrary types, the SELECT clause of an EJB QL query defined
for a finder method must always correspond to the abstract schema type of the entity bean for which the
finder method is defined.


and later on

In contrast, the SELECT clause of a query defined for a select method can
return the abstract schema types of other entity beans or the values of cmp-fields.


The given EJB-QL states that the method is select method (because of the return type), so it appeared that this EJB-QL is right.
ejbCreate(..) returns primary key type so it should return java.lang.Object.
A, B, C
You cannot use JOINs in EJB-QL.
For sure some kind of Exception will be thrown , but I don't know what kind. EJB spec p.341 17.3.3

A stateless session bean instance must commit a transaction before a business method returns.
A message-driven bean instance must commit a transaction before the onMessage method returns.

Which one can be defined as an application exception?
A.EJBException
B.IOException
C.RemoteException
D.NoSuchObjectException
The answer is C. Concluded from the discussion below. June 05, 2003
[ June 05, 2003: Message edited by: ZheMin Lin ]


The answer is B.
RemoteException can't be in any case application exception.
A message-driven bean class can define one = true
OR
more ejbCreate methods = false
true || false = true
The answer is true.
I'm using JBoss 3.2.3.
Do you think that properly coded bean with the following DD will not deploy and run?

Pay attention that <aassembly-descriptor> part is misssing, the place where transaction attributes are specified(RequiresNew, Required, Never, etc...). If our uniquiely :-) named BeanStatefullBean has one method getSomething() for example, will the container start a transaction when this method is exected?
[ February 22, 2004: Message edited by: Todor Mollov ]
I didn't specify transaction attributes both for my entity and session beans and they deployed perfectly. Now I wonder what transaction mechanism will be used?
Any idea ?
thank you ,
but I don't understand how to set up such a securite realm. Suppose we use database and I insert there a couple of pairs username-password. Suppose I use rich client to authenticate the user. The loging window contains 2 text fields(username field and pass field) and two buttons (OK,CANCEL). How the container will know how to map Principles(Abstract actor) and real users(the data in the DB)?
What if transaction descriptions are missed in DD. What kind of transactions will the container use ?
Sorry to interrupt but Nehul is right:

as we know NO BMT for entity bean

but is wrong for :

if you are using CMT in that case entity bean will be abstract


Entity beans have Bean Managed Persistance BMP or Container Manged Persistance CMP. But they only have Container Managed Transactions CMT.
So if Entity bean is BMP it is concrete and if is CMP it is abstract.
I'm agree with Prasad that something smells about the question.
java:comp/env subcontext is where the bean begins navigating when he want to look something up.