Java API configuration with web.xml

[dstricker]

Hi,

I am currently using WURFL via the Java API configured through WEB-INF/web.xml. The app server stack consists of apache 2.2.9, tomcat 5.5, and java 1.5. I have a number of contexts that each use WURFL, and while the code library dependencies are shared, the WURFL device file and patch files are loaded on a per-context basis. I am trying to minimize memory consumption, and I would like to share a single WurflHolder and/or WurflManager across all contexts (which all require the default device information, anyway).

While probably inadvisable, I attempted to put the listener and context-param tags in catalina's default web.xml file (TOMCAT_HOME/conf/web.xml):

<listener>
<listener-class>
net.sourceforge.wurfl.core.web.WURFLServletContextListener
</listener-class>
</listener>
<context-param>
<param-name>wurfl</param-name>
<param-value>wurfl-2.3.xml.zip</param-value>
</context-param>
<context-param>
<param-name>wurflPatch</param-name>
<param-value>web_browsers_patch.xml</param-value>
</context-param>

But I cannot specify a file location that makes sense from the viewpoint of this configuration.

What is the best way to share a single device file and patch files for all contexts?

Thanks,
David

[fulvio.crivellaro]

Hello David.

You can share your wurfl and patch files by simply specifying absolute paths in the web.xml file.
Of course, even if it is not your case, it works pretty much the same for Spring *.ctx context files.

So, for example, on a Windows machine you could write something like:
<param-value><DRIVE>:/<PATH_TO_WURFL>/wurfl-2.3.xml.zip</param-value>
while on a Unix machine it would be:
<param-value>/<PATH_TO_WURFL>/wurfl-2.3.xml.zip</param-value>

I hope this answers your question!

Regards,
Fulvio

[dstricker]

Hi Fulvio,

Thanks for your quick response!

However, this is not working for me, partially because the resource gets loaded via ServletContextWURFLHolder as follows:

93: private URI toURI(ServletContext servletContext, String mainPath) {
94: URI uri = null;
95: try {
96: uri = servletContext.getResource(mainPath).toURI();

getResource takes a context-relative full path:

http://tomcat.apache.org/tomcat-5.5-doc ... ng.String)

meaning that it won't look outside of the context itself (nor does it syntactically accept a path that begins with a drive letter).

But the deeper question is: even if it *could* load the file from elsewhere, won't it reside in the memory of that particular context? That is to say, if another context were to load the file from the same place as the first one, wouldn't it create new objects in memory anyway? If so -- and this is my main question and problem -- is there a way for the WURFLHolder to be loaded in memory once for *all* contexts? I have many contexts using WURFL, and they are using a lot of memory by loading the device file into different places in memory.

It seems that this would need to be different:

WURFLHolder wurflHolder = (WURFLHolder) getServletContext().getAttribute("net.sourceforge.wurfl.core.WURFLHolder");

Is there another way to refer to the WURFLHolder at the server level?

Thanks again for your help!

[fulvio.crivellaro]

Hi David.

We are about to deliver release 1.4 of our Java API, hopefully within this week.
This new release will support absolute paths for sure.

Anyway, according to your detailed question, you don't need such a feature, but you are asking for a shared wurfl <INSTANCE>, not <FILE>.
We plan to develop a simple example, a tutorial to implement exactly what you need, since we gave particularly attention to memory usage and optimization for the 1.4 release.
Nonetheless we are now particularly focused on the 1.4 delivery now, so I suggest you to stay tuned, until the new tutorial is available.

For the time being, anyway, you can take a look at this document, which explains how to implement a shared wurfl instance, according to your specific visibility and security requirements.

Fulvio

[dstricker]

Hi Fulvio,

Thanks again for the quick and detailed response. Looking forward to 1.4!

> For the time being, anyway, you can take a look at this document, which explains how to
> implement a shared wurfl instance, according to your specific visibility and security requirements.

Is this something that is available now or will this be bundled as a tutorial with the new release (don't see a file attached)?

Can I implement a shared wurfl instance in 1.3.1.1 or should I wait until 1.4?

Thanks again,
David

[fulvio.crivellaro]

Hi David.
I answer inline, except for the fact that I forgot to paste the URL I was talking about in my previous post... Sorry for that!
Here it is: http://tomcat.apache.org/tomcat-5.5-doc ... howto.html

>Hi Fulvio,

>Thanks again for the quick and detailed response. Looking forward to 1.4!

You're welcome!

>> For the time being, anyway, you can take a look at this document, which explains how to
>> implement a shared wurfl instance, according to your specific visibility and security requirements.

>Is this something that is available now or will this be bundled as a tutorial with the new release (don't see a file attached)?

See the missing URL!

>Can I implement a shared wurfl instance in 1.3.1.1 or should I wait until 1.4?

This is something which has to do with Java and Tomcat, and does not depend on Wurfl version.
Obviously, anyway, the tutorial will be focused on Wurfl 1.4, and ready to be deployed with such version, but if you need it you can customize it to work with previous versions of Wurfl.

I hope everything is clear now!
Don't hesitate to ask more questions if you need.
Fulvio

[dstricker]

> This is something which has to do with Java and Tomcat, and does not depend on Wurfl version.
> Obviously, anyway, the tutorial will be focused on Wurfl 1.4, and ready to be deployed with such
> version, but if you need it you can customize it to work with previous versions of Wurfl.

I understand now -- there are many ways a WURFLHolder can be made available to a context, not just those that are presented in the overview. I am working on using an approach such as those described in the JNDI document, but I am also looking forward to 1.4 and the tutorial, as I'm sure your approach will be much better!

Thanks again for your help,
David

[dstricker]

Hi again,

I see 1.4 is released, which is great! I am in the process of upgrading now. Does the tutorial you referred to exist yet, or if not, can you paraphrase the steps here?

Anyway, according to your detailed question, you don't need such a feature, but you are asking for a shared wurfl <INSTANCE>, not <FILE>.
We plan to develop a simple example, a tutorial to implement exactly what you need, since we gave particularly attention to memory usage and optimization for the 1.4 release.

Basically I need exactly that...a shared WURFL instance available to many contexts on a single tomcat server. I realize that Spring might make this easier, but at the moment, I am not using Spring for these projects.

Thank you again!
David

[sm_support2]

Does the tutorial you referred to exist yet [...]?

It does now. Enjoy.

http://www.scientiamobile.com/blog/post ... -with-JNDI

[dstricker]

This is great -- thanks!!