|
History
| Log In
|
|
|
|
Thomas, could you please provide more input on how having the war customizable would help in your case? Btw, I'm planning on changing the default implementation to simply consider bundles with .war extension - this will support servlet 2.5 wars as well (whcih are based only on annotations), static wars not to mention that it will be closed to the behaviour in S2AP.
Costin, what you have told is another valid situation where the .war extension is used to determine the bundle as a web-bundle.
In my case, I would like to have the web ui be split into modules. Modules like the shipping module will be build as a saparate bundle containing the ui components. Now consider that i would like to supply this bundle as a part of various other web-applications to be deployed at various client centers. Essentially, this module can now be part of various web applications, interaction of which would be leveraged by OSGi. In effect, my web ui (module) bundles will also work like any other bundle in OSGi, that would add up functionality to an existing bundle. In this case, I would like my web module bundles (that will not have a web.xml) be recognised as a bundle to be deployed to web container, but should be treated in a different way altogether. This would require that the war-scanner be customisable. Right now, I am doing all this inside a fragment bundle, but I would be happy if I could move this out of the fragment bundle. (I am too early speaking on this, as I have just started off on it) With the above idea (or using the .war), some of the method names such as getWebXmlConfiguration seem to be tied up to the web.xml concept. I don't know whether now you would consider the original requirement of customising the warScanner, or rather this would spark up a totally new idea in your mind. The warScanner is meant to run along the web deployer - if you don't have a web-inf/web.xml and your bundle is not war then the deployer (that is the web container) will not know what to do with it.
Or am I missing something here? My point is that the web extender works with a certain workflow which you'd like to generalize. From what I understand, you won't reuse most of the web extender/web components and it seems that just creating your own extender would work better. Costin, I have mentioned my intentions above. Probably you are right, that I may end up writing my own web extender. But, as of now I am starting with writing fragment to the web-extender.
As I had mentioned above, I have just started off, I will get back to this issue once I am more clear. BTW, it was good that you provided extending the WarScanner even as a fragment, since, I could start my work right away.! Thomas how exactly are you using the web scanner when the interface itself is internal? Even if you define a bean, if the type is not compatible, the configuration will not be picked up.
I created a spring xml configuration file under /META-INF/spring/extender with an entry like this:
<bean id="warScanner" class="point.to.class.inside.same.bundle.MyWarScanner" /> This class will implement the WarScanner interface. Now, my War Scanner logic is used instead of the default one. Was this the reply you wanted? Ah right - now I understand why you have to put your scanner inside the fragment and not outside (as you would normally would).
Thomas, feel free to report back any feedback that you have but let me state that you are using an internal interface and internal behaviour which might change w/o a replacement at any point. |
||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
WarScanner should be customizable
as "I think there is no reason why I should declare the bean definitions in the fragment bundle and could not keep the implementations outside."