There are a couple of challenges in making this component work as described above.
The first problem is that at the moment it's not possible to read the body of the request sent by bridgeit to the auxiliary resource.
So far, this component renders a button that calls the geoTrack bridgeit function when clicked. This works as expected, like other bridgeit components. After clicking the button, bridgeit launches and begins to send geotracking data to the postURL. While it has been verified that this works as expected, there's no way to read the body of this request that contains the geotracking information.
Specifically, the problem is that JSF doesn't provide a way to read the body of this request. When retrieving the request parameter map from the ResourceHandler for this auxiliary resource, the parameter map contains no entries. The request sent to the server by bridgeit is of content type 'application/json', as can be seen by calling externalContext.getRequestContentType(). I suppose that since this is not of type 'application/x-www-form-urlencoded', JSF doesn't bother in parsing the body of the request. Since the request is neither of type 'multipart/form-data', no Part objects can be retrieved from it. If we get the actual HttpServletRequest object (by calling externalContext.geyRequest()), and if on it we invoke getInputStream() (which contains the body of the request), we actually get nothing, no bytes, because the input stream can only be read once, and JSF already did that, without saving the contents of the body anywhere.
So, we would need to either create a special servlet or a filter just for this use case to obtain the body content of this request done by bridgeit of type 'application/json', with geotracking data. Alternatively, we could instead modify bridgeit to make this request of type 'multipart/form-data' or 'application/x-www-form-urlencoded', so that it could be processed by JSF and the data be available at the moment the ResourceHandler is invoked. We could also make this an option in the bridgeit call.
Assuming that we make this work somehow, the other challenge would be to evaluate an EL expression from the ResourceHandler. This EL expression would correspond to the EL expression specified in the component to write the geotracking data to directly. Since this is done outside of the regular JSF lifecycle, we would write this data directly to the bean property corresponding to this EL expression. Beans in this case could only be session- or application- scoped. The approach I have in mind is to create a custom implementation of Resource that recieves some sort of callback object with the EL expression to evaluate. Then, this resource is registered via ResourceRegistry, so that a random name is generated. This would become the postURL for bridgeit. So that when this resource is accessed, the geotracking data from the bridgeit request is extracted in the ResourceHandler and then the EL expression associated with this resource is evaluated and the geotracking data is written to this bean property.
<mobi:geotrack strategy="significant|continuous" />
This component will also require a ResourceHandler to accept the location updates in geoJSON format. These are uploaded outside the JSF lifecycle, so a mechanism for propagating these into the application beans will need to be determined.