Kanchan Kumar Dey

+ Follow
since Oct 18, 2007
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 Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kanchan Kumar Dey

hi gurusamy,

Thing is that I had never into developing Portlet server. I was just studying and raise the question as I find it important issue needs to be addressed properly..

Anyway to help you out...

Either you can develop your own Portlet Containet after creating a Protlet Container API..Hope may sun in future also incorporate this...

Or you can create a Layer (Implementing a kind of Portlet container API) which in turn talks to the different Portalet container as configured or asked for...something like JDBC layer.

Your Portal (a web app. with good CMS) shall talk to this layer, and this layer shall talk to the actual portlet container on which it is deployed or configured with.

The layer must be implementing the different communication protocol vis~a~vis portlet container.

So this layer works as a bridge to integrate your portal with portlet container and in turns provides a abstraction which provides a uniform interface to all portlet container.

I hope this much is clear to understand what I am trying to say.
15 years ago
HI Ritesh,
Could you please share the information that how you have configured Tomcat 6.0 with NIO

You are not getting events for Read because, everytime its a new request and for that you are getting only Begin event.
Read even is fired when a message comes from the client over the same HTTP connection already established...I Guess.
15 years ago
I know that one can deploy jsr168 portlets to any portal server and I too have mentioned that no. of times(A portlet container is a RI for jsr 168 & jsr 286 and any portlet compliant to that can run on any portlet container. True. - extrats from my last comment).

Perhaps you are not reading my comments properly. From the beginning, I am only concerned about the Portal<=>Portlet container communication and not PortletContainer<=>portlet communication.

Yes, my intention is to develop a new portal like JetSpeed or WebSphere or Pluto and for that we need to know which portlet container I am working with and interface does it provides. There is no standardization on this part. One either need to go through the vendor specific documents or code base, to understand how to get an instance of the portlet container, and what methods are supported.

There could be many reasons to create a new Portal and not to choose Jetspeed, websphere etc.. But that is a diff. subject.

I repeat my question. If I want to develop my Portal(which is just a CMS like web application), can I do that without knowing which portlet container I am working with.
say, I develop a "MyPortalServer" which works with Pluto Portlet container.
Can I make it(MyPortalServer) work with Jetspeed portlet container or webspehre also without changing any code.
[ June 10, 2008: Message edited by: Kanchan Kumar Dey ]
15 years ago
Just to add to my earlier reply...

Portal<==========>Portlet Container<=========>Portlet
|_ _ _ _??_ _ _ _ _ |_ _ _ Jsr168 & Jsr286 _ _ _ _ _ _ _ _ _ |

[ June 09, 2008: Message edited by: Kanchan Kumar Dey ]
[ June 09, 2008: Message edited by: Kanchan Kumar Dey ]
15 years ago
Yes true. You are talking about jsr 168 & jsr 286 and portlets...
A portlet container is a RI for jsr 168 & jsr 286 and any portlet compliant to that can run on any portlet container. True.

But I am not talking about portlet container <=> portlet communication. am talking about Portal <=> Portlet container communication.

A Action or Render request is received by a Portal (which is nothing but a web application with good CMS). Portal call methods on portlet container and in turn portlet container calls methods on portlet. Now we know from jsr168&286, what method a portlet container calls on portlet and so when and what we need to implement in a portlet. But jsr168 and jsr286 does not clarify what method a Portal calls on portlet container. So, if we intend to develop our own Portal, we need to look for that vendor specific portlet container's documents or need to dig the code to find what method to call on portlet container and how to get an instance of the portlet container etc.

I am saying we must have an API(portlet container API) so that we can develop our Portal without any vendor specifc knowledge of any Portlet container and can employ any Jsr168 & jsr 286 compliant portlet container for our purpose. Do we have that? If not, then we are not complete with JSR 168 & Jsr 286,we need one more API atleast.
15 years ago
4) Just to add to my earlier reply,
A portal and portlet container are developed by different stake holders. They must not know the details beyonds some contracts given by an interface(Portlet container API). Otherwise one has to develop both Portal and Portlet Container togetherly (and in effect implement another RI for jsr 168 & 286).
15 years ago
Thanks for the reply.
But not convinced completely.
Firstly I did not get my answer that whether Portal and portlet container is tightly coupled or not? Is there any Portlet container API?

2ndly, (if I am not wrong with my doubt,)with ref. to your response:
1) Servlet, jsp itself is an API and one can develop and deploy there own servlet/jsp web app. independent of any servlet container? Then why not there be a API for portlet container?

2) Web app. developed with struts are tightly coupled and there is no replacement for struts without changing codes on other parts. It is individual's choice to go for such design, coupling or not.

3)I don't know about cocoon or JSF. But thing is that I would always like to design portal which can run on any portlet container. Otherwise my effort in developing a portal with Apache pluto portlet container will go in vain if i want shift to any other better portlet container. A portlet container API only needs to support few statndard methods which are always ultimately triggering the methods on portlets itself.
A portlet container is in a different layer than portal itself and they should not be tightly coupled.
15 years ago
We know about Portlet API (jsr 168 & 286) which standardizes the communication with portlet (between portlet and portlet container).

Do we have any API for portlet container, so that there is a standard way to access the instance of Portlet container, invokes methods on portlet container without knowing which vendor has developed it? Till now i think a Portal and portlet container are tightly coupled and a portal cannot be easily deployed with any portlet container without knowing its interface methods and then changing code in the portal itself?
If this is so, I think we are not complete with jsr 168 & 286.
(I have seen source code for pluto portal and pluto portlet container. They are tightly coupled.)

Please correct if I am wrong?
15 years ago
Mike, the question is not about no.s or whether the issue is major or minor.
A issue is a issue and needs to be addressed.

I am new to this J2EE world, and my intention is only to know that whether my understanding is correct or not and how to handle the requirement in EJB3.0.

What you said, if I understood correctly, is to implement a EJBObject interface in our own session bean. But then, I can overwrite all the functionality of EJBObject without calling a super._ _ _. And then how container is going to provide the implementation for the same as the container is not supposed to change our code(though can add more codes). I am not clear that how EJBObject.getHandle()(Which now I have overwritten) will return me the handler object for future purpose.

May be I need to follow some restriction/convention while overwriting methods from EJBObject like what has been described in those links(posted earlier), but still needs clarity. I can always write wrong codes to destroy the functionality from EJBObject (through method overwriting). Or may be something I am missing conceptually.

Or may be I failed to understand totally the solution you proposed (excuse me for that).
Thanks a lot Mike.

But one more clarification...

In ejb 2.0 it is not the bean which implements the EJBObject. It is altogether a different interface whose implementation is provided only by the container and not the developer. There are lot of reasons for such a design principle and it becomes obvious that the developer should not be given a chance to mingle with it.

The approach which you have suggested seems to break that design principle, if I have understood it correctly. Am I right?

And if it is so, then my intention is only to know that
1)Whether the EJB3.0 specification has intentionally removed this feature?
2)What might be the reason for removing this feature from EJB3.0 specification (as going forward with EJB specification, it seems that this feature would be deprecated in future version)?[/EMAIL]
I asked this question in this forum twice. but no answers...
My question is wrong? or it is so difficult to answer...

Further there should some tracking system to unanswered question so that the question doesn't loose its identity and value and gets the reply which it deserves.
My proposal is to show all the unanswered question in a separate listing or should be shown at the top of the list.

when I used Jaxb with xsd to generate java source it creates the same but with AccessType.Field on the type classes. The problem is while marshalling it enquires the fields but not the getter methods. This way I will not get a default value If I don't set it explicitly.

Is there a way to use JAXB to generate source with AccessType.Property(this will also place all the field level generated annotation at the property level) instead of AccessType.Field.

Thanks in advance.
16 years ago
In EJB2.0, the ejbObject().gethandle()is used to get the serializable stub of the remote stateful session bean. One can use the returned "handle" object at later point of time, even from some different jvm , to connect to the same Stateful session bean object.

Does EJB 3.0 support this feature by any means, as I guess there is no remote interface equivalent to EJBObject as such in it.