lmappletserver-developers — Developer discussions for lmappletserver

Re: [Lmappletserver-developers] Problem with saved searches when adding a new metadata after the search is saved

[Roberto M. <rob...@gm...>]

Hi Peter,

Thanks for the tip. I have already fixed, tested and committed the 
changes regarding this issue.

Regards,
Roberto

Peter Salomonsen wrote:
> Hi Roberto,
>
> We should make the default behavior so that when leaving the 
> lmappletserver_metaloginterceptors.properties file empty, then the 
> DefaultInterceptor should just return
>
>    return ctx.proceed();
>
> I or you can fix this - tell me what's best. We should also rename the 
> properties file so that it is called 
> lmappletserver_addons_ejbinterceptors (more generic). I also see that 
> the interceptor code is using HashMap while it rather could be using 
> HashSet (minor details :)...
>
> regards,
>
> Peter
>
> On 10/30/07, *Roberto MIlev* <rob...@gm... 
> <mailto:rob...@gm...>> wrote:
>
>     Hi Peter,
>
>     First an update regarding the interceptors and my lmappletserver
>     setup.
>     Leaving the lmappletserver_metaloginterceptors.properties file empty
>     defaults to the DefaultInterceptor being called. However this
>     caused all
>     the queries to return null. I read up on writing around methods, and I
>     cant seem to find the InvocationContext.proceed() signal being
>     called by
>     the default interceptor. I got everything working once I explicitly
>     turned the interceptor off.
>
>     Regards,
>     Roberto
>
>     Roberto Milev wrote:
>     > Hi Peter,
>     >
>     > I changed and commiter orm.xml. I will be looking at the interceptor
>     > stuff next. I will keep you posted.
>     >
>     > Regards,
>     > Roberto
>     >
>     > On 10/23/07, * Peter Salomonsen* <co...@pe...
>     <mailto:co...@pe...>
>     > <mailto: co...@pe...
>     <mailto:co...@pe...>>> wrote:
>     >
>     >     Hi Robert,
>     >
>     >     I've attached a metaloginterceptors property file example.
>     This is
>     >     a feature me and Jon has been working on, and the purpose is
>     to be
>     >     able to intercept calls within the lmappletserver-addons ejb3
>     >     session beans using default EJB3 interceptors.
>     >
>     >     I wasn't aware that it was a requirement to have this file, so
>     >     this is a bug, the intention is that this file is not required,
>     >     but an option if you need to create an interceptor for some
>     >     reason. And it really shouldn't be called
>     metaloginterceptor, as
>     >     it is really intercepting everything - this naming is related to
>     >     our specific use case - we should change this however to a more
>     >     generic name (maybe just interceptor).
>     >
>     >     To tell you about our use case - we use interceptors to
>     perform a
>     >     parallell query on searchLogEntries (historic searches). We
>     have a
>     >     MetaDataLogEntry table with more than a billion of records, and
>     >     the standard query produced by searchLogEntries is not able to
>     >     handle this. The strategy is then to intercept the call, and
>     >     duplicate it to run in multiple processes / servers on smaller
>     >     dataset partitions, and collect the resultsets when sufficient
>     >     amount of threads has returned. Then we also gain our desired
>     >     speed (which is instant results).
>     >
>     >     About table names - since the case problem is TopLink specific,
>     >     could we rather solve this using an orm.xml for the unit tests?
>     >     Instead of using the Table annotation?
>     >
>     >     regards,
>     >
>     >     Peter
>     >
>     >
>     >     On 10/21/07, *Roberto MIlev* < rob...@gm...
>     <mailto:rob...@gm...>
>     >     <mailto:rob...@gm...
>     <mailto:rob...@gm...>>> wrote:
>     >
>     >         Hi Peter,
>     >
>     >         You will find the changes you requested committed to SVN. A
>     >         few notes:
>     >
>     >         - I was only abe to test the shownColumns changes with dummy
>     >         hardcoded
>     >         data, beacuse I am getting errors due to missing resource -
>     >         lmappletserver_metaloginterceptors. I am not able to
>     find this
>     >         resource
>     >         in the project. Perhaps you can shed some light on this?
>     >         - In the mean time I also resolved the issue with the
>     junt tests
>     >         failing. The thing was that the Toplink JPA always
>     creates the
>     >         tables
>     >         based on the name of the Entity in uppercase. This was not
>     >         visible until
>     >         i install everything on Linux. the solution is to always
>     >         specify the
>     >         name attribute in the @Table annotation.
>     >
>     >         Regards,
>     >         Roberto
>     >
>     >         Peter Salomonsen wrote:
>     >         > Hi,
>     >         >
>     >         > I was just going to update my metadata table by adding
>     a new
>     >         metadata
>     >         > (new column). I found that the searchdto has a showcolumns
>     >         boolean
>     >         > array, and this causes the requirement that the metadata
>     >         cannot change
>     >         > order or change in size. What happened in my case was that
>     >         > listmetadata returned more columns than the showcolumns
>     >         array, and
>     >         > this caused an ArrayIndexOutOfBounds exception in
>     >         > MetaDataSearchExecutor.java on the showcolumns array.
>     >         >
>     >         > I think this has to be solved differently. The
>     showcolumns array
>     >         > should rather be a list of metadata_ids rather than
>     booleans
>     >         - so that
>     >         > it is not dependent on me not changing the metadata
>     order or
>     >         number of
>     >         > metadatas.
>     >         >
>     >         > Can you fix this?
>     >         >
>     >         > regards,
>     >         >
>     >         > Peter
>     >
>     >
>     >
>     >
>     >
>     >
>     > --
>     > Regards,
>     > Roberto Milev
>
>

Re: [Lmappletserver-developers] Problem with saved searches when adding a new metadata after the search is saved

[Peter S. <co...@pe...>]

Hi Roberto,

We should make the default behavior so that when leaving the
lmappletserver_metaloginterceptors.properties file empty, then the
DefaultInterceptor should just return

   return ctx.proceed();

I or you can fix this - tell me what's best. We should also rename the
properties file so that it is called lmappletserver_addons_ejbinterceptors
(more generic). I also see that the interceptor code is using HashMap while
it rather could be using HashSet (minor details :)...

regards,

Peter

On 10/30/07, Roberto MIlev <rob...@gm...> wrote:
>
> Hi Peter,
>
> First an update regarding the interceptors and my lmappletserver setup.
> Leaving the lmappletserver_metaloginterceptors.properties file empty
> defaults to the DefaultInterceptor being called. However this caused all
> the queries to return null. I read up on writing around methods, and I
> cant seem to find the InvocationContext.proceed() signal being called by
> the default interceptor. I got everything working once I explicitly
> turned the interceptor off.
>
> Regards,
> Roberto
>
> Roberto Milev wrote:
> > Hi Peter,
> >
> > I changed and commiter orm.xml. I will be looking at the interceptor
> > stuff next. I will keep you posted.
> >
> > Regards,
> > Roberto
> >
> > On 10/23/07, * Peter Salomonsen* <co...@pe...
> > <mailto:co...@pe...>> wrote:
> >
> >     Hi Robert,
> >
> >     I've attached a metaloginterceptors property file example. This is
> >     a feature me and Jon has been working on, and the purpose is to be
> >     able to intercept calls within the lmappletserver-addons ejb3
> >     session beans using default EJB3 interceptors.
> >
> >     I wasn't aware that it was a requirement to have this file, so
> >     this is a bug, the intention is that this file is not required,
> >     but an option if you need to create an interceptor for some
> >     reason. And it really shouldn't be called metaloginterceptor, as
> >     it is really intercepting everything - this naming is related to
> >     our specific use case - we should change this however to a more
> >     generic name (maybe just interceptor).
> >
> >     To tell you about our use case - we use interceptors to perform a
> >     parallell query on searchLogEntries (historic searches). We have a
> >     MetaDataLogEntry table with more than a billion of records, and
> >     the standard query produced by searchLogEntries is not able to
> >     handle this. The strategy is then to intercept the call, and
> >     duplicate it to run in multiple processes / servers on smaller
> >     dataset partitions, and collect the resultsets when sufficient
> >     amount of threads has returned. Then we also gain our desired
> >     speed (which is instant results).
> >
> >     About table names - since the case problem is TopLink specific,
> >     could we rather solve this using an orm.xml for the unit tests?
> >     Instead of using the Table annotation?
> >
> >     regards,
> >
> >     Peter
> >
> >
> >     On 10/21/07, *Roberto MIlev* <rob...@gm...
> >     <mailto:rob...@gm...>> wrote:
> >
> >         Hi Peter,
> >
> >         You will find the changes you requested committed to SVN. A
> >         few notes:
> >
> >         - I was only abe to test the shownColumns changes with dummy
> >         hardcoded
> >         data, beacuse I am getting errors due to missing resource -
> >         lmappletserver_metaloginterceptors. I am not able to find this
> >         resource
> >         in the project. Perhaps you can shed some light on this?
> >         - In the mean time I also resolved the issue with the junt tests
> >         failing. The thing was that the Toplink JPA always creates the
> >         tables
> >         based on the name of the Entity in uppercase. This was not
> >         visible until
> >         i install everything on Linux. the solution is to always
> >         specify the
> >         name attribute in the @Table annotation.
> >
> >         Regards,
> >         Roberto
> >
> >         Peter Salomonsen wrote:
> >         > Hi,
> >         >
> >         > I was just going to update my metadata table by adding a new
> >         metadata
> >         > (new column). I found that the searchdto has a showcolumns
> >         boolean
> >         > array, and this causes the requirement that the metadata
> >         cannot change
> >         > order or change in size. What happened in my case was that
> >         > listmetadata returned more columns than the showcolumns
> >         array, and
> >         > this caused an ArrayIndexOutOfBounds exception in
> >         > MetaDataSearchExecutor.java on the showcolumns array.
> >         >
> >         > I think this has to be solved differently. The showcolumns
> array
> >         > should rather be a list of metadata_ids rather than booleans
> >         - so that
> >         > it is not dependent on me not changing the metadata order or
> >         number of
> >         > metadatas.
> >         >
> >         > Can you fix this?
> >         >
> >         > regards,
> >         >
> >         > Peter
> >
> >
> >
> >
> >
> >
> > --
> > Regards,
> > Roberto Milev
>

Re: [Lmappletserver-developers] Media columns in the MetaLogViewer

[Peter S. <co...@pe...>]

Hi Roberto,

I'm not a file system expert - so I cannot tell whats the most optimal
regarding how many files to put in a folder - but your suggestion sounds
interesting. This means that we also can keep actual media file names since
each log entry has its own folder.

I'd also like a comment from Jon on this.

cheers,

Peter

On 11/1/07, Roberto Milev <rob...@gm...> wrote:
>
> Hi Peter,
>
> About the folder structure, an alternative approach would be to organize
> it to reflect the actual MetaDataLogEntry id. for example:
>
> MetaDataLogEntry id = 1001 - would map to /1/0/0/1
> MetaDataLogEntry id = 1002 - would map to /1/0/0/3
> .. etc
> MetaDataLogEntry id = 1011 - would map to /1/0/1/1
>
> in this manner every media file could be easily located within the data
> structure.
>
> I will start setting the infrastructure for the Phase One of the task. I
> will keep you posted of the progress.
>
> Regards,
> Roberto
>
>
> On 10/30/07, Peter Salomonsen <co...@pe...> wrote:
> >
> > Hi Roberto,
> >
> > I think we should split the project in two phases:
> >
> > Phase One:
> >
> > Media upload mechanisms and media file download (with correct mime types
> > etc) - but no media player. So the play button would go directly to the
> > multimediaservlet.
> >
> > Phase Two:
> >
> > Embedded Mediaplayer using e.g. FMJ.
> >
> > About the file sys:
> >
> > Splitting on date folders is good (to speed of access), but in case of
> > massive uploads, it might be better to split on MetaDataLogEntry id ranges.
> > Maybe the folder structure should reflect this - e.g. 1000 files per
> > folder (this could be customizable).
> >
> > I see the challenges regarding separating the project, and the challenge
> > regarding different data types we've also had with other data types. The
> > MetaDataLogEntry table should maybe have one field per datatype such as with
> > the numericvalue field - that we don't use today - but maybe we should.
> >
> > regards,
> >
> > Peter
> >
> > On 10/30/07, Roberto MIlev < rob...@gm...> wrote:
> > >
> > > Hi Peter,
> > >
> > > Please find attached my ideas on on implementing the new feature. My
> > > initial rough estimate for implementation is around 80 man hours.
> > >
> > > Please give me your thoughts.
> > >
> > > Regards,
> > > Roberto
> > >
> > > Peter Salomonsen wrote:
> > > > Hi Roberto -
> > > >
> > > > how is it going with the interceptor stuff - did you get to
> > > understand
> > > > how it works?
> > > >
> > > > I have a new project proposal for you. We'd like to add multimedia
> > > > capabilities to the MetaLogViewer - so that you can attach
> > > multimedia
> > > > clips to a MetaDataLogEntry. The idea will be to create new columns
> > > > that contains multimedia file names, and with a possibility to
> > > launch
> > > > a player to view /play. Embedded players would be very nice -
> > > however
> > > > supporting all the varieties of file formats may be difficult. Have
> > > to
> > > > consider whether to stick to one format ( e.g. ogg/vorbis/theora -
> > > and
> > > > use e.g. the flumotion cortado applet), or support multiple formats,
> > > > and test frameworks such as fmj (which is an open source impl of
> > > java
> > > > media framework).
> > > >
> > > > I don't think the media content itself should be stored in the
> > > > MetaDataLogEntry table, but the file name could be, and there should
> > > > be a file structure for easy retrieval.
> > > >
> > > > Get the idea?
> > > >
> > > > This makes the lmappletserver-addons.jar even more massive,  and the
> > >
> > > > question is if we could create a new Multimedia-extensions module?
> > > > Should this even be a whole new separate project?
> > > >
> > > > Is this a project for you? In that case some sketches and models
> > > would
> > > > be nice, would you have a look at it, and think of a solution
> > > proposal?
> > > >
> > > > regards,
> > > >
> > > > Peter
> > > >
> > > > On 10/23/07, *Roberto Milev* < rob...@gm...
> > > > <mailto:rob...@gm...>> wrote:
> > > >
> > > >     Hi Peter,
> > > >
> > > >     I changed and commiter orm.xml. I will be looking at the
> > > >     interceptor stuff next. I will keep you posted.
> > > >
> > > >     Regards,
> > > >     Roberto
> > > >
> > > >
> > > >     On 10/23/07, * Peter Salomonsen* < co...@pe...
> > > >     <mailto: co...@pe...>> wrote:
> > > >
> > > >         Hi Robert,
> > > >
> > > >         I've attached a metaloginterceptors property file example.
> > > >         This is a feature me and Jon has been working on, and the
> > > >         purpose is to be able to intercept calls within the
> > > >         lmappletserver-addons ejb3 session beans using default EJB3
> > > >         interceptors.
> > > >
> > > >         I wasn't aware that it was a requirement to have this file,
> > > so
> > > >         this is a bug, the intention is that this file is not
> > > >         required, but an option if you need to create an interceptor
> > > >         for some reason. And it really shouldn't be called
> > > >         metaloginterceptor, as it is really intercepting everything
> > > -
> > > >         this naming is related to our specific use case - we should
> > > >         change this however to a more generic name (maybe just
> > > >         interceptor).
> > > >
> > > >         To tell you about our use case - we use interceptors to
> > > >         perform a parallell query on searchLogEntries (historic
> > > >         searches). We have a MetaDataLogEntry table with more than a
> > >
> > > >         billion of records, and the standard query produced by
> > > >         searchLogEntries is not able to handle this. The strategy is
> > > >         then to intercept the call, and duplicate it to run in
> > > >         multiple processes / servers on smaller dataset partitions,
> > > >         and collect the resultsets when sufficient amount of threads
> > > >         has returned. Then we also gain our desired speed (which is
> > > >         instant results).
> > > >
> > > >         About table names - since the case problem is TopLink
> > > >         specific, could we rather solve this using an orm.xml for
> > > the
> > > >         unit tests? Instead of using the Table annotation?
> > > >
> > > >         regards,
> > > >
> > > >         Peter
> > > >
> > > >
> > > >         On 10/21/07, *Roberto MIlev* < rob...@gm...
> > > >         <mailto: rob...@gm...>> wrote:
> > > >
> > > >             Hi Peter,
> > > >
> > > >             You will find the changes you requested committed to
> > > SVN.
> > > >             A few notes:
> > > >
> > > >             - I was only abe to test the shownColumns changes with
> > > >             dummy hardcoded
> > > >             data, beacuse I am getting errors due to missing
> > > resource -
> > > >             lmappletserver_metaloginterceptors. I am not able to
> > > find
> > > >             this resource
> > > >             in the project. Perhaps you can shed some light on this?
> > > >             - In the mean time I also resolved the issue with the
> > > junt
> > > >             tests
> > > >             failing. The thing was that the Toplink JPA always
> > > creates
> > > >             the tables
> > > >             based on the name of the Entity in uppercase. This was
> > > not
> > > >             visible until
> > > >             i install everything on Linux. the solution is to always
> > >
> > > >             specify the
> > > >             name attribute in the @Table annotation.
> > > >
> > > >             Regards,
> > > >             Roberto
> > > >
> > > >             Peter Salomonsen wrote:
> > > >             > Hi,
> > > >             >
> > > >             > I was just going to update my metadata table by adding
> > > a
> > > >             new metadata
> > > >             > (new column). I found that the searchdto has a
> > > >             showcolumns boolean
> > > >             > array, and this causes the requirement that the
> > > metadata
> > > >             cannot change
> > > >             > order or change in size. What happened in my case was
> > > that
> > > >             > listmetadata returned more columns than the
> > > showcolumns
> > > >             array, and
> > > >             > this caused an ArrayIndexOutOfBounds exception in
> > > >             > MetaDataSearchExecutor.java on the showcolumns array.
> > > >             >
> > > >             > I think this has to be solved differently. The
> > > >             showcolumns array
> > > >             > should rather be a list of metadata_ids rather than
> > > >             booleans - so that
> > > >             > it is not dependent on me not changing the metadata
> > > order
> > > >             or number of
> > > >             > metadatas.
> > > >             >
> > > >             > Can you fix this?
> > > >             >
> > > >             > regards,
> > > >             >
> > > >             > Peter
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >     --
> > > >     Regards,
> > > >     Roberto Milev
> > > >
> > > >
> > >
> > >
> >
>
>
> --
> Regards,
> Roberto Milev

Re: [Lmappletserver-developers] Media columns in the MetaLogViewer

[Roberto M. <rob...@gm...>]

Hi Peter,

About the folder structure, an alternative approach would be to organize it
to reflect the actual MetaDataLogEntry id. for example:

MetaDataLogEntry id = 1001 - would map to /1/0/0/1
MetaDataLogEntry id = 1002 - would map to /1/0/0/3
.. etc
MetaDataLogEntry id = 1011 - would map to /1/0/1/1

in this manner every media file could be easily located within the data
structure.

I will start setting the infrastructure for the Phase One of the task. I
will keep you posted of the progress.

Regards,
Roberto


On 10/30/07, Peter Salomonsen <co...@pe...> wrote:
>
> Hi Roberto,
>
> I think we should split the project in two phases:
>
> Phase One:
>
> Media upload mechanisms and media file download (with correct mime types
> etc) - but no media player. So the play button would go directly to the
> multimediaservlet.
>
> Phase Two:
>
> Embedded Mediaplayer using e.g. FMJ.
>
> About the file sys:
>
> Splitting on date folders is good (to speed of access), but in case of
> massive uploads, it might be better to split on MetaDataLogEntry id ranges.
> Maybe the folder structure should reflect this - e.g. 1000 files per
> folder (this could be customizable).
>
> I see the challenges regarding separating the project, and the challenge
> regarding different data types we've also had with other data types. The
> MetaDataLogEntry table should maybe have one field per datatype such as with
> the numericvalue field - that we don't use today - but maybe we should.
>
> regards,
>
> Peter
>
> On 10/30/07, Roberto MIlev <rob...@gm...> wrote:
> >
> > Hi Peter,
> >
> > Please find attached my ideas on on implementing the new feature. My
> > initial rough estimate for implementation is around 80 man hours.
> >
> > Please give me your thoughts.
> >
> > Regards,
> > Roberto
> >
> > Peter Salomonsen wrote:
> > > Hi Roberto -
> > >
> > > how is it going with the interceptor stuff - did you get to understand
> > > how it works?
> > >
> > > I have a new project proposal for you. We'd like to add multimedia
> > > capabilities to the MetaLogViewer - so that you can attach multimedia
> > > clips to a MetaDataLogEntry. The idea will be to create new columns
> > > that contains multimedia file names, and with a possibility to launch
> > > a player to view /play. Embedded players would be very nice - however
> > > supporting all the varieties of file formats may be difficult. Have to
> > > consider whether to stick to one format ( e.g. ogg/vorbis/theora - and
> >
> > > use e.g. the flumotion cortado applet), or support multiple formats,
> > > and test frameworks such as fmj (which is an open source impl of java
> > > media framework).
> > >
> > > I don't think the media content itself should be stored in the
> > > MetaDataLogEntry table, but the file name could be, and there should
> > > be a file structure for easy retrieval.
> > >
> > > Get the idea?
> > >
> > > This makes the lmappletserver-addons.jar even more massive,  and the
> > > question is if we could create a new Multimedia-extensions module?
> > > Should this even be a whole new separate project?
> > >
> > > Is this a project for you? In that case some sketches and models would
> > > be nice, would you have a look at it, and think of a solution
> > proposal?
> > >
> > > regards,
> > >
> > > Peter
> > >
> > > On 10/23/07, *Roberto Milev* <rob...@gm...
> > > <mailto:rob...@gm...>> wrote:
> > >
> > >     Hi Peter,
> > >
> > >     I changed and commiter orm.xml. I will be looking at the
> > >     interceptor stuff next. I will keep you posted.
> > >
> > >     Regards,
> > >     Roberto
> > >
> > >
> > >     On 10/23/07, * Peter Salomonsen* <co...@pe...
> > >     <mailto: co...@pe...>> wrote:
> > >
> > >         Hi Robert,
> > >
> > >         I've attached a metaloginterceptors property file example.
> > >         This is a feature me and Jon has been working on, and the
> > >         purpose is to be able to intercept calls within the
> > >         lmappletserver-addons ejb3 session beans using default EJB3
> > >         interceptors.
> > >
> > >         I wasn't aware that it was a requirement to have this file, so
> >
> > >         this is a bug, the intention is that this file is not
> > >         required, but an option if you need to create an interceptor
> > >         for some reason. And it really shouldn't be called
> > >         metaloginterceptor, as it is really intercepting everything -
> > >         this naming is related to our specific use case - we should
> > >         change this however to a more generic name (maybe just
> > >         interceptor).
> > >
> > >         To tell you about our use case - we use interceptors to
> > >         perform a parallell query on searchLogEntries (historic
> > >         searches). We have a MetaDataLogEntry table with more than a
> > >         billion of records, and the standard query produced by
> > >         searchLogEntries is not able to handle this. The strategy is
> > >         then to intercept the call, and duplicate it to run in
> > >         multiple processes / servers on smaller dataset partitions,
> > >         and collect the resultsets when sufficient amount of threads
> > >         has returned. Then we also gain our desired speed (which is
> > >         instant results).
> > >
> > >         About table names - since the case problem is TopLink
> > >         specific, could we rather solve this using an orm.xml for the
> > >         unit tests? Instead of using the Table annotation?
> > >
> > >         regards,
> > >
> > >         Peter
> > >
> > >
> > >         On 10/21/07, *Roberto MIlev* <rob...@gm...
> > >         <mailto: rob...@gm...>> wrote:
> > >
> > >             Hi Peter,
> > >
> > >             You will find the changes you requested committed to SVN.
> > >             A few notes:
> > >
> > >             - I was only abe to test the shownColumns changes with
> > >             dummy hardcoded
> > >             data, beacuse I am getting errors due to missing resource
> > -
> > >             lmappletserver_metaloginterceptors. I am not able to find
> > >             this resource
> > >             in the project. Perhaps you can shed some light on this?
> > >             - In the mean time I also resolved the issue with the junt
> > >             tests
> > >             failing. The thing was that the Toplink JPA always creates
> >
> > >             the tables
> > >             based on the name of the Entity in uppercase. This was not
> > >             visible until
> > >             i install everything on Linux. the solution is to always
> > >             specify the
> > >             name attribute in the @Table annotation.
> > >
> > >             Regards,
> > >             Roberto
> > >
> > >             Peter Salomonsen wrote:
> > >             > Hi,
> > >             >
> > >             > I was just going to update my metadata table by adding a
> > >             new metadata
> > >             > (new column). I found that the searchdto has a
> > >             showcolumns boolean
> > >             > array, and this causes the requirement that the metadata
> > >             cannot change
> > >             > order or change in size. What happened in my case was
> > that
> > >             > listmetadata returned more columns than the showcolumns
> > >             array, and
> > >             > this caused an ArrayIndexOutOfBounds exception in
> > >             > MetaDataSearchExecutor.java on the showcolumns array.
> > >             >
> > >             > I think this has to be solved differently. The
> > >             showcolumns array
> > >             > should rather be a list of metadata_ids rather than
> > >             booleans - so that
> > >             > it is not dependent on me not changing the metadata
> > order
> > >             or number of
> > >             > metadatas.
> > >             >
> > >             > Can you fix this?
> > >             >
> > >             > regards,
> > >             >
> > >             > Peter
> > >
> > >
> > >
> > >
> > >
> > >
> > >     --
> > >     Regards,
> > >     Roberto Milev
> > >
> > >
> >
> >
>


-- 
Regards,
Roberto Milev

Re: [Lmappletserver-developers] Media columns in the MetaLogViewer

[Peter S. <co...@pe...>]

Hi Roberto,

I think we should split the project in two phases:

Phase One:

Media upload mechanisms and media file download (with correct mime types
etc) - but no media player. So the play button would go directly to the
multimediaservlet.

Phase Two:

Embedded Mediaplayer using e.g. FMJ.

About the file sys:

Splitting on date folders is good (to speed of access), but in case of
massive uploads, it might be better to split on MetaDataLogEntry id ranges.
Maybe the folder structure should reflect this - e.g. 1000 files per folder
(this could be customizable).

I see the challenges regarding separating the project, and the challenge
regarding different data types we've also had with other data types. The
MetaDataLogEntry table should maybe have one field per datatype such as with
the numericvalue field - that we don't use today - but maybe we should.

regards,

Peter

On 10/30/07, Roberto MIlev <rob...@gm...> wrote:
>
> Hi Peter,
>
> Please find attached my ideas on on implementing the new feature. My
> initial rough estimate for implementation is around 80 man hours.
>
> Please give me your thoughts.
>
> Regards,
> Roberto
>
> Peter Salomonsen wrote:
> > Hi Roberto -
> >
> > how is it going with the interceptor stuff - did you get to understand
> > how it works?
> >
> > I have a new project proposal for you. We'd like to add multimedia
> > capabilities to the MetaLogViewer - so that you can attach multimedia
> > clips to a MetaDataLogEntry. The idea will be to create new columns
> > that contains multimedia file names, and with a possibility to launch
> > a player to view /play. Embedded players would be very nice - however
> > supporting all the varieties of file formats may be difficult. Have to
> > consider whether to stick to one format ( e.g. ogg/vorbis/theora - and
> > use e.g. the flumotion cortado applet), or support multiple formats,
> > and test frameworks such as fmj (which is an open source impl of java
> > media framework).
> >
> > I don't think the media content itself should be stored in the
> > MetaDataLogEntry table, but the file name could be, and there should
> > be a file structure for easy retrieval.
> >
> > Get the idea?
> >
> > This makes the lmappletserver-addons.jar even more massive,  and the
> > question is if we could create a new Multimedia-extensions module?
> > Should this even be a whole new separate project?
> >
> > Is this a project for you? In that case some sketches and models would
> > be nice, would you have a look at it, and think of a solution proposal?
> >
> > regards,
> >
> > Peter
> >
> > On 10/23/07, *Roberto Milev* <rob...@gm...
> > <mailto:rob...@gm...>> wrote:
> >
> >     Hi Peter,
> >
> >     I changed and commiter orm.xml. I will be looking at the
> >     interceptor stuff next. I will keep you posted.
> >
> >     Regards,
> >     Roberto
> >
> >
> >     On 10/23/07, * Peter Salomonsen* <co...@pe...
> >     <mailto:co...@pe...>> wrote:
> >
> >         Hi Robert,
> >
> >         I've attached a metaloginterceptors property file example.
> >         This is a feature me and Jon has been working on, and the
> >         purpose is to be able to intercept calls within the
> >         lmappletserver-addons ejb3 session beans using default EJB3
> >         interceptors.
> >
> >         I wasn't aware that it was a requirement to have this file, so
> >         this is a bug, the intention is that this file is not
> >         required, but an option if you need to create an interceptor
> >         for some reason. And it really shouldn't be called
> >         metaloginterceptor, as it is really intercepting everything -
> >         this naming is related to our specific use case - we should
> >         change this however to a more generic name (maybe just
> >         interceptor).
> >
> >         To tell you about our use case - we use interceptors to
> >         perform a parallell query on searchLogEntries (historic
> >         searches). We have a MetaDataLogEntry table with more than a
> >         billion of records, and the standard query produced by
> >         searchLogEntries is not able to handle this. The strategy is
> >         then to intercept the call, and duplicate it to run in
> >         multiple processes / servers on smaller dataset partitions,
> >         and collect the resultsets when sufficient amount of threads
> >         has returned. Then we also gain our desired speed (which is
> >         instant results).
> >
> >         About table names - since the case problem is TopLink
> >         specific, could we rather solve this using an orm.xml for the
> >         unit tests? Instead of using the Table annotation?
> >
> >         regards,
> >
> >         Peter
> >
> >
> >         On 10/21/07, *Roberto MIlev* <rob...@gm...
> >         <mailto:rob...@gm...>> wrote:
> >
> >             Hi Peter,
> >
> >             You will find the changes you requested committed to SVN.
> >             A few notes:
> >
> >             - I was only abe to test the shownColumns changes with
> >             dummy hardcoded
> >             data, beacuse I am getting errors due to missing resource -
> >             lmappletserver_metaloginterceptors. I am not able to find
> >             this resource
> >             in the project. Perhaps you can shed some light on this?
> >             - In the mean time I also resolved the issue with the junt
> >             tests
> >             failing. The thing was that the Toplink JPA always creates
> >             the tables
> >             based on the name of the Entity in uppercase. This was not
> >             visible until
> >             i install everything on Linux. the solution is to always
> >             specify the
> >             name attribute in the @Table annotation.
> >
> >             Regards,
> >             Roberto
> >
> >             Peter Salomonsen wrote:
> >             > Hi,
> >             >
> >             > I was just going to update my metadata table by adding a
> >             new metadata
> >             > (new column). I found that the searchdto has a
> >             showcolumns boolean
> >             > array, and this causes the requirement that the metadata
> >             cannot change
> >             > order or change in size. What happened in my case was that
> >             > listmetadata returned more columns than the showcolumns
> >             array, and
> >             > this caused an ArrayIndexOutOfBounds exception in
> >             > MetaDataSearchExecutor.java on the showcolumns array.
> >             >
> >             > I think this has to be solved differently. The
> >             showcolumns array
> >             > should rather be a list of metadata_ids rather than
> >             booleans - so that
> >             > it is not dependent on me not changing the metadata order
> >             or number of
> >             > metadatas.
> >             >
> >             > Can you fix this?
> >             >
> >             > regards,
> >             >
> >             > Peter
> >
> >
> >
> >
> >
> >
> >     --
> >     Regards,
> >     Roberto Milev
> >
> >
>
>

[Lmappletserver-developers] My SearchDTO and GetterSetter

[Peter S. <co...@pe...>]

Hi Roberto,

Here's how I've implemented my searchDTO and GetterSetter.

@ReportSearcher(XeptoMetaDataSearchExecutor.class)
public class XeptoMetaDataSearchDTO extends MetaDataSearchDTO {
    private static final long serialVersionUID = 1L;

    int userId = 0;

    public XeptoMetaDataSearchDTO(MetaDataSearchDTO searchData) {
        this.setColumnSorted(searchData.getColumnSorted());
        this.setColumnWidths(searchData.getColumnWidths());
        this.setLatest(searchData.getLatest());
        this.setMeta_ids(searchData.getMeta_ids());
        this.setName(searchData.getName());
        this.setSearch_strings(searchData.getSearch_strings());
        this.setShownColumns(searchData.getShownColumns());
        this.setSortedColumnOrder(searchData.getSortedColumnOrder());
    }

    public int getUserId() {
        return userId;
    }

    public void setUserId(int userId) {
        this.userId = userId;
    }



}


------------------------------------------

public class XeptoMetaDataLogGetterSetter extends MetaDataLogGetterSetter
        implements SearchDataGetterSetter {

    public XeptoMetaDataLogGetterSetter(MetaDataLogViewer metadata) {
        super(metadata);
    }

    @Override
    public AbstractSearchDTO getSearchData() {
        return new
XeptoMetaDataSearchDTO((MetaDataSearchDTO)super.getSearchData());
    }

}

See? the getSearchData() method of the GetterSetter needs to convert the
searchDTO into my custom searchDTO...

I don't know if this was your original intention of a use case - but my
reason for doing it this way, is that I want to link each search to a
specific user (hence the userId property)... And then on the server I use an
ExternalEntityFilter (com.lightminds.appletserver.metalog) to apply the
entity filtering logic based on the user id that owns the search. (By having
the userid the server can "log in" as the specified user and the scheduled
report will only find entities that the user can access...)


regards,

Peter

Re: [Lmappletserver-developers] MetaDataSearchDTO

[Peter S. <co...@pe...>]

Hi Roberto,

Thanks for the explanation - I implemented a new SearchDataGetterSetter
extending the MetaDataLogGetterSetter - since I still need the
MetaDataLogViewer.extractSearchTextsFieldsAndColumnsFromSearchPanels()
method to be called (which is done by the saveSearch() method).

This means that I initially get a MetaDataSearchDTO which I'll then convert
to my own DTO.Correct me if I'm wrong, but it seems to me that I cannot
avoid this conversion from MetaDataSearchDTO to MyCustomSearchDTO - since
I'm dependent on what the MetaDataLogViewer.saveSearch() method does. ??

Would it be more correct if the saveSearch method took a SearchDTO object as
an argument, rather than creating a new instance inside the method?

regards,

Peter



On 9/25/07, Roberto Milev <rob...@gm...> wrote:
>
> Hi Peter,
>
> I agree, this is done intentionally, MetaDataSearchDTO extends
> AbstractSearchDTO. This saveSearch method that you're referring to is used
> to gather information from the panel and put it in an AbstractSearchDTO,
> than we get that object and store it in database. I might have named the
> method badly (if you think so, I can correct it immediately), but the idea
> is for this method to be unique for each applet. So you need to make another
> method like this to gather different kind of information for your custom
> searchDTO which will extend AbstractSearchDTO. Than another class to
> implement the SearchDataGetterSetter and that class name to set in the menu
> creation as it is in MetaDataLogViewerApplet.
>
> Regards,
> Roberto
>
> On 9/25/07, Peter Salomonsen <co...@pe...> wrote:
> >
> > Hi Roberto,
> >
> > Remember the Custom SearchDTO tutorial? I've tried this, and I'm using a
> > custom SearchDTO, but this will never work because of this:
> >
> >     /**
> >      * Saves the search in database
> >      *
> >      * @param searchName
> >      *            name that the search will be stored in database
> >      */
> >     public MetaDataSearchDTO saveSearch() {
> >         // This has been changed in order to work with the search_addon
> > concept
> >         extractSearchTextsFieldsAndColumnsFromSearchPanels();
> >         MetaDataSearchDTO search = new MetaDataSearchDTO();
> >         search.setMeta_ids(searchFieldArray);
> >         search.setSearch_strings(searchTextArray);
> >         search.setShownColumns(shownColumns);
> >         return search;
> >         // mdr.saveSearch(searchName, searchFieldArray, searchTextArray,
> >         // shownColumns);
> >     }
> >
> > which is from MetaDataLogViewer.
> >
> >
> > Reason is that this always return a MetaDataSearchDTO, while it should
> > return an instance of my custom searchDTO..
> >
> > This is top prio for me, you have a solution proposal?
> >
> > regards,
> >
> > Peter
> >
>
>
>
> --
> Regards,
> Roberto Milev

[Lmappletserver-developers] MetaDataSearchDTO

[Peter S. <co...@pe...>]

Hi Roberto,

Remember the Custom SearchDTO tutorial? I've tried this, and I'm using a
custom SearchDTO, but this will never work because of this:

    /**
     * Saves the search in database
     *
     * @param searchName
     *            name that the search will be stored in database
     */
    public MetaDataSearchDTO saveSearch() {
        // This has been changed in order to work with the search_addon
concept
        extractSearchTextsFieldsAndColumnsFromSearchPanels();
        MetaDataSearchDTO search = new MetaDataSearchDTO();
        search.setMeta_ids(searchFieldArray);
        search.setSearch_strings(searchTextArray);
        search.setShownColumns(shownColumns);
        return search;
        // mdr.saveSearch(searchName, searchFieldArray, searchTextArray,
        // shownColumns);
    }

which is from MetaDataLogViewer.


Reason is that this always return a MetaDataSearchDTO, while it should
return an instance of my custom searchDTO..

This is top prio for me, you have a solution proposal?

regards,

Peter

Re: [Lmappletserver-developers] Junit task breakdown

[Roberto M. <rob...@gm...>]

Hi Peter,

The API consistency test are submitted to SVN. The test check for the 
existence of API methods without executing them. These are the submitted 
classes:

/lmappletserver_addons/src_tests/com/lightminds/appletserver/gui/entity/EntityListAPITest.java           
/lmappletserver_addons/src_tests/com/lightminds/appletserver/gui/metadata/MetaDataAPITest.java 

/lmappletserver_addons/src_tests/com/lightminds/report/ReportAPITest.java
/lmappletserver_addons/src_tests/com/lightminds/search/SearchAPITest.java

Regards,
Roberto

Peter Salomonsen wrote:
> Hi Roberto,
>
> That sounds like a good start. Would you use the src_tests folder and 
> create some example tests so that we can discuss further from there?
>
> I've moved the cvs modules lmappletserver-core and 
> lmappletserver-addons (metalog) to svn.
>
> I've also committed a delete of the contents of these two cvs modules 
> and also the lmappletserver cvs module (the one you reorganized long ago).
>
> regards,
>
> Peter
>
>
> On 9/20/07, *Roberto Milev* < rob...@gm... 
> <mailto:rob...@gm...>> wrote:
>
>     Hi Peter,
>
>     Please find bellow my initial list of unit tests for
>     lmappletserver. Please give me your feedback.
>
>     -- 
>     Regards,
>     Roberto Milev
>     ---------------------------------------------------
>
>      
>     - input of data into the metalog
>
>     Here we can test the MetaDataManager methods:
>
>         * addLogEntry 
>
>     - search in the data (should verify that input data is searchable
>     as expected)
>
>     Here we can test the MetaDataManager methods:
>
>         * searchEntries
>
>      
>     - Alert reports
>
>     Here we can test the SearchManager methods:
>
>         * getAllSearchNamesByClass
>         * saveSearchWithAlert (call addLogEntry to trigger the alert)
>         * openSearch
>
>      
>     - Scheduled reports
>
>     Here we can test the ReportManager methods: 
>
>         * openScheduledReport 
>         * saveScheduledReport
>         * getAllScheduledReportNames
>         * getAllScheduledTasks
>         * deleteScheduledReport 
>
>      
>
>     - API consistency
>
>     Here we can test all Managers methods 
>
>         * SearchManager (All methods)
>         * ReportManager (All methods)
>         * MetaDataManager (All methods)
>         * EntityListManager (All methods)
>
>
>

Re: [Lmappletserver-developers] Junit task breakdown

[Peter S. <co...@pe...>]

Hi Roberto,

I've moved lmappletserver_build and lmappletserver-addons-full-example to
svn.

regards,

Peter

On 9/20/07, Roberto Milev <rob...@gm...> wrote:
>
> Hi Peter,
>
> Yes I will be putting the tests to src_test, and we can take a look at
> things form there.
>
> About the cvs modules. The lmappletserver_buid is used to build the final
> ear form the core and addons, also there is the fill-example project module
> which I believe should also be moved.
>
> Regards,
> Roberto
>
> On 9/20/07, Peter Salomonsen <co...@pe...> wrote:
> >
> > Hi Roberto,
> >
> > That sounds like a good start. Would you use the src_tests folder and
> > create some example tests so that we can discuss further from there?
> >
> > I've moved the cvs modules lmappletserver-core and lmappletserver-addons
> > (metalog) to svn.
> >
> > I've also committed a delete of the contents of these two cvs modules
> > and also the lmappletserver cvs module (the one you reorganized long ago).
> >
> > regards,
> >
> > Peter
> >
> >
> > On 9/20/07, Roberto Milev < rob...@gm...> wrote:
> > >
> > > Hi Peter,
> > >
> > > Please find bellow my initial list of unit tests for lmappletserver.
> > > Please give me your feedback.
> > >
> > > --
> > > Regards,
> > > Roberto Milev
> > > ---------------------------------------------------
> > >
> > >
> > > - input of data into the metalog
> > >
> > > Here we can test the MetaDataManager methods:
> > >
> > >    - addLogEntry
> > >
> > > - search in the data (should verify that input data is searchable as
> > > expected)
> > >
> > > Here we can test the MetaDataManager methods:
> > >
> > >    - searchEntries
> > >
> > >
> > > - Alert reports
> > >
> > > Here we can test the SearchManager methods:
> > >
> > >    - getAllSearchNamesByClass
> > >    - saveSearchWithAlert (call addLogEntry to trigger the alert)
> > >    - openSearch
> > >
> > >
> > > - Scheduled reports
> > >
> > > Here we can test the ReportManager methods:
> > >
> > >    - openScheduledReport
> > >    - saveScheduledReport
> > >    - getAllScheduledReportNames
> > >    - getAllScheduledTasks
> > >    - deleteScheduledReport
> > >
> > >
> > >
> > > - API consistency
> > >
> > > Here we can test all Managers methods
> > >
> > >    - SearchManager (All methods)
> > >    - ReportManager (All methods)
> > >    - MetaDataManager (All methods)
> > >    - EntityListManager (All methods)
> > >
> > >
> > >
> >
>
>
> --
> Regards,
> Roberto Milev

Re: [Lmappletserver-developers] Junit task breakdown

[Peter S. <co...@pe...>]

Hi Roberto,

That sounds like a good start. Would you use the src_tests folder and create
some example tests so that we can discuss further from there?

I've moved the cvs modules lmappletserver-core and lmappletserver-addons
(metalog) to svn.

I've also committed a delete of the contents of these two cvs modules and
also the lmappletserver cvs module (the one you reorganized long ago).

regards,

Peter


On 9/20/07, Roberto Milev < rob...@gm...> wrote:
>
> Hi Peter,
>
> Please find bellow my initial list of unit tests for lmappletserver.
> Please give me your feedback.
>
> --
> Regards,
> Roberto Milev
> ---------------------------------------------------
>
>
> - input of data into the metalog
>
> Here we can test the MetaDataManager methods:
>
>    - addLogEntry
>
> - search in the data (should verify that input data is searchable as
> expected)
>
> Here we can test the MetaDataManager methods:
>
>    - searchEntries
>
>
> - Alert reports
>
> Here we can test the SearchManager methods:
>
>    - getAllSearchNamesByClass
>    - saveSearchWithAlert (call addLogEntry to trigger the alert)
>    - openSearch
>
>
> - Scheduled reports
>
> Here we can test the ReportManager methods:
>
>    - openScheduledReport
>    - saveScheduledReport
>    - getAllScheduledReportNames
>    - getAllScheduledTasks
>    - deleteScheduledReport
>
>
>
> - API consistency
>
> Here we can test all Managers methods
>
>    - SearchManager (All methods)
>    - ReportManager (All methods)
>    - MetaDataManager (All methods)
>    - EntityListManager (All methods)
>
>
>

[Lmappletserver-developers] Subversion migration failed

[Peter S. <co...@pe...>]

I'll consider just committing cvs HEAD to subversion. Please tell me if you
commit anything to cvs.

cheers,

Peter

[Lmappletserver-developers] Subversion migration in progress

[Peter S. <co...@pe...>]

I'm converting to subversion, please don't commit any more to the cvs
repository..

The conversion progress is eta by 24 hours from now.

regards,

Peter

[Lmappletserver-developers] Fwd: Dynamic bean and special characters

[Peter S. <co...@pe...>]

Hi Roberto,

Read inline comments.

On 7/20/07, Roberto Milev <rob...@gm...> wrote:
>
> Hi Peter,
>
> Read comments inline.
>
> On 7/20/07, Peter Salomonsen <co...@pe...> wrote:
> >
> > Hi Roberto,
> >
> > The XML servlet is great, and it's much better to use in iReport. Did
> > you
> > manage to use the remote xml datasource? (I had some problems with it..)
> > This
> > would be even better.
>
>
> I did  not consider a remote xml datasource. Does this refer to loading
> form URL?
>

Yes it's an iReport feature.. You can specify  an xml datasource from a url.

One downside with the xml datasource, is that the Report Wizard won't accept
> >
> > it. Is there a way around this? Suggestions?
>
>
> Do you mean the report wizart inside the metalog applet? If yes, then this
> is covered because xml datasources correspond to saved searches.
>

No,  the report wizard in  iReport. Somehow it doesn't seem to  support xml
datasources.  No big deal though.

About this:
> >
> > http://localhost:8080/lmas-addons-example/reportservlet?reportName=Report_1
> >
> >
> > It does always delete my report - and I know it's because of the "Print
> > current report" function - but could we make it possible get an
> > on-demand pdf
> > without deleting?
> >
> > Further - in addition to pdf - could we also get an Excel doc - just
> > like when
> > using the excel preview function in iReport?
> >
> > Maybe introduce some switches? :
> >
> > http://localhost:8080/lmas-addons-example/reportservlet?reportName=Report_1&type=excel&delete=false
> >
> > (other types pdf, and the print current report could use delete=true)
>
>
> yes the type and delete switches sound ok.
>
> And - regarding xsl transformation (to google kml's and other htmls) - any
> > suggestions on how to solve this? Should we introduce xsl template
> > uploading?
> > We can use the reportservlet for also viewing xsl reports, the servlet
> > will
> > figure out if the template used is xsl?
>
>
>  I suggest we expand the report template table and add fields for content
> type and file extension. For content type we would support: pdf, excel, xml
> (xml would be used for xsl templates, and the file extension could be html,
> klm, etc.). the xsl templates could be loaded in the same manner,
> additionally the file extension should be specified on the upload page. I
> see the foolwing possibilities for using the URL switches:
>
> -reportName
>     - type: pdf, excel, xml
>     - delete: true, false
>
> -searchName
>     - type: excel, xml
>     - template: (any saved template in the db)
>     - delete: true, false
>
> What do you think?
>

Sounds ok to me.

cheers,

Peter

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Peter S. <co...@pe...>]

Hi Roberto,

The XML servlet is great, and it's much better to use in iReport. Did you 
manage to use the remote xml datasource? (I had some problems with it..) This 
would be even better.

One downside with the xml datasource, is that the Report Wizard won't accept 
it. Is there a way around this? Suggestions?

About this:

http://localhost:8080/lmas-addons-example/reportservlet?reportName=Report_1

It does always delete my report - and I know it's because of the "Print 
current report" function - but could we make it possible get an on-demand pdf 
without deleting?

Further - in addition to pdf - could we also get an Excel doc - just like when 
using the excel preview function in iReport?

Maybe introduce some switches? :

http://localhost:8080/lmas-addons-example/reportservlet?reportName=Report_1&type=excel&delete=false
(other types pdf, and the print current report could use delete=true)

And - regarding xsl transformation (to google kml's and other htmls) - any 
suggestions on how to solve this? Should we introduce xsl template uploading? 
We can use the reportservlet for also viewing xsl reports, the servlet will 
figure out if the template used is xsl?

regards,

Peter


On Friday 20 July 2007 08:01:29 you wrote:
> He Peter,
>
> I have committed the functionality to retrieve searches in XML. I
> modified the existing report servlet to handle this. So now if you
> navigate to:
>
> http://localhost:8080/lmas-addons-example/reportservlet?searchName=Search_1
>
> you will get an XML representation of the search result (see
> attachment). I also removed the dynamic bean creation stuff an modified
> the pdf creation to use this XML as a data source. This makes authoring
> jasper templates in iReport even easier. You should use the actual XML
> file and setup a datasource. In the query window select XPath, and use
> "/searchResults/row" as the search expression. Form the XPath selection
> drag and drop to define your fields. I also updated the sample jasper
> templates in the full example project.
>
> The PDF functionality is still there and you can get a PDF of a report
> if you navigate to (this URL is also used form the meta data applet):
> http://localhost:8080/lmas-addons-example/reportservlet?reportName=Report_1
>
> Please have a look and send me your comments.
>
> Regards,
> Roberto
>
> Peter Salomonsen wrote:
> > On Monday 16 July 2007 06:55:16 you wrote:
> >> I have started working on implementing the feature. I have created a new
> >> servlet - XmlReportServelet. My idea is to be able to use the reporting
> >> template mechanism that we have, but load report templates in XSLT
> >> format. The results of a saved search would be represented in a fixed
> >> defined XML format, for e.g.:
> >>
> >>   <searchResults latest="true">
> >>     <row>
> >>       <column name="id" >1</column>
> >>       <column name="airportName" >JFK</column>
> >>       <column name="latitude" >- 44.98</column>
> >>       <column name="longitude" >15.63</column>
> >>       <column name="altitude" >128</column>
> >>       <column name="windSpeed" >43</column>
> >>     </row>
> >>     <row>
> >>       <column name="id" >2</column>
> >>       <column name="airportName" >JFK</column>
> >>       <column name="latitude" >- 44.98</column>
> >>       <column name="longitude" >15.63</column>
> >>       <column name="altitude" >128</column>
> >>       <column name="windSpeed" >43</column>
> >>     </row>
> >>   </searchResults>
> >
> > This is a very good idea. Is this format compatible with the XML data
> > source that you have in iReport? Eventually could you change it so that
> > it would be compatible?
> >
> >> The new servlet would apply the XSL transformation to this XML and
> >> return the result. It would receive the the template and search names
> >> (unique IDs) as URL params for e.g.:
> >> /xmlReport/Position.klm?template=Placemark&search=Vehicle1
> >
> > XSL transformation is a good way of providing the kml. Actually I don't
> > think you should implement this part then. Providing the xml is enough,
> > and let external applications apply xsl templates for now. I think just
> > providing the stored search as xml is sufficient for now - and we'll make
> > the decision about also storing xml templates later.
> >
> >> This would ultimately allow us to have URLs that generate HTML reports,
> >> RSS feeds etc.
> >
> > That is exactly what we want.
> >
> > Since we're now going for XMLDatasources would this eliminate the need
> > for the DynamicBean? I see a problem with this regarding datatypes. The
> > DynamicBean makes everything as strings, and this is e.g. a problem when
> > sorting numbers in the report.
> >
> > With the xml datasource we wouldn't any longer have to use the csv for
> > designing templates in iReport - right?
> >
> > Another thing - iReport has a possibility of viewing the report as Excel
> > - could we use the same mechanism to send an excel file rather than pdf?
> >
> > regards,
> >
> > Peter

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Roberto M. <rob...@gm...>]

He Peter,

I have committed the functionality to retrieve searches in XML. I 
modified the existing report servlet to handle this. So now if you 
navigate to:

http://localhost:8080/lmas-addons-example/reportservlet?searchName=Search_1

you will get an XML representation of the search result (see 
attachment). I also removed the dynamic bean creation stuff an modified 
the pdf creation to use this XML as a data source. This makes authoring 
jasper templates in iReport even easier. You should use the actual XML 
file and setup a datasource. In the query window select XPath, and use 
"/searchResults/row" as the search expression. Form the XPath selection 
drag and drop to define your fields. I also updated the sample jasper 
templates in the full example project.

The PDF functionality is still there and you can get a PDF of a report 
if you navigate to (this URL is also used form the meta data applet):
http://localhost:8080/lmas-addons-example/reportservlet?reportName=Report_1

Please have a look and send me your comments.

Regards,
Roberto

Peter Salomonsen wrote:
> On Monday 16 July 2007 06:55:16 you wrote:
>   
>> I have started working on implementing the feature. I have created a new
>> servlet - XmlReportServelet. My idea is to be able to use the reporting
>> template mechanism that we have, but load report templates in XSLT
>> format. The results of a saved search would be represented in a fixed
>> defined XML format, for e.g.:
>>
>>   <searchResults latest="true">
>>     <row>
>>       <column name="id" >1</column>
>>       <column name="airportName" >JFK</column>
>>       <column name="latitude" >- 44.98</column>
>>       <column name="longitude" >15.63</column>
>>       <column name="altitude" >128</column>
>>       <column name="windSpeed" >43</column>
>>     </row>
>>     <row>
>>       <column name="id" >2</column>
>>       <column name="airportName" >JFK</column>
>>       <column name="latitude" >- 44.98</column>
>>       <column name="longitude" >15.63</column>
>>       <column name="altitude" >128</column>
>>       <column name="windSpeed" >43</column>
>>     </row>
>>   </searchResults>
>>     
>
> This is a very good idea. Is this format compatible with the XML data source 
> that you have in iReport? Eventually could you change it so that it would be 
> compatible?
>
>   
>> The new servlet would apply the XSL transformation to this XML and
>> return the result. It would receive the the template and search names
>> (unique IDs) as URL params for e.g.:
>> /xmlReport/Position.klm?template=Placemark&search=Vehicle1
>>     
>
> XSL transformation is a good way of providing the kml. Actually I don't think 
> you should implement this part then. Providing the xml is enough, and let 
> external applications apply xsl templates for now. I think just providing the 
> stored search as xml is sufficient for now - and we'll make the decision 
> about also storing xml templates later.
>
>   
>> This would ultimately allow us to have URLs that generate HTML reports,
>> RSS feeds etc.
>>     
>
> That is exactly what we want.
>
> Since we're now going for XMLDatasources would this eliminate the need for the 
> DynamicBean? I see a problem with this regarding datatypes. The DynamicBean 
> makes everything as strings, and this is e.g. a problem when sorting numbers 
> in the report.
>
> With the xml datasource we wouldn't any longer have to use the csv for 
> designing templates in iReport - right?
>
> Another thing - iReport has a possibility of viewing the report as Excel - 
> could we use the same mechanism to send an excel file rather than pdf?
>
> regards,
>
> Peter
>
>
>   

[Lmappletserver-developers] Metalog search optimizations

[Peter S. <co...@pe...>]

Hi,

I've done some significant search optimizations on the metalog 
(MetaDataManagerBean.getLogEntries)

- (PJS) Optimization - Automatically skip meta_ids which searchstrings are 
empty
- (PJS) Optimization - Add external entity join criteria to all joined 
MetaDataLogEntry tables
- (PJS) Optimization - Don't add an extra join if meta_id is already present

In effect it writes the sql queries better, and saves a lot of stress on the 
database..

cheers,

Peter

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Roberto M. <rob...@gm...>]

Hi Peter,

I have started working on implementing the feature. I have created a new 
servlet - XmlReportServelet. My idea is to be able to use the reporting 
template mechanism that we have, but load report templates in XSLT 
format. The results of a saved search would be represented in a fixed 
defined XML format, for e.g.:

  <searchResults latest="true">
    <row>
      <column name="id" >1</column>
      <column name="airportName" >JFK</column>
      <column name="latitude" >- 44.98</column>
      <column name="longitude" >15.63</column>
      <column name="altitude" >128</column>
      <column name="windSpeed" >43</column>
    </row>
    <row>
      <column name="id" >2</column>
      <column name="airportName" >JFK</column>
      <column name="latitude" >- 44.98</column>
      <column name="longitude" >15.63</column>
      <column name="altitude" >128</column>
      <column name="windSpeed" >43</column>
    </row>
  </searchResults>

The new servlet would apply the XSL transformation to this XML and 
return the result. It would receive the the template and search names 
(unique IDs) as URL params for e.g.: 
/xmlReport/Position.klm?template=Placemark&search=Vehicle1

This would ultimately allow us to have URLs that generate HTML reports, 
RSS feeds etc.

If this approach is OK I believe i will be able to deliver the full 
implementation by the end of this week.

Regards,
Roberto

Peter Salomonsen wrote:
> Hi Roberto,
>
> Your question whether we should use region or placemark, makes me think we 
> should generalize this even more. Cause we really want to be able to use 
> everything. The objects might be fixed, but also moving - so the kml must be 
> customizable.
>
> So my question is:
>
> - Would it be possible to create a report template that produces xml (which in 
> this case will be kml)?
> - The kml url mention earlier, will then instead of being kml specific, be 
> mapped to a report - so that you can get a report (with any template) on the 
> fly just using a url. How would this be?
>
> regards,
>
> Peter
>
> On Tuesday 10 July 2007 16:58:18 you wrote:
>   
>> Hi Peter,
>>
>> Yes,  I started looking into the google-map integration.
>>
>> The approach to this task would be to create e a servlet with *.kml
>> mapping. The request with
>> http://lmappletserver.lightminds.com/lmas-addons-example/
>> kml/mysearch.kml<http://lmappletserver.lightminds.com/lmas-addons-example/k
>> ml/mysearch.kml>, that mysearch will be the saved search name, this I think
>> is the best because the Saved search name is unique, and can be used as
>> identifier. When the servlet is called and executes the saved search a
>> transformer class will create the mysearch.kml content string from the
>> result of the search. Then this string will be sent to the client as output
>> stream. At this moment I look at two approaches, and I would like for you
>> to tell which one to use, first one is to use the Placemark tag to create a
>> yellow pin(in Google Earth), and lead the user to that spot. This is done
>> by kml like this:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <kml xmlns="http://earth.google.com/kml/2.1">
>> <Placemark>
>>   <name>Macky Auditorium</name>
>>   <description>University of Colorado.</description>
>>   <LookAt>
>>     <longitude>-105.2727379358738</longitude>
>>     <latitude>40.01000594412381</latitude>
>>     <altitude>0</altitude>
>>     <range>127.2393107680517</range>
>>     <tilt>65.74454495876547</tilt>
>>     <heading>-27.70337734057933</heading>
>>   </LookAt>
>> </Placemark>
>> </kml>
>>
>> Or we can use the Region tag, and show regions of the airport, and be
>> visible only when the user reaches certain zooming resolution. This is done
>> by kml like this:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <kml xmlns="http://earth.google.com/kml/2.1">
>> <Document>
>>   <name>romania Document</name>
>>     <Region>
>>       <LatLonAltBox>
>>         <north>50.625</north>
>>         <south>45</south>
>>         <east>28.125</east>
>>         <west>22.5</west>
>>       </LatLonAltBox>
>>       <Lod>
>>         <minLodPixels>128</minLodPixels>
>>         <maxLodPixels>1024</maxLodPixels>
>>       </Lod>
>>     </Region>
>> </Document>
>> </kml>
>>
>> Here because of the fact that in the current database we have only
>> latitude, longitude and altitude we have to make coordinate transformation,
>> therefore I think that this approach is not appropriate for our
>> application.
>>
>> Regards,
>> Roberto
>>
>> On 7/9/07, Peter Salomonsen <co...@pe...> wrote:
>>     
>>> Hi,
>>>
>>> This and the checkbox scrollbar looks good as far as I can see..
>>>
>>> Have you looked into the google-map (kml) integration?
>>>
>>> regards,
>>>
>>> Peter
>>>
>>> On Sunday 08 July 2007 17:59:30 you wrote:
>>>       
>>>> Hi Peter,
>>>>
>>>> The change to display the metadatacolumn name is no key exists in
>>>> property file is commited. Additionally I did anothetr small change to
>>>> display the localized strings in the search combo box.
>>>>
>>>> Regards,
>>>> Roberto
>>>>
>>>> Peter Salomonsen wrote:
>>>>         
>>>>> Hi Roberto,
>>>>>
>>>>> The new MetaDataColumnNames.properties file works just perfect. Could
>>>>>           
>>> we
>>>
>>>       
>>>>> also extend it so that if a key doesn't exist, the metadatacolumn
>>>>> name
>>>>>           
>>> is
>>>
>>>       
>>>>> showed directly?
>>>>>
>>>>> regards,
>>>>>
>>>>> Peter
>>>>>           
>
>
>
>   

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Peter S. <co...@pe...>]

This is not neccesary in the lmappletserver_addons libraries. This should b=
e=20
handled by each implementing application.

The lmappletserver_addons urls should be completely open by default.

regards,

Peter

On Wednesday 11 July 2007 13:02:11 Jon =C3=85kerstr=C3=B6m wrote:
> Also I'm curious how will the kml be secured? Have you looked into that?
> How do we avoid users that are not allowed to view the units in the .kml
> gets access to them simply by knowint the url?
>
> Best regards
> Jonte
>
> On Wed, 2007-07-11 at 12:49 +0200, Peter Salomonsen wrote:
> > Hi Roberto,
> >
> > Your question whether we should use region or placemark, makes me think
> > we should generalize this even more. Cause we really want to be able to
> > use everything. The objects might be fixed, but also moving - so the kml
> > must be customizable.
> >
> > So my question is:
> >
> > - Would it be possible to create a report template that produces xml
> > (which in this case will be kml)?
> > - The kml url mention earlier, will then instead of being kml specific,
> > be mapped to a report - so that you can get a report (with any template)
> > on the fly just using a url. How would this be?
> >
> > regards,
> >
> > Peter
> >
> > On Tuesday 10 July 2007 16:58:18 you wrote:
> > > Hi Peter,
> > >
> > > Yes,  I started looking into the google-map integration.
> > >
> > > The approach to this task would be to create e a servlet with *.kml
> > > mapping. The request with
> > > http://lmappletserver.lightminds.com/lmas-addons-example/
> > > kml/mysearch.kml<http://lmappletserver.lightminds.com/lmas-addons-exa=
mp
> > >le/k ml/mysearch.kml>, that mysearch will be the saved search name, th=
is
> > > I think is the best because the Saved search name is unique, and can =
be
> > > used as identifier. When the servlet is called and executes the saved
> > > search a transformer class will create the mysearch.kml content string
> > > from the result of the search. Then this string will be sent to the
> > > client as output stream. At this moment I look at two approaches, and=
 I
> > > would like for you to tell which one to use, first one is to use the
> > > Placemark tag to create a yellow pin(in Google Earth), and lead the
> > > user to that spot. This is done by kml like this:
> > >
> > > <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> > > <kml xmlns=3D"http://earth.google.com/kml/2.1">
> > > <Placemark>
> > >   <name>Macky Auditorium</name>
> > >   <description>University of Colorado.</description>
> > >   <LookAt>
> > >     <longitude>-105.2727379358738</longitude>
> > >     <latitude>40.01000594412381</latitude>
> > >     <altitude>0</altitude>
> > >     <range>127.2393107680517</range>
> > >     <tilt>65.74454495876547</tilt>
> > >     <heading>-27.70337734057933</heading>
> > >   </LookAt>
> > > </Placemark>
> > > </kml>
> > >
> > > Or we can use the Region tag, and show regions of the airport, and be
> > > visible only when the user reaches certain zooming resolution. This is
> > > done by kml like this:
> > >
> > > <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> > > <kml xmlns=3D"http://earth.google.com/kml/2.1">
> > > <Document>
> > >   <name>romania Document</name>
> > >     <Region>
> > >       <LatLonAltBox>
> > >         <north>50.625</north>
> > >         <south>45</south>
> > >         <east>28.125</east>
> > >         <west>22.5</west>
> > >       </LatLonAltBox>
> > >       <Lod>
> > >         <minLodPixels>128</minLodPixels>
> > >         <maxLodPixels>1024</maxLodPixels>
> > >       </Lod>
> > >     </Region>
> > > </Document>
> > > </kml>
> > >
> > > Here because of the fact that in the current database we have only
> > > latitude, longitude and altitude we have to make coordinate
> > > transformation, therefore I think that this approach is not appropria=
te
> > > for our application.
> > >
> > > Regards,
> > > Roberto
> > >
> > > On 7/9/07, Peter Salomonsen <co...@pe...> wrote:
> > > > Hi,
> > > >
> > > > This and the checkbox scrollbar looks good as far as I can see..
> > > >
> > > > Have you looked into the google-map (kml) integration?
> > > >
> > > > regards,
> > > >
> > > > Peter
> > > >
> > > > On Sunday 08 July 2007 17:59:30 you wrote:
> > > > > Hi Peter,
> > > > >
> > > > > The change to display the metadatacolumn name is no key exists in
> > > > > property file is commited. Additionally I did anothetr small chan=
ge
> > > > > to display the localized strings in the search combo box.
> > > > >
> > > > > Regards,
> > > > > Roberto
> > > > >
> > > > > Peter Salomonsen wrote:
> > > > > > Hi Roberto,
> > > > > >
> > > > > > The new MetaDataColumnNames.properties file works just perfect.
> > > > > > Could
> > > >
> > > > we
> > > >
> > > > > > also extend it so that if a key doesn't exist, the metadatacolu=
mn
> > > > > > name
> > > >
> > > > is
> > > >
> > > > > > showed directly?
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Peter
> >
> > -----------------------------------------------------------------------=
=2D-
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Lmappletserver-developers mailing list
> > Lma...@li...
> > https://lists.sourceforge.net/lists/listinfo/lmappletserver-developers

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Peter S. <co...@pe...>]

Hi Roberto,

Your question whether we should use region or placemark, makes me think we 
should generalize this even more. Cause we really want to be able to use 
everything. The objects might be fixed, but also moving - so the kml must be 
customizable.

So my question is:

- Would it be possible to create a report template that produces xml (which in 
this case will be kml)?
- The kml url mention earlier, will then instead of being kml specific, be 
mapped to a report - so that you can get a report (with any template) on the 
fly just using a url. How would this be?

regards,

Peter

On Tuesday 10 July 2007 16:58:18 you wrote:
> Hi Peter,
>
> Yes,  I started looking into the google-map integration.
>
> The approach to this task would be to create e a servlet with *.kml
> mapping. The request with
> http://lmappletserver.lightminds.com/lmas-addons-example/
> kml/mysearch.kml<http://lmappletserver.lightminds.com/lmas-addons-example/k
>ml/mysearch.kml>, that mysearch will be the saved search name, this I think
> is the best because the Saved search name is unique, and can be used as
> identifier. When the servlet is called and executes the saved search a
> transformer class will create the mysearch.kml content string from the
> result of the search. Then this string will be sent to the client as output
> stream. At this moment I look at two approaches, and I would like for you
> to tell which one to use, first one is to use the Placemark tag to create a
> yellow pin(in Google Earth), and lead the user to that spot. This is done
> by kml like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <kml xmlns="http://earth.google.com/kml/2.1">
> <Placemark>
>   <name>Macky Auditorium</name>
>   <description>University of Colorado.</description>
>   <LookAt>
>     <longitude>-105.2727379358738</longitude>
>     <latitude>40.01000594412381</latitude>
>     <altitude>0</altitude>
>     <range>127.2393107680517</range>
>     <tilt>65.74454495876547</tilt>
>     <heading>-27.70337734057933</heading>
>   </LookAt>
> </Placemark>
> </kml>
>
> Or we can use the Region tag, and show regions of the airport, and be
> visible only when the user reaches certain zooming resolution. This is done
> by kml like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <kml xmlns="http://earth.google.com/kml/2.1">
> <Document>
>   <name>romania Document</name>
>     <Region>
>       <LatLonAltBox>
>         <north>50.625</north>
>         <south>45</south>
>         <east>28.125</east>
>         <west>22.5</west>
>       </LatLonAltBox>
>       <Lod>
>         <minLodPixels>128</minLodPixels>
>         <maxLodPixels>1024</maxLodPixels>
>       </Lod>
>     </Region>
> </Document>
> </kml>
>
> Here because of the fact that in the current database we have only
> latitude, longitude and altitude we have to make coordinate transformation,
> therefore I think that this approach is not appropriate for our
> application.
>
> Regards,
> Roberto
>
> On 7/9/07, Peter Salomonsen <co...@pe...> wrote:
> > Hi,
> >
> > This and the checkbox scrollbar looks good as far as I can see..
> >
> > Have you looked into the google-map (kml) integration?
> >
> > regards,
> >
> > Peter
> >
> > On Sunday 08 July 2007 17:59:30 you wrote:
> > > Hi Peter,
> > >
> > > The change to display the metadatacolumn name is no key exists in
> > > property file is commited. Additionally I did anothetr small change to
> > > display the localized strings in the search combo box.
> > >
> > > Regards,
> > > Roberto
> > >
> > > Peter Salomonsen wrote:
> > > > Hi Roberto,
> > > >
> > > > The new MetaDataColumnNames.properties file works just perfect. Could
> >
> > we
> >
> > > > also extend it so that if a key doesn't exist, the metadatacolumn
> > > > name
> >
> > is
> >
> > > > showed directly?
> > > >
> > > > regards,
> > > >
> > > > Peter

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Roberto M. <rob...@gm...>]

Hi Peter,

The change to display the metadatacolumn name is no key exists in 
property file is commited. Additionally I did anothetr small change to 
display the localized strings in the search combo box.

Regards,
Roberto

Peter Salomonsen wrote:
> Hi Roberto,
>
> The new MetaDataColumnNames.properties file works just perfect. Could we also 
> extend it so that if a key doesn't exist, the metadatacolumn name is showed 
> directly?
>
> regards,
>
> Peter
>
>   

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Peter S. <co...@pe...>]

Hi Roberto,

The new MetaDataColumnNames.properties file works just perfect. Could we also 
extend it so that if a key doesn't exist, the metadatacolumn name is showed 
directly?

regards,

Peter

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Roberto M. <rob...@gm...>]

Hi Peter,

The changes for handling special characters are done and committed. 
Please have a look. Total time spent on this task 14 hours.

Regards,
Roberto

Peter Salomonsen wrote:
> Sounds good... It's a go then ..
>
> cheers,
>
> Peter
>
> On Tuesday 26 June 2007 14:45:09 Roberto MIlev wrote:
>   
>> Hi Peter,
>>
>> I agree.
>>
>> Database metadata to be created as english (no special characters)
>> names. These names will be used as keys to a property file named
>> column_names.properties. In this property file the metadata keys will be
>> mapped to values as wished (with special characters). These naming will
>> be used only for display purpose. When generating report or xls/csv the
>> database keys will be used, and if so, the class field generator will
>> have no problems.
>>
>> Regards,
>> Roberto
>>
>> Peter Salomonsen wrote:
>>     
>>> Just as a follow up. Ideally, the metadata column names should maybe
>>> serve as keys to a language property file? so that the metadata columns
>>> also could be shown in different languages. In this case one would of
>>> course require that the key names (= metadata column names) had valid
>>> characters.
>>>
>>> Take this into account when proposing a solution.
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> On Thursday 21 June 2007 15:32:05 Peter Salomonsen wrote:
>>>       
>>>> Hi,
>>>>
>>>> If we have column names that contain e.g. scandinavian characters like :
>>>> æøå , or others like ẽ é etc. there is a problem with the dynamic bean
>>>> setters and getters.
>>>>
>>>> Could you propose a solution for this?
>>>>
>>>> regards,
>>>>
>>>> Peter
>>>>
>>>> ------------------------------------------------------------------------
>>>> - This SF.net email is sponsored by DB2 Express
>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>> control of your XML. No limits. Just data. Click to get it now.
>>>> http://sourceforge.net/powerbar/db2/
>>>> _______________________________________________
>>>> Lmappletserver-developers mailing list
>>>> Lma...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lmappletserver-developers
>>>>         
>
>
>
>   

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Peter S. <co...@pe...>]

Sounds good... It's a go then ..

cheers,

Peter

On Tuesday 26 June 2007 14:45:09 Roberto MIlev wrote:
> Hi Peter,
>
> I agree.
>
> Database metadata to be created as english (no special characters)
> names. These names will be used as keys to a property file named
> column_names.properties. In this property file the metadata keys will be
> mapped to values as wished (with special characters). These naming will
> be used only for display purpose. When generating report or xls/csv the
> database keys will be used, and if so, the class field generator will
> have no problems.
>
> Regards,
> Roberto
>
> Peter Salomonsen wrote:
> > Just as a follow up. Ideally, the metadata column names should maybe
> > serve as keys to a language property file? so that the metadata columns
> > also could be shown in different languages. In this case one would of
> > course require that the key names (=3D metadata column names) had valid
> > characters.
> >
> > Take this into account when proposing a solution.
> >
> > Regards,
> >
> > Peter
> >
> > On Thursday 21 June 2007 15:32:05 Peter Salomonsen wrote:
> >> Hi,
> >>
> >> If we have column names that contain e.g. scandinavian characters like=
 :
> >> =C3=A6=C3=B8=C3=A5 , or others like =E1=BA=BD =C3=A9 etc. there is a p=
roblem with the dynamic bean
> >> setters and getters.
> >>
> >> Could you propose a solution for this?
> >>
> >> regards,
> >>
> >> Peter
> >>
> >> ----------------------------------------------------------------------=
=2D-
> >>- This SF.net email is sponsored by DB2 Express
> >> Download DB2 Express C - the FREE version of DB2 express and take
> >> control of your XML. No limits. Just data. Click to get it now.
> >> http://sourceforge.net/powerbar/db2/
> >> _______________________________________________
> >> Lmappletserver-developers mailing list
> >> Lma...@li...
> >> https://lists.sourceforge.net/lists/listinfo/lmappletserver-developers

Re: [Lmappletserver-developers] Dynamic bean and special characters

[Roberto M. <rob...@gm...>]

Hi Peter,

I agree.

Database metadata to be created as english (no special characters) 
names. These names will be used as keys to a property file named 
column_names.properties. In this property file the metadata keys will be 
mapped to values as wished (with special characters). These naming will 
be used only for display purpose. When generating report or xls/csv the 
database keys will be used, and if so, the class field generator will 
have no problems.

Regards,
Roberto

Peter Salomonsen wrote:
> Just as a follow up. Ideally, the metadata column names should maybe serve as 
> keys to a language property file? so that the metadata columns also could be 
> shown in different languages. In this case one would of course require that 
> the key names (= metadata column names) had valid characters.
>
> Take this into account when proposing a solution.
>
> Regards,
>
> Peter
>
> On Thursday 21 June 2007 15:32:05 Peter Salomonsen wrote:
>   
>> Hi,
>>
>> If we have column names that contain e.g. scandinavian characters like :
>> æøå , or others like ẽ é etc. there is a problem with the dynamic bean
>> setters and getters.
>>
>> Could you propose a solution for this?
>>
>> regards,
>>
>> Peter
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Lmappletserver-developers mailing list
>> Lma...@li...
>> https://lists.sourceforge.net/lists/listinfo/lmappletserver-developers
>>     
>
>
>
>