Hitachi Vantara Pentaho Community Forums
Results 1 to 17 of 17

Thread: [Mondrian] xmla over olap4j server

  1. #1
    Michele Rossi Guest

    Default [Mondrian] xmla over olap4j server

    Hi,
    first all of thanks a lot for all your efforts on Mondrian and OLAP4J -
    we're using both and they are working fantastically for us.

    We have built our own OLAP4J driver for our internal system and we'd like to
    use the feature described here by Julian Hyde:
    http://julianhyde.blogspot.com/2010/...mondrians.html

    What is the status of the work in this area?
    I think that the ideal solution would be a webapp configurable with the
    details of the OLAP4J driver / URL to connect to.

    Unfortunately I am not at liberty to contribute to open source projects
    during my working hours but I could think about doing it in my free time.

    In that case we'd have a discussion about it and agree broadly on the
    implementation.

    What do you think about the above?

    What perforce branch should I look at for those changes?
    Is mondrian_release/3.2 the correct location?


    thanks a lot,
    Michele

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  2. #2
    Julian Hyde Guest

    Default RE: [Mondrian] xmla over olap4j server

    Michele,

    I have done about 90% of the work that you need, but the code is still part
    of the mondrian code base. It would be great if you could push forward the
    final 10%, and let me know what changes need to be made.

    Then some point, I can spin all of this code (XmlaServlet, XmlaHandler) out
    as a separate project that is outside the mondrian code base and has zero
    dependencies on Mondrian. (I'd describe it as an "XMLA olap4j bridge"; not
    to be confused with the XMLA olap4j driver, which operates in the reverse
    direction.)

    Later we might also move over mondrian's XMLA tests, packaging them in a jar
    so that they can continue to be called from Mondrian's suite, but can also
    be called from others' suites.

    I did the changes on the //open/mondrian-release/3.2 branch (mainly changes
    13929 and 13944, see below), but I have since integrated back to the main
    line //open/mondrian. There aren't many differences between those branches
    at this point, but you should work on main.

    Perforce changes:

    * 13929: http://perforce.eigenbase.org:8080/@md=d
    <http://perforce.eigenbase.org:8080/@...g@/13929?ac=10
    > &cd=//&rc=s&rg=c&c=Umg@/13929?ac=10

    * 13944: http://perforce.eigenbase.org:8080/@md=d
    <http://perforce.eigenbase.org:8080/@...g@/13944?ac=10
    > &cd=//&rc=s&rg=c&c=Umg@/13944?ac=10


    You would need to instantiate mondrian.xmla.impl.XmlaServlet (probably its
    default implementation mondrian.xmla.impl.DefaultXmlaServlet) in your web
    server.

    You will see that XmlaServlet has a 'MondrianServer server' data member. But
    it is only used to create an XmlaHandler, so you could easily remove it.

    mondrian.xmla.XmlaHandler does most of the work, and following change 13929
    and 13944 the dependencies on mondrian are minimal. Just utility classes. It
    gets all of the information it needs from an olap4j connection.

    The XmlaHandler.XmlaExtra interface provides extra metadata & functionality
    that is not (currently) in the olap4j interface, such as drillthrough, and
    whether a hierarchy is a parent-child hierarchy. Your olap4j connection
    class can optionally provide an XmlaExtra, by implementing the
    Connection.unwrap(Class) method. (Called from
    XmlaHandler.getExtra(OlapConnection). If it returns null, XmlaHandler will
    use a default XmlaExtra that uses dumb defaults.

    The key callback is XmlaHandler.ConnectionFactory. Either provide
    ConnectionFactory when servlet creates an XmlaHandler, or override
    XmlaHandler.createConnection.

    Your implementation of ConnectionFactory probably just creates an olap4j
    connection, but it needs to set its catalog, schema and role consistent with
    the values in the XMLA request.

    Then XmlaHandler will call your olap4j connection to find other available
    catalogs and schemas in that server.

    I've punted on authentication for now. I assume that the container has
    authenticated, and has set the "role_name" property in the request contet.
    Probably if there is a username and password in the XMLA request they should
    be passed into the getConnection method, but the olap4j provider should also
    be able initiate request-response authentication over HTTP. And it should
    figure out for itself the default role for that user. Much to do in that
    area...

    Hope that helps.

    Julian


    _____

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On
    Behalf Of Michele Rossi
    Sent: Thursday, March 03, 2011 12:46 AM
    To: mondrian (AT) pentaho (DOT) org
    Subject: [Mondrian] xmla over olap4j server


    Hi,
    first all of thanks a lot for all your efforts on Mondrian and OLAP4J -
    we're using both and they are working fantastically for us.

    We have built our own OLAP4J driver for our internal system and we'd like to
    use the feature described here by Julian Hyde:
    http://julianhyde.blogspot.com/2010/...g-in-mondrians.
    html

    What is the status of the work in this area?
    I think that the ideal solution would be a webapp configurable with the
    details of the OLAP4J driver / URL to connect to.

    Unfortunately I am not at liberty to contribute to open source projects
    during my working hours but I could think about doing it in my free time.

    In that case we'd have a discussion about it and agree broadly on the
    implementation.

    What do you think about the above?

    What perforce branch should I look at for those changes?
    Is mondrian_release/3.2 the correct location?


    thanks a lot,
    Michele


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  3. #3
    Michele Rossi Guest

    Default 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 (DOT) com> wrote:

    >
    >
    > ------------------------------
    > *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > *Sent:* Friday, March 11, 2011 1:43 AM
    > *To:* mondrian (AT) pentaho (DOT) org; jhyde (AT) pentaho (DOT) 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
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  4. #4
    Julian Hyde Guest

    Default RE: [Mondrian] xmla over olap4j server

    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 (DOT) com]
    Sent: Friday, March 11, 2011 12:55 PM
    To: jhyde (AT) pentaho (DOT) com
    Cc: mondrian (AT) pentaho (DOT) 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 (DOT) com> wrote:





    _____

    From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    Sent: Friday, March 11, 2011 1:43 AM
    To: mondrian (AT) pentaho (DOT) org; jhyde (AT) pentaho (DOT) 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



    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  5. #5
    Michele Rossi Guest

    Default Re: [Mondrian] xmla over olap4j server

    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 (DOT) 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 (DOT) com]
    > *Sent:* Friday, March 11, 2011 12:55 PM
    > *To:* jhyde (AT) pentaho (DOT) com
    > *Cc:* mondrian (AT) pentaho (DOT) 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 (DOT) com> wrote:
    >
    >>
    >>
    >> ------------------------------
    >> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> *Sent:* Friday, March 11, 2011 1:43 AM
    >> *To:* mondrian (AT) pentaho (DOT) org; jhyde (AT) pentaho (DOT) 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
    >>

    >
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  6. #6
    VanIngen, Erik (FIPS) Guest

    Default RE: [Mondrian] xmla over olap4j server

    Dear Mondrian,

    I am about to integrate Mondrian in my SDMX project and I came across this message. I would vote for the use of Maven in the Mondrian project. The advantages are huge like little build configuration files (convention over configuration), excellent integration in IDE's and Continuous Integration servers and so on.

    Erik

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of Julian Hyde
    Sent: 11 March 2011 22:13
    To: 'Michele Rossi'
    Cc: mondrian (AT) pentaho (DOT) org
    Subject: RE: [Mondrian] xmla over olap4j server

    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 (DOT) com]
    Sent: Friday, March 11, 2011 12:55 PM
    To: jhyde (AT) pentaho (DOT) com
    Cc: mondrian (AT) pentaho (DOT) 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 (DOT) com<mailto:jhyde (AT) pentaho (DOT) .com>> wrote:


    ________________________________
    From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com<mailto:michele.rossi (AT) gmail (DOT) com>]
    Sent: Friday, March 11, 2011 1:43 AM
    To: mondrian (AT) pentaho (DOT) org<mail...taho (DOT) org>; jhyde (AT) pentaho (DOT) com<mailto:...taho (DOT) 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


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  7. #7
    Tom Barber Guest

    Default RE: [Mondrian] xmla over olap4j server

    As pointed out, pentaho has a Maven/Ivy repo to build projects with Mondrian in them, unless you need the source and build that, you can pull the latest and stable builds from repo.pentaho.org (login guest:guest).

    Tom
    ________________________________________
    From: mondrian-bounces (AT) pentaho (DOT) org [mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of VanIngen, Erik (FIPS) [Erik.VanIngen (AT) fao (DOT) org]
    Sent: 14 March 2011 14:33
    To: jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list; 'Michele Rossi'
    Subject: RE: [Mondrian] xmla over olap4j server

    Dear Mondrian,

    I am about to integrate Mondrian in my SDMX project and I came across this message. I would vote for the use of Maven in the Mondrian project. The advantages are huge like little build configuration files (convention over configuration), excellent integration in IDE

  8. #8
    Julian Hyde Guest

    Default RE: [Mondrian] xmla over olap4j server

    Erik VanIngen wrote:

    I am about to integrate Mondrian in my SDMX project and I came across this
    message. I would vote for the use of Maven in the Mondrian project. The
    advantages are huge like little build configuration files (convention over
    configuration), excellent integration in IDE's and Continuous Integration
    servers and so on.

    Best I can say is the following. I have noted the enthusiasm for Maven in
    our community. We will consider Maven as an option next time there is a need
    & opportunity to change our build system. For now, our build system works,
    doesn't require a lot of maintenance, and does a lot of useful stuff that we
    don't want to have to re-build.

    Meantime, as Tom also pointed out, Maven projects can use Mondrian and
    olap4j (and other Pentaho libraries) because we deploy components to a
    Maven-compatible repository.

    Julian

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  9. #9
    VanIngen, Erik (FIPS) Guest

    Default [Mondrian] Binding for mondrian.xsd

    Hi Mondrian,

    I am prototyping with a system that will generate SDMX from Mondrian. As in input it will probably use the RolapSchemes.

    Therefore a few questions:

    (1) Is there a Java binding available for this xsd /mondrian-src/mondrian-3.2.1.13885/lib/mondrian.xsd ? If not, how is a RolapScheme un-marshalled in Mondrian?

    (2) When publishing the RolapScheme in Mondrian, is it available through an URL?

    (3) Is Mondrian publishing the list of Rolapschemes as a webservice?

    Cheers,
    Erik




    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  10. #10
    Michele Rossi Guest

    Default Re: [Mondrian] xmla over olap4j server

    [ re sending to the whole list as requested by Julian ]

    Hi Julian,
    I've completed the first stage of the xmla-over-olap4j work.

    I still haven't found out how to create patch files - it can probably be
    done using the p4 client, I will look at it tomorrow.

    For now I am attaching to this email the three files that I updated and an
    example web.xml that shows how the servlet could be deployed.
    You can find most of my changes easily by searching for [MROSSI].

    Initially I tried to split out the servlet from the rest of the Mondrian
    codebase but the dependencies are many and go fairly deep.
    I am not sure that such an endeavour would be very valuable.
    After all there is nothing wrong in just using the whole mondrian jar as it
    is.

    I've tested my code using Excel and the SimbaO2X adapter.
    I can successfully connect to a Foodmart olap database in the following way:

    Excel-->Simba-->My Server with the modified DefaultXmlaServlet-->Olap4j Xmla
    Driver-->A standard mondrian installation with a standard xmla servlet.

    I will need to make some more changes to handle the credentials passed by
    Excel in the XMLA requests.
    I did most of the work last year but never contributed it back.

    What do you think?
    How do you think I should proceed from this point?

    Many thanks!
    Michele



    On 11 March 2011 17:56, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    >
    >
    > ------------------------------
    > *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > *Sent:* Friday, March 11, 2011 1:43 AM
    > *To:* mondrian (AT) pentaho (DOT) org; jhyde (AT) pentaho (DOT) 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
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  11. #11
    Julian Hyde Guest

    Default RE: [Mondrian] xmla over olap4j server

    Michele,

    I have checked in your changes as change 14208. I moved things around a bit
    -- I moved your olap4j connection factory out of XmlaServlet into a new
    derived class, Olap4jXmlaServlet. And the previous functionality, to start
    an embedded mondrian server, is in a new subclass MondrianXmlaServlet.

    I hope that I have preserved the intent of your changes.

    Thanks for the contribution. It definitely moves us down the road to an XMLA
    server that is independent of mondrian.

    Other users (including Pentaho BI server team), take note: Applications that
    used DefaultXmlaServlet should probably now use MondrianXmlaServlet.

    Julian


    _____

    From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    Sent: Friday, April 15, 2011 1:36 AM
    To: Mondrian developer mailing list
    Cc: jhyde (AT) pentaho (DOT) com
    Subject: Re: [Mondrian] xmla over olap4j server


    [ re sending to the whole list as requested by Julian ]

    Hi Julian,
    I've completed the first stage of the xmla-over-olap4j work.

    I still haven't found out how to create patch files - it can probably be
    done using the p4 client, I will look at it tomorrow.

    For now I am attaching to this email the three files that I updated and an
    example web.xml that shows how the servlet could be deployed.
    You can find most of my changes easily by searching for [MROSSI].

    Initially I tried to split out the servlet from the rest of the Mondrian
    codebase but the dependencies are many and go fairly deep.
    I am not sure that such an endeavour would be very valuable.
    After all there is nothing wrong in just using the whole mondrian jar as it
    is.

    I've tested my code using Excel and the SimbaO2X adapter.
    I can successfully connect to a Foodmart olap database in the following way:

    Excel-->Simba-->My Server with the modified DefaultXmlaServlet-->Olap4j Xmla
    Driver-->A standard mondrian installation with a standard xmla servlet.

    I will need to make some more changes to handle the credentials passed by
    Excel in the XMLA requests.
    I did most of the work last year but never contributed it back.

    What do you think?
    How do you think I should proceed from this point?

    Many thanks!
    Michele



    On 11 March 2011 17:56, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:





    _____

    From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    Sent: Friday, March 11, 2011 1:43 AM
    To: mondrian (AT) pentaho (DOT) org; jhyde (AT) pentaho (DOT) 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




    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  12. #12
    Andy Grohe Guest

    Default Re: [Mondrian] xmla over olap4j server

    What are the advantages of splitting out xmla from Mondrian to the community? At this time, they seem linked in my mind.

    Sent from my iPhone

    On Apr 18, 2011, at 11:20 PM, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    > Michele,
    >
    > I have checked in your changes as change 14208. I moved things around a bit -- I moved your olap4j connection factory out of XmlaServlet into a new derived class, Olap4jXmlaServlet. And the previous functionality, to start an embedded mondrian server, is in a new subclass MondrianXmlaServlet.
    >
    > I hope that I have preserved the intent of your changes.
    >
    > Thanks for the contribution. It definitely moves us down the road to an XMLA server that is independent of mondrian.
    >
    > Other users (including Pentaho BI server team), take note: Applications that used DefaultXmlaServlet should probably now use MondrianXmlaServlet.
    >
    > Julian
    >
    > From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > Sent: Friday, April 15, 2011 1:36 AM
    > To: Mondrian developer mailing list
    > Cc: jhyde (AT) pentaho (DOT) com
    > Subject: Re: [Mondrian] xmla over olap4j server
    >
    > [ re sending to the whole list as requested by Julian ]
    >
    > Hi Julian,
    > I've completed the first stage of the xmla-over-olap4j work.
    >
    > I still haven't found out how to create patch files - it can probably be done using the p4 client, I will look at it tomorrow.
    >
    > For now I am attaching to this email the three files that I updated and an example web.xml that shows how the servlet could be deployed.
    > You can find most of my changes easily by searching for [MROSSI].
    >
    > Initially I tried to split out the servlet from the rest of the Mondrian codebase but the dependencies are many and go fairly deep.
    > I am not sure that such an endeavour would be very valuable.
    > After all there is nothing wrong in just using the whole mondrian jar as it is.
    >
    > I've tested my code using Excel and the SimbaO2X adapter.
    > I can successfully connect to a Foodmart olap database in the following way:
    >
    > Excel-->Simba-->My Server with the modified DefaultXmlaServlet-->Olap4j Xmla Driver-->A standard mondrian installation with a standard xmla servlet.
    >
    > I will need to make some more changes to handle the credentials passed by Excel in the XMLA requests.
    > I did most of the work last year but never contributed it back.
    >
    > What do you think?
    > How do you think I should proceed from this point?
    >
    > Many thanks!
    > Michele
    >
    >
    >
    > On 11 March 2011 17:56, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >
    >
    > From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > Sent: Friday, March 11, 2011 1:43 AM
    > To: mondrian (AT) pentaho (DOT) org; jhyde (AT) pentaho (DOT) 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
    >
    >
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  13. #13
    Michele Rossi Guest

    Default Re: [Mondrian] xmla over olap4j server

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  14. #14
    Andy Grohe Guest

    Default Re: [Mondrian] xmla over olap4j server

    I think that states it clearly.

    Now we just need more olap4j implementations that Mondrian.

    So the xmla server requires an olap4j implementation in the engine side?

    Thanks

    Sent from my iPhone

    On Apr 19, 2011, at 8:00 AM, Michele Rossi <m.rossi (AT) iontrading (DOT) com> wrote:

    > hi,
    > The xmla servlet is not actually being split from the mondrian codebase (at least for now).
    > However its functionality is very distinct from Mondrian and refactoring the two functional areas is a matter of clean design and separation of concerns.
    >
    > Having an XMLA Servlet that can rely on a standard OLAP4J driver instead of the native mondrian API will allow other OLAP engines that have an OLAP4J driver to be exposed via XMLA.
    >
    > Another angle on this is that until now mondrian has been both a server (xmla) and an aggregation engine.
    > The idea is to split the two things.
    > Mondrian can keep being an engine, and the XMLA Servlet allows anyone with an OLAP driver to become an OLAP Server.
    >
    > Julian can probably put it in a better way.
    >
    > thanks,
    > Michele
    >
    >
    >
    >
    > On 19 April 2011 14:17, Andy Grohe <agrohe21 (AT) gmail (DOT) com> wrote:
    > What are the advantages of splitting out xmla from Mondrian to the community? At this time, they seem linked in my mind.
    >
    > Sent from my iPhone
    >
    > On Apr 18, 2011, at 11:20 PM, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >
    >> Michele,
    >>
    >> I have checked in your changes as change 14208. I moved things around a bit -- I moved your olap4j connection factory out of XmlaServlet into a new derived class, Olap4jXmlaServlet. And the previous functionality, to start an embedded mondrian server, is in a new subclass MondrianXmlaServlet.
    >>
    >> I hope that I have preserved the intent of your changes.
    >>
    >> Thanks for the contribution. It definitely moves us down the road to an XMLA server that is independent of mondrian.
    >>
    >> Other users (including Pentaho BI server team), take note: Applications that used DefaultXmlaServlet should probably now use MondrianXmlaServlet.
    >>
    >> Julian
    >>
    >> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> Sent: Friday, April 15, 2011 1:36 AM
    >> To: Mondrian developer mailing list
    >> Cc: jhyde (AT) pentaho (DOT) com
    >> Subject: Re: [Mondrian] xmla over olap4j server
    >>
    >> [ re sending to the whole list as requested by Julian ]
    >>
    >> Hi Julian,
    >> I've completed the first stage of the xmla-over-olap4j work.
    >>
    >> I still haven't found out how to create patch files - it can probably be done using the p4 client, I will look at it tomorrow.
    >>
    >> For now I am attaching to this email the three files that I updated and an example web.xml that shows how the servlet could be deployed.
    >> You can find most of my changes easily by searching for [MROSSI].
    >>
    >> Initially I tried to split out the servlet from the rest of the Mondrian codebase but the dependencies are many and go fairly deep.
    >> I am not sure that such an endeavour would be very valuable.
    >> After all there is nothing wrong in just using the whole mondrian jar as it is.
    >>
    >> I've tested my code using Excel and the SimbaO2X adapter.
    >> I can successfully connect to a Foodmart olap database in the following way:
    >>
    >> Excel-->Simba-->My Server with the modified DefaultXmlaServlet-->Olap4j Xmla Driver-->A standard mondrian installation with a standard xmla servlet.
    >>
    >> I will need to make some more changes to handle the credentials passed by Excel in the XMLA requests.
    >> I did most of the work last year but never contributed it back.
    >>
    >> What do you think?
    >> How do you think I should proceed from this point?
    >>
    >> Many thanks!
    >> Michele
    >>
    >>
    >>
    >> On 11 March 2011 17:56, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>
    >>
    >> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> Sent: Friday, March 11, 2011 1:43 AM
    >> To: mondrian (AT) pentaho (DOT) org; jhyde (AT) pentaho (DOT) 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
    >>
    >>
    >> _______________________________________________
    >> Mondrian mailing list
    >> Mondrian (AT) pentaho (DOT) org
    >> http://lists.pentaho.org/mailman/listinfo/mondrian

    >
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian
    >
    >
    >
    >
    > --
    >
    >
    > Michele Rossi
    >
    > <image001.jpg>
    >
    > Via San Martino, 52, 56125 Pisa, ITALY
    > T: +39 050 220 3894
    > m.rossi (AT) iontrading (DOT) com
    > http://www.iontrading.com
    >
    >
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  15. #15
    Michele Rossi Guest

    Default Re: [Mondrian] xmla over olap4j server

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  16. #16
    Paul Stoellberger Guest

    Default Re: [Mondrian] xmla over olap4j server

    there will be a oracle olap driver at some point too. luc said its on his todo list.

    but i'd rather use the olap4j api directly than exposing my olap4j as xmla. this is only beneficial if you have a nice existing xmla client that you want to use for accessing system.

    i think julians point with this refactoring is to hide the mondrian api and making the olap4j api the only one that matters.
    and as a nice side effect you get an xmla server for all olap4j compatible systems.

    i would expect the xmla-servlet code to move to olap4j at some point.

    paul


    Am 19.04.2011 um 14:56 schrieb Michele Rossi <m.rossi (AT) iontrading (DOT) com>:

    > you're right, at the moment the only open source implementation of olap4j that I know of is mondrian.
    > But for example we have decided to use Olap4j as API for our internal proprietary system too.
    > In the future there might be more "mondrians" out there.. unlikely but who knows.
    >
    > Michele
    >
    >
    > On 19 April 2011 15:44, Andy Grohe <agrohe21 (AT) gmail (DOT) com> wrote:
    > I think that states it clearly.
    >
    > Now we just need more olap4j implementations that Mondrian.
    >
    > So the xmla server requires an olap4j implementation in the engine side?
    >
    > Thanks
    >
    > Sent from my iPhone
    >
    > On Apr 19, 2011, at 8:00 AM, Michele Rossi <m.rossi (AT) iontrading (DOT) com> wrote:
    >
    >> hi,
    >> The xmla servlet is not actually being split from the mondrian codebase (at least for now).
    >> However its functionality is very distinct from Mondrian and refactoring the two functional areas is a matter of clean design and separation of concerns.
    >>
    >> Having an XMLA Servlet that can rely on a standard OLAP4J driver instead of the native mondrian API will allow other OLAP engines that have an OLAP4J driver to be exposed via XMLA.
    >>
    >> Another angle on this is that until now mondrian has been both a server (xmla) and an aggregation engine.
    >> The idea is to split the two things.
    >> Mondrian can keep being an engine, and the XMLA Servlet allows anyone with an OLAP driver to become an OLAP Server.
    >>
    >> Julian can probably put it in a better way.
    >>
    >> thanks,
    >> Michele
    >>
    >>
    >>
    >>
    >> On 19 April 2011 14:17, Andy Grohe <agrohe21 (AT) gmail (DOT) com> wrote:
    >> What are the advantages of splitting out xmla from Mondrian to the community? At this time, they seem linked in my mind.
    >>
    >> Sent from my iPhone
    >>
    >> On Apr 18, 2011, at 11:20 PM, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>
    >>> Michele,
    >>>
    >>> I have checked in your changes as change 14208. I moved things around a bit -- I moved your olap4j connection factory out of XmlaServlet into a new derived class, Olap4jXmlaServlet. And the previous functionality, to start an embedded mondrian server, is in a new subclass MondrianXmlaServlet.
    >>>
    >>> I hope that I have preserved the intent of your changes.
    >>>
    >>> Thanks for the contribution. It definitely moves us down the road to an XMLA server that is independent of mondrian.
    >>>
    >>> Other users (including Pentaho BI server team), take note: Applications that used DefaultXmlaServlet should probably now use MondrianXmlaServlet.
    >>>
    >>> Julian
    >>>
    >>> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>> Sent: Friday, April 15, 2011 1:36 AM
    >>> To: Mondrian developer mailing list
    >>> Cc: jhyde (AT) pentaho (DOT) com
    >>> Subject: Re: [Mondrian] xmla over olap4j server
    >>>
    >>> [ re sending to the whole list as requested by Julian ]
    >>>
    >>> Hi Julian,
    >>> I've completed the first stage of the xmla-over-olap4j work.
    >>>
    >>> I still haven't found out how to create patch files - it can probably be done using the p4 client, I will look at it tomorrow.
    >>>
    >>> For now I am attaching to this email the three files that I updated and an example web.xml that shows how the servlet could be deployed.
    >>> You can find most of my changes easily by searching for [MROSSI].
    >>>
    >>> Initially I tried to split out the servlet from the rest of the Mondrian codebase but the dependencies are many and go fairly deep.
    >>> I am not sure that such an endeavour would be very valuable.
    >>> After all there is nothing wrong in just using the whole mondrian jar as it is.
    >>>
    >>> I've tested my code using Excel and the SimbaO2X adapter.
    >>> I can successfully connect to a Foodmart olap database in the following way:
    >>>
    >>> Excel-->Simba-->My Server with the modified DefaultXmlaServlet-->Olap4j Xmla Driver-->A standard mondrian installation with a standard xmla servlet.
    >>>
    >>> I will need to make some more changes to handle the credentials passed by Excel in the XMLA requests.
    >>> I did most of the work last year but never contributed it back.
    >>>
    >>> What do you think?
    >>> How do you think I should proceed from this point?
    >>>
    >>> Many thanks!
    >>> Michele
    >>>
    >>>
    >>>
    >>> On 11 March 2011 17:56, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>>
    >>>
    >>> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>> Sent: Friday, March 11, 2011 1:43 AM
    >>> To: mondrian (AT) pentaho (DOT) org; jhyde (AT) pentaho (DOT) 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
    >>>
    >>>
    >>> _______________________________________________
    >>> Mondrian mailing list
    >>> Mondrian (AT) pentaho (DOT) org
    >>> http://lists.pentaho.org/mailman/listinfo/mondrian

    >>
    >> _______________________________________________
    >> Mondrian mailing list
    >> Mondrian (AT) pentaho (DOT) org
    >> http://lists.pentaho.org/mailman/listinfo/mondrian
    >>
    >>
    >>
    >>
    >> --
    >>
    >>
    >> Michele Rossi
    >>
    >> <image001.jpg>
    >>
    >> Via San Martino, 52, 56125 Pisa, ITALY
    >> T: +39 050 220 3894
    >> m.rossi (AT) iontrading (DOT) com
    >> http://www.iontrading.com
    >>
    >>
    >> _______________________________________________
    >> Mondrian mailing list
    >> Mondrian (AT) pentaho (DOT) org
    >> http://lists.pentaho.org/mailman/listinfo/mondrian

    >
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian
    >
    >
    >
    >
    > --
    >
    >
    > Michele Rossi
    >
    > <image001.jpg>
    >
    > Via San Martino, 52, 56125 Pisa, ITALY
    > T: +39 050 220 3894
    > m.rossi (AT) iontrading (DOT) com
    > http://www.iontrading.com
    >
    >
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  17. #17
    Julian Hyde Guest

    Default RE: [Mondrian] xmla over olap4j server

    Michele Rossi wrote:

    you're right, at the moment the only open source implementation of olap4j
    that I know of is mondrian.

    Well, there's the XMLA driver for olap4j. You can use that to talk to a lot
    of databases, including the open source OLAP database, Palo.

    And there is your use case: using the XMLA driver plus server to build a
    proxy. Pretty useless on its own, but you could extend it to do some cool
    architectural things: access control, routing, caching.

    But for example we have decided to use Olap4j as API for our internal
    proprietary system too.
    In the future there might be more "mondrians" out there.. unlikely but who
    knows.

    Of course one hopes that there will be multiple implementations of a
    specification. But a good spec it is useful in itself; it saves a lot of
    design time if someone has already designed an API, test suite and tool set
    for you. That's why I would advise others building OLAP capabilities to
    implement the olap4j spec.

    Other reasons to split out the XMLA server from mondrian:

    1. Mondrian is a large piece of code. It is difficult to maintain and
    especially difficult to contribute to. If we can carve it up into smaller
    modules, we get more contributions.

    2. The XMLA server was using mondrian's legacy API. We want to remove that
    API someday.

    3. The olap4j API is intentionally similar to XMLA. You'll find similarly
    named classes and attributes in both. Making the XMLA server run on top of
    the olap4j API.

    4. Modularizing the XMLA server (i.e. removing unnecessary dependencies on
    Mondrian) allows new architectural options. I had never dreamed that someone
    would want to build an XMLA proxy.

    5. Mondrian is an embeddable engine, but it doesn't quite have the services
    necessary to make it a full server. (The ability to run as a service, e.g.
    start up when the O/S starts; Authentication; Assignment of roles based on
    who is making the connection; A repository of schemas.) Mondrian's XMLA
    server had some of those services. Refactoring forced us to make those
    services explicit, and pluggable.

    Julian


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.