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
>