[Mondrian] xmla over olap4j server

Michele Rossi michele.rossi at gmail.com
Sun Mar 13 10:56:01 EDT 2011


hi,
sure it all sounds fine.
So the main piece of work here will be cutting out many dependencies of the
existing xmla servlet to the rest of the mondrian codebase.

I will have a go at it soon - no doubt I'll be in touch with more questions
once I get started.

thanks,
Michele


On 11 March 2011 22:12, Julian Hyde <jhyde at pentaho.com> wrote:

>  Let's keep it simple. The output of this project should be a library (a
> jar file), and one of the classes in that jar is a servlet. When the project
> is built it will push the jar into pentaho's repository, which is
> maven2-compatible.
>
> Anyone who wants to package that jar into a war can do so, but in their own
> workspace. You can write your own maven project for that if you wish.
>
> Right now that jar would consist of a subset of the classes in
> mondrian/classes. It's easy to build that jar by adding a few lines to
> mondrian's build.xml, or even using 'jar -cvf' on the command line.
>
> Julian
>
>  ------------------------------
> *From:* Michele Rossi [mailto:michele.rossi at gmail.com]
> *Sent:* Friday, March 11, 2011 12:55 PM
> *To:* jhyde at pentaho.com
> *Cc:* mondrian at pentaho.org
>
> *Subject:* Re: [Mondrian] xmla over olap4j server
>
> Hi Julian,
> regarding the new xmla server project - I have only ever created web-apps
> (.WAR) using  eclipse-level projects mirroring the folder
> structure dictated by the servlet specification.
>
> So you have a WEB-INF folder with a web.xml etc.
>
> With such a layout Maven can create a WAR very easily.
>
> I am sure that with Ant you can do all sorts of things, including creating
> that structure dynamically with a bit of build.xml tricks.
> However  I am not sure about the best patterns to follow if we go down that
> road.
> The end product is a standard WAR file that you can run in any servlet
> container and point to any olap4j driver right?
>
>
> Patch files: sure, I assume it's something that the Perforce client can do
> basing them on a changelist?
> I will look into it.
>
> Use of Maven: building a convincing case will take me a while and I am not
> sure a long email is the best way to share my points.
>
> I recently gave a presentation at work about it and people were quite
> convinced afterwards.
>
> Let's just say that if you adopt Maven you get all sorts of good things for
> free including
> -full eclipse integration
>
> -automatic project-site generation with a variety of code quality reports
> (test coverage is the one that impressed my boss most),
>
> -integration with Sonar  (another advanced code quality analysis tool)
>
> -integration with TeamCity (automatic builds and test execution)
>
> -entirely declarative build files ("pom.xml") with no strange tricks - much
> easier to mantain than ANT scripts (it's a personal opinion of course but I
> think those build.xml files are evil - they seem easy to write and later you
> find them totally impossible to maintain / debug)
>
>
> Michele
>
> On 11 March 2011 18:56, Julian Hyde <jhyde at pentaho.com> wrote:
>
>>
>>
>>  ------------------------------
>> *From:* Michele Rossi [mailto:michele.rossi at gmail.com]
>> *Sent:* Friday, March 11, 2011 1:43 AM
>> *To:* mondrian at pentaho.org; jhyde at pentaho.com
>> *Subject:* Re: [Mondrian] xmla over olap4j server
>>
>>  [re-sending from my private email address as it's not working from my
>> work address]
>>
>>
>>> Julian,
>>> I have a few questions for you:
>>>
>>> 1. How do I get started?
>>> Can you create an account on perforce for me with write permissions?
>>>
>> Please submit your changes as patches attached to jira cases. We don't
>> give people committer privileges until they have made a few successful
>> contributions.
>>
>>   2. Olap4j drillthrough
>>> The mondrian olap4j driver implements drillthrough via the "executeQuery"
>>> method which returns a java.sql.ResultSet right?
>>> Can we not leverage that method to implement drillthrough on the xmla
>>> server?
>>>
>> Possibly. Depends on your requirements. Mondrian's XMLA clients expect
>> more in the XMLA response than is currently available in the ResultSet
>> returned by that method. Therefore the XMLA server calls a method in
>> XmlaExtra. The default implementation of XmlaExtra calls executeQuery. Same
>> effect, longer route.
>>
>>
>>>
>>
>>> 3. The new project:
>>> We will need a new "olap4j xmla server" project with its separate build
>>> an dependencies.
>>> Can you think of a good name for it?
>>> Perhaps Olap4jXmlaServer could be a good candidate :)
>>>
>> Sounds reasonable.
>>
>>  4. How to build the new project:
>>> I know that mondrian is built using Ant.
>>>
>>> Have you ever thought about starting to use Maven?
>>> I've used Maven successfully for years and I've totally forgot how to use
>>> ant.
>>>
>>> I think it would also be beneficial in terms of linking olap4j releases
>>> with server releases.
>>> We could then distribute both olap4j, mondrian and the xmla server on
>>> public maven repositories.
>>>
>> At this point I don't want to create a new project. I would like to work
>> with the xmla server code in situ in the mondrian code base, to learn what
>> the necessary changes are, and where would be the appropriate cut points.
>> Then I will help you factor it into another project. But first, let's get it
>> working in situ.
>>
>> Re. maven, see below.
>>
>>
>>> 5. Proposed solution
>>> I can put together a webapp project quickly using the following
>>> ingredients
>>>
>>> a. maven build
>>>
>>> b. unit tests based on mondrian:
>>> You create an in-process mondrian instance and connect to it using the
>>> mondrian olap4j driver.
>>> Then you hit the new server using the olap4j xmla driver.
>>> You can then compare results making assertions on the equality of
>>> metadata and values.
>>>
>>> c. The output artifact would a standard .WAR file
>>>
>>> d. Jetty launcher
>>> I propose the creation of a jetty launcher too.
>>> I can create such launcher using maven reasonably quickly.
>>> The result would be a tar.gz file with a number of sub-folders, one of
>>> them containing the .war file discussed above, others containing shared
>>> jetty libraries and finally the .bat and .sh launchers.
>>>
>>> We could then have a "cfg" folder with a template .properties file where
>>> a user would have to put the details of his/her favourite olap4j driver and
>>> the connection details.
>>>
>> All of the above sounds fine. In due course. But please, don't make big
>> changes as the first step. (I've found that the most successful committers
>> are the ones who submit small patches at first.)
>>
>> In this case, the patches would be whatever hacks to mondrian's xmla
>> server are necessary to build your flavor of the server. I will learn a lot
>> from those patches.
>>
>> When time comes to create the new project, we can discuss using maven.
>> You'd have to make a strong case, because it would be a Pentaho project
>> (containing about 15k of mondrian source code, plus unit tests) and Pentaho
>> projects have standardized on using an ant+ivy+subfloor infrastructure.
>>
>> Julian
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110313/895021f1/attachment.html 


More information about the Mondrian mailing list