Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!

Anuj Singhal

Greenhorn
+ Follow
since Oct 17, 2003
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 Anuj Singhal

Seems, I am missing a very simple and basic concept.
I guess the same queue would be used.
ThreadPoolExecutor inherits submit(Callable<T> task) method.
The constructor of ThreadPoolExecutor accepts an instance BlockingQueue<Runnable>. This blocking queue can hold Runnable instances only.
Javadoc for ThreadPoolExecutor constructor says:
"the queue to use for holding tasks before they are executed. This queue will hold only the Runnable tasks submitted by the execute method."
Question : How tasks submitted through submit(Callable<T> task) are queued?
There are two interceptors defined for a given method; one at method level and one at class level.
What will be the sequence of execution?

@Stateless
@Interceptors(org.acme.AnotherInterceptor.class)
public class MyBean ... {
...
@Interceptors(org.acme.MyInterceptor.class)
public void someMethod() {
}
}
Will a) return just one reference of department object, whereas b) will return 5 references of Dept object?

Refer below extract from specification , section 4.4.5.
-----------------------------------------------------------------------------------------------------------------------
SELECT d
FROM Department d LEFT JOIN FETCH d.employees
WHERE d.deptno = 1


A fetch join has the same join semantics as the corresponding inner or outer join, except that the related
objects specified on the right-hand side of the join operation are not returned in the query result or otherwise
referenced in the query. Hence, for example, if department 1 has five employees, the above query
returns five references to the department 1 entity.

-----------------------------------------------------------------------------------------------------------------------

I am not clear on above paragraph. The above query will return 5 references when inner join is used or when fetch join is used?

What will be the difference in behavior between below two queries?
a)
SELECT d
FROM Department d LEFT JOIN d.employees e
WHERE d.deptno = 1

b)
SELECT d
FROM Department d LEFT JOIN FETCH d.employees
WHERE d.deptno = 1


Thanks,
Anuj
I got the answer I was looking for.
My understanding of top level class was not correct.
A class can be a top level class and can have super class at the same time.
It is mentioned about session bean class in section 4.6.2 of EJB 3.0 specification, "The class must be a top level class."
In the same section it is also mentioned, "The session bean class may have superclasses and/or superinterfaces."
Are not these two statements contradictory to each other?
My application has JMS selector similiar to one mentioned below:
NumberOfOrders = 1

I understand that a message will be picked up by the JMS client, if property value of "NumberOfOrders" in JMS message is set to 1.
But, i am not sure what will happen if "NumberOfOrders" property is not added to the JMS message.
Probably, selector condition will resolve to "null > 1" in above case and message will not be picked up by JMS client.
Has someone tested this before?
Great!
Will definitely go through them.

Thanks,
Anuj
Hi,

This happens to be one of the most the debated topic in IT forums.

As what i think, these are the key areas where SOAP outplays CORBA:-
1) Simple and light weight: As the name suggests, it is Simple. It exchanges message in human readable XML format. The whole SOAP protocol is defined in a simple schema file.
It is light weight, in the sense, it does not propogate any transaction or security context.
2) Easier to use : SOAP is far less complicated to use and understand. Just open a IDL file and try to understand the interface and do same with a WSDL file. WSDL is far more easier to understand. Also, it an XML file, so existing XML parsers can be used to create Stub and Interface Generators.
3) HTTP protocol: SOAP's biggest advantage is that SOAP messages can be tranported over HTTP(although not limited), thus reducing firewall problems to a huge extent.
Whereas, CORBA uses non-standard ports for communication. Imagine a company, using CORBA distributed application, having office at 50 different locations and each office has it's own firewall settings(which is quite likely). Such a setup will require higher maintenance compared to SOAP.
Instead, If SOAP over HTTP is used, communication will take place over HTTP port, which is generally open in most firewalls. Client/Web Service endpoint communicates just like Web Browser/Web Server and most companies allow Web browsing.
4) Industry support and standardization: SOAP is developed and drafted by IBM and Microsoft and is supported by Sun Microsystems. All major industries and communities have embraced SOAP. Whether a person is an apprentice or developer or architect or CTO, this fact gives him lot of confidence in picking up a technology.

Technology keeps evolving, trying to make life of a developer easier and allowing them focus on business logic.
The way industry efforts are channelized, SOAP is expected to get better day by day, if not become de facto solution for SOA and other distributed applications.



Thanks,
Anuj

[ September 28, 2006: Message edited by: Anuj Singhal ]
[ September 28, 2006: Message edited by: Anuj Singhal ]
You are welcome
Hope you got what you were looking for.

Thanks,
Anuj
Hi,
This link would provide you required information.
Study Resources for SCDJWS Exam

Thanks,
Anuj
[ September 26, 2006: Message edited by: Anuj Singhal ]
Hi,

Original message:-
------------------------------------------------------------------------
All of the local elements of a SOAP message must be namespace-qualified (prefixed with the SOAP 1.1 namespace), because the XML schema for SOAP 1.1 specifies the elementFormDefault attribute as "qualified".
------------------------------------------------------------------------
Do you mean Schema for the SOAP/1.1 envelope having targetnamespace http://schemas.xmlsoap.org/soap/envelope/
It is true that this schema mandates local elements defined in this schema to be namespace qualified in an XML document, which means Header, Body and Fault need to be fully quanlified.
However this schema can no way restrict body element to contain XML fragment with fully qualified names, only SOAP specification or BP can do that.


Original message:-
---------------------------------------------------------------------------
In addition, the Basic Profile 1.0 requires that all the application-specific elements contained by the Body element must be qualified.BP Unqualified elements in a SOAP Body element create too much ambiguity as to the meaning and proper structure of elements.
---------------------------------------------------------------------------

True. That's what is mentioned in clause R1014 of BP , as i said in my initial post. It tells only about direct child of Body element, but nothing about Grand children.
In RMH, i have seen RPC style SOAP XML documents, in which GrandChildren are not fully-qualified. i assume that they are BP complaint SOAP message.



Thanks,
Anuj
Hi,
TreeSet and TreeMap uses compareTo to check duplicate elements.
They do not use equals and hashcode method.

check this code:-





Output:-
compareTo called
compareTo called
compareTo called
Set: [1, 3]

Thanks,
Anuj
13 years ago
Hi,
As per the contract of compareTo method, it is a "natural comparison method".
This means that this method should be used only to compare objects for order, and not to check equality of two objects.

Then, why do Set use compareTo method, instead of equals method, to eliminate duplicate items.
It expects compareTo() to be consistent with equals.
Isn't a breach of contract of compareTo method?

Thanks,
Anuj
13 years ago