Make Dispatcher class public or protected

[9902468]

Hi,

Im using integration package in my software, and I cannot add the connector servlet to our software. Now, it would be easy to route all appropriate requests for the Dispatcher, but as it's constructor is protected I can not instantiate it. Also the doGet and doPost methods are protected.

I copied all code from this class to my own Dispatcher, and the only change was to mark those three as public. Everything works.

Could those be marked as public in the final release? (Then I could just instantiate your Dispatcher, and I could delete mine.)

Or is there good reason why this should be only instantiated by your servlet?

• Ville

[Michael Osipov]

Hi,

the class is not protected. It's package private. What is the reason why you can't use the ConnectorServlet?

The reason was that the more control you give, the less you can't guarantee a clean state as people start to tamper classes and implementations. The only control should be over the connector itself.

We could make it really protected and you could subclass the dispatcher and use it anywhere or make it private. We will evalute both.

[9902468]

Replying to mosipov:

Hi again,

we are providing integration package to T5, and using it's configuration facilities it is possible to have everything in place by just dropping the jar to classpath. I can add servlet filter programmatically to T5 request - response chain, so that the developer who uses the package can use it Tapestry 5 way: zero tampering with web.xml and everything configured through the proviced IoC. This is not mandatory, but nice addition. If I can't subclass the Dispatcher I'll just have to copy that class everytime I upgrade FCK Editor Java integration package - minor annoyance, but we can live with it.

I'll ask one more question also: UserAction interface exposes only the request to the handling method, could the interface (and all other such interfaces) receive also the ServletContext? This way I could directly access T5 IoC. Now I have to add filter that detects any FCK activity and copies reference from ServletContext to request, so that I can access all the needed services via IoC. Again, I can live with the current situation, but I could delete a lot of code if the methods would receive the ServletContext also.

• Ville

Ps. Thanks for the integration package!

Hi,

the class is not protected. It's package private. What is the reason why you can't use the ConnectorServlet?

The reason was that the more control you give, the less you can't guarantee a clean state as people start to tamper classes and implementations. The only control should be over the connector itself.

We could make it really protected and you could subclass the dispatcher and use it anywhere or make it private. We will evalute both.

[Michael Osipov]

Ok, this sounds very interesting altough I have never used Tapestry before. I talked to th-schwarz which is my fellow-dev and he agrees with me that this is too much control over the entire system. Giving more control is mostly error-prone so I have a workaround without changing any line of code for you: Since the Dispatcher is package private you may declare your servlet in the net.fckeditor.connector package in your jar. You will have access to the dispatcher.

I evaluate this in first place, please. I will leave the ticket open for now.

File a new ticket for your second wish.

[Michael Osipov]

One thing though is still unclear. Do you want to subclass the Dispatcher or do you want to have it just in the public scope to use it in your system? this is a big difference. The class and its methods could be done final public then.

[9902468]

Replying to mosipov:

Hi,

actually I only need to be able to instantiate it and hold a reference to it and that's it. So no need to subclass.

I didn't even think that I could declare my servlet to that package, thanks for the tip! :)

• Ville

One thing though is still unclear. Do you want to subclass the Dispatcher or do you want to have it just in the public scope to use it in your system? this is a big difference. The class and its methods could be done final public then.

[9902468]

Replying to 9902468:

Hi again,

of course I need to be able to call the doGet and doPost methods also, forgot that in my previous post. public final would thus be sufficient.

If you do you can close this one. Thanks!

• Ville

Replying to mosipov:

Hi,

actually I only need to be able to instantiate it and hold a reference to it and that's it. So no need to subclass.

I didn't even think that I could declare my servlet to that package, thanks for the tip! :)

• Ville

One thing though is still unclear. Do you want to subclass the Dispatcher or do you want to have it just in the public scope to use it in your system? this is a big difference. The class and its methods could be done final public then.

[Michael Osipov]

Hi Ville,

tell if you my idea (declaring your servlet in our package worked for you. Since your servlet won't be different to ours, you will have full control over the Dispatcher.

I will clse this one if you confirm ;-)

[9902468]

Replying to mosipov:

Yep, it works great! Thanks,

• Ville

Hi Ville,

tell if you my idea (declaring your servlet in our package worked for you. Since your servlet won't be different to ours, you will have full control over the Dispatcher.

I will clse this one if you confirm ;-)

[Michael Osipov]

Please open another ticket for your second wish. Closing this one as WFM.