[Developers] JIRA upgrade
Hello All, As some might have noticed, we have upgraded the jira installation on http://www.mmbase.org/jira/ to the latest version. This took a little longer than expected, but now we have full subversion support. All issues now have a tab with the svn changes. Let me knwo when something is not working for you with this new installation. Regards, Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Changes in source visible in MMBase Jira
Hi, The current jira version (3.6.5) does not have the subversion module yet. I just check the administration section in Jira and 4 account are administrators at the moment. 1 admin, which had an...@finalist.com as emailaddress, but I am not sure if he still knows the password. 2 mmbaseleader, which has the same password as the mmweb ssh-account on www.mmbase.org 3 Henk 4 Nico, me IIRC an...@finalist installed the jira instance with the jira ssh-user (we both don't remember the password). I imported the bugtracker issues. j...@mmbase requested the open source license. Nico Michiel Meeuwissen wrote: On Tue, Aug 4, 2009 at 13:19, Jacobjob Kosterjacob...@finalist.com wrote: So we need an upgrade of Jira first. Can Vlamea do this, or should somebody with a login on the Confluence site do this? I don't know. Henk was talking to me, after I mailed the list. He said that he probably hand over his admin rights on the Jira, if you guys don't make objections. You mean hand over to you? I at least have no objections. I'd very much welcome the link between JIRA and SVN. greetings, Michiel ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] jstl dep. in example-webapp
Hi Ernst, Guess you are using the mvn2 build.. I saw the error last week, but didn't had the time to investigate. If the jstl.version is wrong then we should go back to the version which was also used in the maven1 build. Nico Ernst Bunders wrote: hi I had to change the jstl dependency version from 1.2 to 1.1.2 to make the webapp to work. There is now a discrepancy between the jstl and the standard libraries. This couses ClassNotFound exceptions on javax.el.ELException, even when this is on the classpath. Changing the jstl version to 1.1.2 and rebuilding the example-webapp fixed it for me. Should i commit this, or is there a reason for using jstl version 1.2 (i couldn't find a matching standards jar) regards, Ernst ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Maven2
Michiel Meeuwissen wrote: On Wed, Mar 4, 2009 at 13:09, Nico Klasens mmb...@klasens.net wrote: Hello Michiel, I have been playing around for some hours the last weeks with my preferred maven2 build structure. I commited the head to a subversion and started moving the files in the way I wanted it. See http://nico.klasens.net/svn/trunk/mmbase/. Big advatnages. Simple poms which use the provided mojo's instead of our own. Any level of rhe build can trigger a multimodule build. I creatwd two mojo's. 1 for the INDEX files (copy of yours) and 2 an RemoteGenerator for the rmmci build. A lot is also usable in the current structure, but I would prefer somthing like mine. I think your proposal is preferable above what is now in CVS. Though on one hand I find some merit in our current, less complicated directory structure (src, blocks, template, config, vs. src/main/java, src/main/webapp, src/main/config), on the other hand this default maven directory structure is used more universally so probably more readily understandable. That using that structure also simplifies the pom's and largely obsoletes the Mojo I deviced is an argument too, though I must say that I found the amount of code to arrange everything quite modest. The big disadvantages of changing the directory structure is that you can't simply move things in CVS, so it would be best to migrate to svn first, and that it would be silly to try to keep the existing build scripts working, so I'd propose to simply drop those. These are hardly technical probems though. greetings, Michiel Just committed some maven stuff which was in my structure and could be applied to the current one. It is now possible to run a full multimodule build when you run mvn inside the mmbase all checkout/maven directory. I don't mind the directory strucuture how it is in /applications The ugliest part of the build is that the mmbase.jar is build in the root. This prevents that the modules sectioncan be added to the /pom.xml. I put it now in the /maven/pom.xml. The /maven-base/pom.xml is still the master pom with overall project information. When the snapshots are installed in the mmbase.org repository then it is even possible to only checkout a small project and build only that one. I think from now on I will only use the maven 2 build for the head. Still 2 things are missing: 1 our integration tests and 2 documentation generation. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] http://www.mmbase.org/mm/documentation
The documentation in the maven build is generated when the site goal is called. The build calls maven sdocbook:generate-html when a documentation directory exists. The only thing I am not sure about are the docbook version and xslt's which are used. The problems seems to be the generation of the href on the a-tag a = target=_topHow To Use XML/a. Nico André van Toly wrote: The documentation builds fine with 'ant documentation'. I have no idea how to build it with maven. The nightly build generation (uses maven?) skips generating links right after 'MMC Mission Statement Document' which has a link in its path with a dot in it, namely: http://www.mmbase.org/mm/documentation/mmbase.org/mmcmissionstatement.html Maybe this is the cause and is it a maven bug? ---André Op 5 aug 2008, om 21:52 heeft Michiel Meeuwissen het volgende geschreven: Hi, Does anybody have any idea how come most links in the subject's URL are missing? I suppose this is a maven artifact of the 'maven-site' directory as peformed by the nightly build, and evidentely something is going wrong with it. I have however no idea what, and right away, I don't know either how I could debug it. Michiel PS, I also made a JIRA issue about this http://www.mmbase.org/jira/browse/MMB-1695 -- mihxil' http://meeuw.org nl_NL eo_XX en_US ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Performance tuning, slow query's
Hallo Winfred,
For all our mysql installations we do the following. Binary fields are
slow when you do a orderby or table scan on a MyIsam table. The full
record is read with an MyIsam which kills your perfromance when you have
MBs stored in a column. A MyIsam table is more suitable when you do full
text searches.
alter table mm_attachments ENGINE = INNODB;
alter table mm_images ENGINE = INNODB;
alter table mm_icaches ENGINE = INNODB;
Very important too are the indexes on the relation tables (insrel,
posrel, *rel, etc). This is how a show create table mm_insrel; should
look like
| mm_insrel | CREATE TABLE `mm_insrel` (
`number` int(11) NOT NULL default '0',
`otype` int(11) NOT NULL default '0',
`owner` varchar(12) NOT NULL default '',
`snumber` int(11) NOT NULL default '0',
`dnumber` int(11) NOT NULL default '0',
`rnumber` int(11) NOT NULL default '0',
`dir` int(11) default NULL,
PRIMARY KEY (`number`),
KEY `otype` (`otype`),
KEY `snumber` (`snumber`),
KEY `dnumber` (`dnumber`),
KEY `rnumber` (`rnumber`),
KEY `mm_insrel_relation_idx` (`snumber`,`dnumber`,`rnumber`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 |
When the mmbase application is written well then the index
mm_insrel_relation_idx is always used. You only get this when the
application is very specific what it wants.
mm:relatednodes type=attachments role=posrel orderby=posrel.pos
searchdir=destination will use this index, because it specifies type,
role and searchdir
A mm:relatednodes type=attachments will give you very bad
performance, because mmbase will not use any of the indexes. The sql
query created will do a where clause with an OR which can never be
resolved with 1 index. Usually the database decides to do a full table
scan (which is not nice when you have 100.000+ relations). Mysql 5
sometimss uses an index merge of snumber and dnumber, but then you are
lucky. A change to mm:relatednodes type=attachments
searchdir=destination will remove the OR part and will give you some
benefit of an index.
Another thing which kills performance is the usage of single node in
list retrieval. Below is one of the many examples which can trigger this
mm:list path=sometype fields=sometype.number max=100 %-- list
query to the database --%
mm:field name=sometype.number id=sometypeNumber /
mm:node number=${sometypeNumber} %--query to the database which
retrieves one record 'where number = 1234' --%
/mm:node
/mm:list
This example will do 101 queries on the database This is done in
sequence, because it is only one thread. This will give slow response
times no matter how fast your server is I have seen mmbase sites doing
2000+ queries in sequences on a database for one request, The customer
was complaining that their fast machine was serving pages very slow :)
Just add this to the log4j.xml and see the horror on your site :)
logger name=org.mmbase.storage.search additivity=false
level class=mmlevel; value=debug /
/logger
Nico
Winfred Peereboom wrote:
We are running mmbase 1.8 and i am busy with some performance tuning.
When i look to the different query's that are produced i notice that
there are not very efficient (example not using joins but where
statement to join). Besides that I see in my mysql proces list that an
update query on the bp_pos table while lock most of all other query's
. The tables are MyIsam. My question now is if someone has some
experience to change tables to innodb. And if he/she knows if i need
to change anything in mmbase conf.
Thanks for any anwer
Met vriendelijke groeten,
winfred Peereboom
VNUMedia
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: Betr.: Re: [Developers] Performance tuning, slow query's
Hallo Winfred,
If your database supports InnoDB then this is the only thing you have to do.
I assume that switching to innodb will not help in your lock issue, but
you could give it a try. How locks are treated depend more on the
isolation level of your connection. I never investigated issue with
mmbase and mysql lock so I don't have a lot of suggestions on that.
Nico
Winfred Peereboom wrote:
Thanks for your reply Nico,
I worked out a couple of things and hope to see (in the near future)
the some results. i added some indexes and changed some related nodes
tags as you explain.
For setting the mm_images and mm_icaches table to innodb, are there
any other changes for this to make it work. Or just give the alter
command ?
One other question is, how do you think of changing the bp_pos (or
other relation table) to innodb, because when our editor changes
something the table will be locked. Other query's have to wait before
he finished updating. Or is this something i need to fix somewhere
else so the table would not be used.
Met vriendelijke groeten,
Winfred Peereboom
Van:Nico Klasens [EMAIL PROTECTED]
Aan:Discussion list for developers developers@lists.mmbase.org
Datum: 02-07-2008 10:24
Onderwerp: Re: [Developers] Performance tuning, slow query's
Hallo Winfred,
For all our mysql installations we do the following. Binary fields are
slow when you do a orderby or table scan on a MyIsam table. The full
record is read with an MyIsam which kills your perfromance when you have
MBs stored in a column. A MyIsam table is more suitable when you do full
text searches.
alter table mm_attachments ENGINE = INNODB;
alter table mm_images ENGINE = INNODB;
alter table mm_icaches ENGINE = INNODB;
Very important too are the indexes on the relation tables (insrel,
posrel, *rel, etc). This is how a show create table mm_insrel; should
look like
| mm_insrel | CREATE TABLE `mm_insrel` (
`number` int(11) NOT NULL default '0',
`otype` int(11) NOT NULL default '0',
`owner` varchar(12) NOT NULL default '',
`snumber` int(11) NOT NULL default '0',
`dnumber` int(11) NOT NULL default '0',
`rnumber` int(11) NOT NULL default '0',
`dir` int(11) default NULL,
PRIMARY KEY (`number`),
KEY `otype` (`otype`),
KEY `snumber` (`snumber`),
KEY `dnumber` (`dnumber`),
KEY `rnumber` (`rnumber`),
KEY `mm_insrel_relation_idx` (`snumber`,`dnumber`,`rnumber`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 |
When the mmbase application is written well then the index
mm_insrel_relation_idx is always used. You only get this when the
application is very specific what it wants.
mm:relatednodes type=attachments role=posrel orderby=posrel.pos
searchdir=destination will use this index, because it specifies type,
role and searchdir
A mm:relatednodes type=attachments will give you very bad
performance, because mmbase will not use any of the indexes. The sql
query created will do a where clause with an OR which can never be
resolved with 1 index. Usually the database decides to do a full table
scan (which is not nice when you have 100.000+ relations). Mysql 5
sometimss uses an index merge of snumber and dnumber, but then you are
lucky. A change to mm:relatednodes type=attachments
searchdir=destination will remove the OR part and will give you some
benefit of an index.
Another thing which kills performance is the usage of single node in
list retrieval. Below is one of the many examples which can trigger this
mm:list path=sometype fields=sometype.number max=100 %-- list
query to the database --%
mm:field name=sometype.number id=sometypeNumber /
mm:node number=${sometypeNumber} %--query to the database which
retrieves one record 'where number = 1234' --%
/mm:node
/mm:list
This example will do 101 queries on the database This is done in
sequence, because it is only one thread. This will give slow response
times no matter how fast your server is I have seen mmbase sites doing
2000+ queries in sequences on a database for one request, The customer
was complaining that their fast machine was serving pages very slow :)
Just add this to the log4j.xml and see the horror on your site :)
logger name=org.mmbase.storage.search additivity=false
level class=mmlevel; value=debug /
/logger
Nico
Winfred Peereboom wrote:
We are running mmbase 1.8 and i am busy with some performance tuning.
When i look to the different query's that are produced i notice that
there are not very efficient (example not using joins but where
statement to join). Besides that I see in my mysql proces list that an
update query on the bp_pos table while lock most of all other query's
. The tables are MyIsam. My question now is if someone has some
experience to change tables to innodb. And if he/she knows if i need
to change anything in mmbase conf.
Thanks for any anwer
Met vriendelijke groeten,
winfred Peereboom
VNUMedia
[Developers] [Fwd: [MMBASE CVS] config/builders/core insrel.xml]
Hello, What is the scenario that this change is necessary? This change means that all databases have to be altered to prevent VERIFY wanrnings.I have no issues with creating an migration script, but I did not have any issues with it earlier. Nico Original Message Subject:[MMBASE CVS] config/builders/core insrel.xml Date: Mon, 11 Feb 2008 17:43:37 +0100 From: Michiel Meeuwissen [EMAIL PROTECTED] Reply-To: developers@lists.mmbase.org, [EMAIL PROTECTED] Organization: Publieke omroep To: [EMAIL PROTECTED] Update of /var/cvs/config/builders/core In directory james.mmbase.org:/tmp/cvs-serv10958 Modified Files: Tag: MMBase-1_8 insrel.xml Log Message: snumber, dnumber can temporary be null See also: http://cvs.mmbase.org/viewcvs/config/builders/core Index: insrel.xml === RCS file: /var/cvs/config/builders/core/insrel.xml,v retrieving revision 1.12 retrieving revision 1.12.2.1 diff -u -b -r1.12 -r1.12.2.1 --- insrel.xml 5 Jul 2006 15:21:17 - 1.12 +++ insrel.xml 11 Feb 2008 16:43:32 - 1.12.2.1 @@ -41,13 +41,11 @@ /gui editor positions - input-1/input list1/list - search1/search /positions /editor datatype base=node xmlns=http://www.mmbase.org/xmlns/datatypes; -required value=true / +required value=false / /datatype /field @@ -64,17 +62,15 @@ /gui editor positions - input-1/input list2/list - search2/search /positions /editor datatype base=node xmlns=http://www.mmbase.org/xmlns/datatypes; -required value=true / +required value=false / /datatype /field -field name=rnumber state=system +field name=rnumber state=system readonly=true descriptions description xml:lang=enThis relation's type objectnumber/description description xml:lang=nlObjectnummer van het relatietype van deze relatie/description @@ -87,9 +83,7 @@ /gui editor positions - input-1/input list3/list - search3/search /positions /editor datatype base=reldef xmlns=http://www.mmbase.org/xmlns/datatypes; @@ -97,7 +91,7 @@ /datatype /field -field name=dir state=system +field name=dir state=system readonly=true descriptions description xml:lang=en Directionality of this relation, can be uni or bi-directional (0 or 1) ___ Cvs mailing list [EMAIL PROTECTED] http://lists.mmbase.org/mailman/listinfo/cvs ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] RC1 Re: MMBase 1.8.5
Same here. I made an MMbase version with maven for the CMSc on 30-11-2007 and have not heard anyone developing on the CMScthat something is brolken. Nico André van Toly wrote: I would say: Release it! I've used 1.8.5 (or its preceders since 1.8.4) in several webapplications and haven't found any major problems. ---André Op 28 nov 2007, om 19:44 heeft Michiel Meeuwissen het volgende geschreven: http://www.mmbase.org/development/download/build_page.jsp?dir=head/stable/MMBase-1_8_5-rc1/ I hope we are about ready to release now. Release notes for 1.8.5 wil look like this: http://www.mmbase.org/development/download/head/stable/MMBase-1_8_5-rc1//release-notes.txt -- mihxil' http://meeuw.org nl_NL eo_XX en_US ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers -- André van Toly MMBase development Userfriendly webdesign W: http://www.toly.nl M: +31(0)627233562 -- ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Please help me: I got a error when I tried to use rmmci
Hello, The important line in your stacktrace is org.mmbase.bridge.remote.implementation.RemoteCloudContext_Impl.getCloud (RemoteCloudContext_Impl.java: It actually says that it could retrieve the CloudContext from the RMIRegistry, but it failed to get a connection to the stub object. The RMIRegistry only stores an url to the stub. This url is usually your hostname with port one higher than the rmiregistry port. It seems you can't connect to that one. The RMIRegistryServer in rmmci.xml was intended to make sure what the hostname was, but I found a small error in the RMMCI code the other day which fails to do that. The RMIRegistryServer should have set the system property java.rmi.server.hostname, but that does not happen. This will happen when the mmbaseroot.xml hostname is set or when it is passed to the jvm with -Djava.rmi.server.hostname=localhost. The latter one should always work. Nico Zhang Xiaofei wrote: Hi,all I met a troublesome error which cost me two days. I still don't get method to solve it now. I am really confused. When I use RMMCI module in my own pc, this error appears as blow. but when I connect to my friend's pc with tomcat5.5+mmbase1.8.4+mysql5(which is as same as my computer), it works very well. Could you give me some suggestions about this error, and how to solve it. Thank you:-) Hope to hear from you soon. Best wishes. Eddy The Error generated by eclipse: Exception in thread main org.mmbase.bridge.BridgeException: Connection refused to host: 10.1.1.102 http://10.1.1.102; nested exception is: java.net.ConnectException: Connection refused: connect at org.mmbase.bridge.remote.implementation.RemoteCloudContext_Impl.getCloud(RemoteCloudContext_Impl.java:77) at org.seaba.scheduler.jobs.mail.EmailSenderTest .init(EmailSenderTest.java:46) at org.seaba.scheduler.jobs.mail.Test.main(Test.java:5) Caused by: java.rmi.ConnectException: Connection refused to host: 10.1.1.102 http://10.1.1.102; nested exception is: java.net.ConnectException: Connection refused: connect at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source) at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source) at sun.rmi.transport.tcp.TCPChannel.newConnection (Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at org.mmbase.bridge.remote.rmi.RemoteCloudContext_Rmi_Stub.getCloud(Unknown Source) at org.mmbase.bridge.remote.implementation.RemoteCloudContext_Impl.getCloud (RemoteCloudContext_Impl.java:74) ... 2 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect (Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect (Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.init(Unknown Source) at java.net.Socket.init(Unknown Source) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket (Unknown Source) at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown Source) ... 8 more ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] position calculation in editwizard lists
Hello,
For a long time, I struggled with position calculation in lists. The
xpaths we used never worked nice. The issue was that the position was
caluclated on all lists with the same role and not the one where the
item was added to. Finaally, I found one which works so I thought I
share this with everyone.
?xml version=1.0?
!DOCTYPE list PUBLIC -//MMBase/DTD editwizard 1.0//EN
http://www.mmbase.org/dtd/wizard-schema_1_0.dtd;
list role=posrel destination=urls minoccurs=0 maxoccurs=*
orderby=[EMAIL PROTECTED]'pos'] ordertype=number
action type=create
relation destinationtype=urls role=posrel
field name=pos{sum(//[EMAIL PROTECTED]'posrel' and
@lastitem='true']/[EMAIL PROTECTED]'urls']/../[EMAIL PROTECTED]'pos'])+{$pos}}/field
object type=urls /
/relation
/action
/list
Nico
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Module#getInitParameter.
Michiel Meeuwissen wrote: 2007/4/25, Pierre van Rooden [EMAIL PROTECTED]: Michiel Meeuwissen wrote: That will have the effect that you can set any module property in web.xml or in context tag (e.g. server.xml or the specific context.xml) of tomcat.. This already exists (in 1.9). Parameters are read from the applicationcontext (overriding xml configuration) during startup, using a module's loadFromContext(). The context name of a module is mmbase/modulename, i.e. mmbase/mmbaseroot. Is this actually the same? I think I need Resource en ResourceParam and what not. Michie Hello Michiel, Some modules are adjusted in the 1.8 and head to load parameters from the context. I experimented with this to get some ideas on how we can use it in a general way. In tomcat you can put in the server.xml or context.xml. These are similar as the env-entry in web.xml Environment name=mmbase/mmbaseroot/datasource-context value=java:comp/env type=java.lang.String / Environment name=mmbase/mmbaseroot/datasource value=jdbc/cmsc type=java.lang.String / Environment name=mmbase/mmbaseroot/basename value=live type=java.lang.String / Environment name=mmbase/imaging/ImageConvertClass value=org.mmbase.module.builders.ConvertImageMagick type=java.lang.String / Environment name=mmbase/imaging/ImageConvert.ConverterCommand value=convert type=java.lang.String / Environment name=mmbase/imaging/ImageConvert.ConverterRoot value= type=java.lang.String / Environment name=mmbase/rmmci/port value= type=java.lang.String / Environment name=mmbase/rmmci/stubport value=1112 type=java.lang.String / Environment name=mmbase/rmmci/bindname value=live type=java.lang.String / !-- if RMIRegistryServer is not set RemoteMMCI looks for a RMIRegistryServer on the host defined in the mmbaseroot.xml module. -- !-- Environment name=mmbase/rmmci/RMIRegistryServer value=localhost type=java.lang.String / -- Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Dove and exception catching.
Hi Michiel, I don't have any objections against it. Error handling is one of the most annoying things in the editwizards. Nico Michiel Meeuwissen wrote: A long time ago I already did it, but I never checked it it, because there was a project to improve on dove/editwizards. But we don't hear much on that terrain. I just found a bug in my application much, much easier by firstly removing all try/catch-blocks from Dove.java again. Dove only catches Runtime-exceptions, and then tries to encode those in the response-XML. But then, Editwizards make an exception of that, which is often considerably less clear, because dove, editwizard sometimes make assumptions about the cause of the exception which are not justified. So, my proposal is to remove all try/catch blocks from Dove.java (in HEAD). How do we feel about that? Michiel ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] copy/clone a Node
Hello Leon,
You could do something like this
http://mmapps.cvs.sourceforge.net/mmapps/mmapps/mmcommons/src/java/net/sf/mmapps/commons/bridge/CloneUtil.java?revision=1.1view=markup
The cloneNodeField method is a mmbase 1.7 version. A 1.8 version would
be something like
public static void cloneNodeField(Node sourceNode, Node destinationNode,
Field field) {
if (sourceNode.getNodeManager().getField(fieldName).getState()
!= Field.STATE_SYSTEM) {
destinationNode.setValueWithoutProcess(fieldName,
sourceNode.getValueWithoutProcess(fieldName));
}
}
Regards,
Nico
Schaeps, Leon wrote:
Hello,
I want to create a function to copy a node in the Editors.
Is there a default function I can use to copy a Node with all its
fieldvalues.
Or is the best way to create a new node and loop the fields of the
source node and copy the values into the fields of the new node?
Kind Regards,
Leon
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: Didactor source to MMBase CVS
Hello Johannes and Henk, I have created the didactor project in Jira. Users can be added to the Didactor group to give permissions on the issues in the didactor project. MMBase committers are also allowed to change issues. We can turn this off when prefered. Jira also monitors the didactor cvs directory for commits. Just let me know when something does not work. Regards, Nico Henk Hangyi wrote: Hi Johannes, Congratulations! Maybe you should tell something on the next developers meeting (March 8) on how to use and develop with Didactor. Nico, could you create a jira project for Didactor (or show me on how to do it) ? Regards, Henk. ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: [MMBASE CVS] src/org/mmbase/bridge BridgeList.java
Michiel Meeuwissen wrote: 2007/2/10, Nico Klasens [EMAIL PROTECTED]: Modified Files: BridgeList.java Log Message: Created subBridgeList method -public BridgeListE subList(int s, int o); +public BridgeListE subBridgeList(int s, int o); I don't understand why that is better. We 'covariant return types' in java 1.5 so why not use it? Don't really know anymore why I did it. Might be that one of the compilers (Eclipse or Sun) did not like the normal sublist. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] jira question
Michiel Meeuwissen wrote: 2007/1/29, Nico Klasens [EMAIL PROTECTED]: Resolved means that developer has fixed the code. Closed means that the reporter has verified the fix. I think so too. This gives us a horrible job though, because at the moment there are 1135 issues with status 'resolved'. Perhaps we should consider bulk-changing them all to 'closed', and start freshly. Scheduling 140 open issues - and eventually fixing and verifying them - seems doable, but verifying the fix for 1135 solutions, on the other hand, seems sheerly impossible. I think we can easily close all issue which are resolved with fixed version 1.7.x. This will reduce it by half. For the rest we have to figure at a practical way. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] jira question
Hello Ernst, What really confuses me is the version head in the MMBob project. What do you want with it? In Jira you are always working towards a release with a real version number. Iow creating a roadmap which shows which issues are solved when. The head of cvs is not a version it will become one when yoy branch or tag it. Cvs head will become version from jira over time. Nico Ernst Bunders wrote: Nico Klasens wrote: Hello Ernst, Sounds like the issue is not solved or you want a clone of the issue for head (See left side operations). See jira documentation http://www.atlassian.com/software/jira/docs/v3.6.5/ yes, let's read the documentation for a bit. I must say I like jira a lot. I may have some questions in the end, but perhaps I give you a ring. thanks, ernst Nico Ernst Bunders wrote: hello Nico thanks for the answer. I have another question. Initially I have added bugs in the following way: I set 'affected versions' to 'unknown' and 'fix versions' to '0.9'. that should have been to 'head' as well. So, then I fix it for 0.9, and I go to 'resolve issue'. I have to chose for a 'fix version' again. Logically I would think that would be the version that has actually been fixed. But it seems I am in fact resetting the original 'fix version' from the issue. so when I choose '0.9' I remove this issue from the 'fix version' list for release 'head' That's not right, I would say. I have been playing around with it. but I can not get an issue to be fixed for 0.9, and not fixed for head. What goes wrong? am I thinking along the wrong lines here? thanks, Ernst Nico Klasens wrote: Resolved means that developer has fixed the code. Closed means that the reporter has verified the fix. Nico Ernst Bunders wrote: what is the distinction between 'resolved' and 'closed' for issues? when should i use which? thanks, Ernst ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] mmbob in bugtracker
Three people at the moment are jira-admin. Me, because I setup the jira system Andre van der Elsrt, our sysadmin at Finalist whowill maintenain the installation Henk Hangyi, he plans to setup the release and roadmap for MMBase in jira The MMbase commitors have rights on the MMBase jira project. I created different usergroups for the other projects. Iow. the contributions can get their own community around it. Nico Ernst Bunders wrote: I see there is an mmbob project too now. pretty neat. Is there some kind of administrator for mmbase jira, or is everyone supposed to do as they please? Ernst Nico Klasens wrote: I have setup the MMbase project in a special way and would like to do it the same way for other projects http://wiki.apache.org/general/ApacheJiraProjectSetup Nico Nico Klasens wrote: Maybe it is an idea to create a new jira project for each contribution. The mmbase project will then only contain issues which are maintained by all mmbase core commitors. We then can use the mmbase project as a roadmap for mmbase. A contribution jira project can then be used as a roadmap for that particular application. My idea is to move the CMS Container jira project at finalist to the mmbase.org in the near future and we already use it as a roadmap. Nico Ernst Bunders wrote: Hello all I have just created a new Component in mmbase jira for mmbob related bugs. It would be nice if known bugs and issues would be registered there. regards, Ernst ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] mmbob in bugtracker
Maybe it is an idea to create a new jira project for each contribution. The mmbase project will then only contain issues which are maintained by all mmbase core commitors. We then can use the mmbase project as a roadmap for mmbase. A contribution jira project can then be used as a roadmap for that particular application. My idea is to move the CMS Container jira project at finalist to the mmbase.org in the near future and we already use it as a roadmap. Nico Ernst Bunders wrote: Hello all I have just created a new Component in mmbase jira for mmbob related bugs. It would be nice if known bugs and issues would be registered there. regards, Ernst ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] mmbob in bugtracker
I have setup the MMbase project in a special way and would like to do it the same way for other projects http://wiki.apache.org/general/ApacheJiraProjectSetup Nico Nico Klasens wrote: Maybe it is an idea to create a new jira project for each contribution. The mmbase project will then only contain issues which are maintained by all mmbase core commitors. We then can use the mmbase project as a roadmap for mmbase. A contribution jira project can then be used as a roadmap for that particular application. My idea is to move the CMS Container jira project at finalist to the mmbase.org in the near future and we already use it as a roadmap. Nico Ernst Bunders wrote: Hello all I have just created a new Component in mmbase jira for mmbob related bugs. It would be nice if known bugs and issues would be registered there. regards, Ernst ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] DelayedGetter/DelayedSetter
Michiel Meeuwissen wrote:
Nico Klasens wrote:
1 User layer - thiu layer is user-centric and every action is based on
this user, his role and the security constraints. You could say this is
the bridge, because the cloud has a user and it applies the securtiy
constriants
2 Repository layer. This layer is used by all users and exposes all that
is in the repository. This layer maintains the model: builders,
typedefs, reldefs typerels oaliases, etc. Data which is in this layer
can be seen by all users. Data in the User layer can be specific for
that user (local modification).
3 Storage layer. This layer is responsible for pesistence and retrieval
of data. The repository layer uses this to store and retrieve nodes.
This layer decides how and when to interact with the persistent store
(database). It could use a cache instead of the trip to the persistent
store.
At the moment, the processors are called in the bridge which is
user-centric. A procesor should work just for one user and one request.
The loop example is executed for in one request and could be a local
modification until it is saved to the repository layer (this is what a
transaction does).
What my processors actually did was simply having a small static storage in
memory for those fields, and simply translate every change in 'don't change
it', and checks it on every get. One can find that an odd location, but it
is rather pragmatic, because it is shallow, and easy to implement.
iow, a quick fix :)
As a perfomance fix I would make sure the application spends as little
on the poll click. For a mmbase poll this means never cache poll data.
The queries (select and update) are fast enough for the database to
handle. You just have to configure everything else to stay in cache :)
I think that whay you say can actually be interpreted as that the current
loop in DatabaseStorageManager#change(MMObjectNode, MMObjectBuilder), to
check if there are changed fields, is wrong in the first place, and the
'change' method should not have been called at all then, and that you could
more easily agree if I moved the check from there to MMObjectNode itself to
make getChanged ignore these kind of bogus-changes. Correct?
MMObject.setValue(String fieldName, Object fieldValue) altready has such
a check. I don't know if this still works correctly.
IMO it is a quick fix, because it solves somthing in the wrong position
of the system When it is really desired to delay the database call then
the storage layer should make this decision. The processors are just to
high on the chain to be able to make a good decision. With MMbase we try
to reduce the load on the database, because mmbase can easily create a
starvation on database resources. But I don't think this is the database
killing example. It is more the many small select statements which use a
new db connection which kill the database. This update example is just
being nice for mmbase itself (caches and events).
We cache db-connections, don't we?
Yes we have a connection pool, but have you every looked how it is used?
A StorageManager is a wrapper around a connection. For every select we
request a new StorageManager from the factory which means get a new
connection from the pool. Add this to the log4j.xml and see how many
select queries MMBase creates.
logger name=org.mmbase.storage.implementation.database
additivity=false
level class=mmlevel; value =debug /
appender-ref ref=logfile /
/logger
It is probably more then you would like I have seen many mmbase
applications in production doing 500+ queries to get one page.
This obvious puts some heavy work on the cache and many queries are
dropped with concurrent users. After some days of tuning, it might be
possible to run only on caches. Many people don't realize which queries
are done when you use the taglib or bridge.
Just an example I came across this week in an article template
mm:node number=${elementId} notfound=skip
mm:field name=title /
mm:field name=body escape=none/
mm:countrelations role=posrel searchdir=destination
id=secondaryContentCount write=false /
c:if test=${secondaryContentCount gt 0}
mm:relatednodes type=article role=posrel
orderby=posrel.pos searchdir=destination
/mm:relatednodes
mm:relatednodes type=gallery role=posrel
orderby=posrel.pos searchdir=destination
/mm:relatednodes
mm:relatednodes type=faqitem role=posrel
orderby=posrel.pos searchdir=destination
/mm:relatednodes
mm:relatednodes type=newsitem role=posrel
orderby=posrel.pos searchdir=destination
/mm:relatednodes
mm:relatednodes type=page role=posrel orderby=posrel.pos
searchdir=destination
/mm:relatednodes
mm:relatednodes type=attachments role=posrel
orderby=posrel.pos searchdir=destination
Re: [Developers] DelayedGetter/DelayedSetter
I like to see MMbase in three layers. 1 User layer - thiu layer is user-centric and every action is based on this user, his role and the security constraints. You could say this is the bridge, because the cloud has a user and it applies the securtiy constriants 2 Repository layer. This layer is used by all users and exposes all that is in the repository. This layer maintains the model: builders, typedefs, reldefs typerels oaliases, etc. Data which is in this layer can be seen by all users. Data in the User layer can be specific for that user (local modification). 3 Storage layer. This layer is responsible for pesistence and retrieval of data. The repository layer uses this to store and retrieve nodes. This layer decides how and when to interact with the persistent store (database). It could use a cache instead of the trip to the persistent store. At the moment, the processors are called in the bridge which is user-centric. A procesor should work just for one user and one request. The loop example is executed for in one request and could be a local modification until it is saved to the repository layer (this is what a transaction does). In my previous reply I made a small difference between StorageManager and storage layer. The StorageManager is the accesspoint to the persistent store and also seen as the access point to the storage layer. In my defintion above this should not be the same. When you tell the persistent store to change (StorageManager). then it has to update. No matter what tha value is. I thought that MMObjectNode has code to determine that the value is equal and should not call the storage for this field. IMO it is a quick fix, because it solves somthing in the wrong position of the system When it is really desired to delay the database call then the storage layer should make this decision. The processors are just to high on the chain to be able to make a good decision. With MMbase we try to reduce the load on the database, because mmbase can easily create a starvation on database resources. But I don't think this is the database killing example. It is more the many small select statements which use a new db connection which kill the database. This update example is just being nice for mmbase itself (caches and events). Nico Michiel Meeuwissen wrote: Nico Klasens wrote: It sounds a wierd hack to me. Why would a delayed update be 10 times faster than a normal update? I would have expected it to be a little less. It can't be the database overhead so it must be code in MMbase. My guess is the eventsystem and cache updates. I mean that if you change a field a very often, that it may be enough to write it to the database only once per 10 seconds. Especially if it is no big deal if a few updates are lost, if in those 10 seconds the system happens to crash or so. The example is not very realistic too. A poll will be updated by different users, which means different cloud sessions. Every cloud should commit its changes to the system before it finishes the request. A Transaction object would have worked to speed up the loop-code too. The setValues and node commit are delayed until the transaction commit takes place. Of course, the example is a bit silly, because I update in one loop the same field very often. But it would not have made any difference if it would have been very many requests, with very many sessions and so on. I don't understand how a transaction would have helped, because I would have very many transactions then, too. The idea is to summarize several updates on the same value in one database update with the last value. And yes, a change on the StorageManager should mean an update on the database. It is called a 'storage layer' for a reason :) I mean: if I can predict that nothing will really change, should it still happen then? If i know that in the database is '1234' and I get the instruction to update that to '1234', can I be so free to do nothing at all? It is possible that in some situations that would give issues, but I don't see it yet. IOW, it is a quick fix for a more fundamental problem or it can be achieved by already existing code. You may be right, but you didn't really convince me. The more fundamental problem is I think 'mmbase persists everything to the database immediately, while that in some cases it not worth the overhead'. Since I cannot think of a generic algorithm to determin in which cases some update-collecting can be acceptable, I thought that simply indicating it like I proposed with these 'processors', would not be so wrong. Btw, I don't foresee that the poll I just implemented, will actually be that much visited that something like this is essential, so for the moment it is rather academic to me, but I can imagine situations where it is important to spare the database a bit like this. For many updates to different nodes I would like to use database
Re: [Developers] Memory leak in QueryResultCache
I have checked in a fix this morning, but I don't know how bad the performance will be, Some parts of the new code tries to optimize, but it looks a little ugly. Now, I have spend some time in the cache code and I think MMbase could use its caches better when it uses more regions which match the purpose of the query. More specialized caches should be able to flush better. The NodeListCache and RelatedNodesCache are not just QueryResultCaches. They are used on special occasions and can be flushed based on those rules. Nico Nico Klasens wrote: Hello Developers, Yesterday, I came back from a nice long christmas weekend and was confrontend with the fact that one of the cmsc demo instances had ran out of memory. I checked the access log files and this instance wasn't used for more than a week. So it could not have been this issue http://issues.apache.org/bugzilla/show_bug.cgi?id=37793 I didn't understand why it was complaining about memory after a week doing nothing. The jmap Object Histogram of java 5 showed this result. The jvm hosts 2 mmbase war files SizeCountClass description --- 250555201043980java.util.HashMap$Entry 10993632458068 org.mmbase.storage.search.implementation.BasicStepField 1085140090350java.util.HashMap$Entry[] 10757472448228 org.mmbase.storage.search.implementation.BasicStepField 6275544261481java.util.ArrayList 360924090231java.util.HashMap 264691282716 org.mmbase.storage.search.implementation.BasicFieldValueConstraint 262681682088 org.mmbase.storage.search.implementation.BasicFieldValueConstraint 216720054180java.util.TreeMap 119707224939 org.mmbase.storage.search.implementation.NodeSearchQuery 118704024730 org.mmbase.storage.search.implementation.NodeSearchQuery 118543249393 org.mmbase.storage.search.implementation.BasicCompositeConstraint 117681649034 org.mmbase.storage.search.implementation.BasicCompositeConstraint 86660854163java.util.TreeMap$1 86646454154java.util.TreeSet 77814424317 org.mmbase.storage.search.implementation.BasicFieldValueBetweenConstraint 77769624303 org.mmbase.storage.search.implementation.BasicFieldValueBetweenConstraint 68023228343java.util.Hashtable$Entry 64915227048org.mmbase.storage.search.implementation.BasicStep 61368025570org.mmbase.storage.search.implementation.BasicStep 52140816294org.mmbase.util.LRUHashtable$LRUEntry 4014723037java.util.Hashtable$Entry[] I was suprised about the fact that there were almost 25000 NodeSearchQuery instnaces in memory for each mmbase instance. We still use the default caches.xml which has max values of 300 entries. After some experiments it turns out the cache is filled by queries with a timestamp which are executed by a cronjob. More suprising is that the code explicitly sets the CachePolicy to NEVER. It turned out that the NodeManager.getList() did nothing with the CachePolicy which is easily fixed. I did some profiling and found the problem. The QueryResultCache registers observers and adds queries to a map which it should remove when nodes of a specific type change. The CacheImplementation, which is used by the QueryResultCache, can decide that queries are unsued and can be removed. This is what the LRUHashtable does. The query is still in the observer map after the CacheImplementation removed it. In other words, the QueryResultCache observers queries which are not cached anymore. As a side-effect, the performance of the cache release is bad, because more queries have to be evaluated than actually cached. In my case it was even worse, because the fields inside the query (selection, constraint and sortorder) are not updated often which will keep them in the observers. At the moment, I am investigating how to solve this issue. Suggestions are welcome. I have created an issue in jira: http://www.mmbase.org/jira/browse/MMB-1367 Regards Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Memory leak in QueryResultCache
Ernst Bunders wrote: Nico Klasens wrote: I have checked in a fix this morning, but I don't know how bad the performance will be, Some parts of the new code tries to optimize, but it looks a little ugly. Now, I have spend some time in the cache code and I think MMbase could use its caches better when it uses more regions which match the purpose of the query. More specialized caches should be able to flush better. The NodeListCache and RelatedNodesCache are not just QueryResultCaches. They are used on special occasions and can be flushed based on those rules. hi Nico With this idear in mind i have created the querycache flush rule plugin architecture. The idear is that you can easily implement different rules for flushing queries. I suppose you could also take cache policies into account in custom cache flush rules. I don't think anybody has created 'custom' rules yet or added usefull generic rules, but this framework is supposed to help you out. If not, it should perhaps be modified? regards, Ersnt It is not helping me out. The ReleaseStrategies have to analyze all queries in the QueryResultCache. Which is fine for MultiLevel queries, but a NodeList query is only concerned about one type. The NodeListCache contains queries with reuslts of nodes of one type. When a node of a type changes then it is almost certain that it should remove all queries for this type. At the moment. it has to analyze all queries in NodeListCache, but with better regions it could just flush all queries of a certain type. I haven't put this idea in the fix, but if I find the time then I will give it a try to implement it that way. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] DelayedGetter/DelayedSetter
It sounds a wierd hack to me.
Why would a delayed update be 10 times faster than a normal update? I
would have expected it to be a little less. It can't be the database
overhead so it must be code in MMbase. My guess is the eventsystem and
cache updates.
The example is not very realistic too. A poll will be updated by
different users, which means different cloud sessions. Every cloud
should commit its changes to the system before it finishes the
request. A Transaction object would have worked to speed up the
loop-code too. The setValues and node commit are delayed until the
transaction commit takes place.
And yes, a change on the StorageManager should mean an update on the
database. It is called a 'storage layer' for a reason :)
IOW, it is a quick fix for a more fundamental problem or it can be
achieved by already existing code.
Nico
Michiel Meeuwissen wrote:
I was busy with the 'poll' contribution, and figured, that for real good
performance, the updating in the database could better be 'collected'
during a certain amount of time, before actual persistance occurs.
Turns out that something like that can be quite easily achieved using the
'getprocessor/setprocessor' paradigm. I've checked in some experimental
code in the poll contribution:
http://cvs.mmbase.org/viewcvs/contributions/poll/src/org/mmbase/datatypes/processors/
These are used on the 'total_answers' field of the 'answer' builder:
http://cvs.mmbase.org/viewcvs/contributions/poll/config/builders/poll/answer.xml?view=markup
I also need a change in mmbase core though:
~/mmbase/head/src/org/mmbase/storage/implementation/database$ cvs diff
DatabaseStorageManager.java
Index: DatabaseStorageManager.java
===
RCS file:
/var/cvs/src/org/mmbase/storage/implementation/database/DatabaseStorageManager.java,v
retrieving revision 1.174
diff -r1.174 DatabaseStorageManager.java
1043c1043,1049
changeFields.add(field);
---
Object value = node.getValues().get(key);
Object origValue = node.getOldValues().get(key);
if (value == null ? origValue == null :
value.equals(origValue)) {
// no actual change, ignore that.
} else {
changeFields.add(field);
}
In other words, because 'setValue's are still called, but the processor
simply returns the old value in stead, the storage layer must be so smart
to not actually perform an update query if nothing actually changed. I first
thought that the 'changed' flag of node would do here, but it doesn't
because that it set with any 'setValue' also if that sets it to the value
it already had. That last thing could also be changed, but it seems rather
more complicated, while DatabaseStorageManager already had the necessary
loop...
The following jsp:
c:forEach begin=1 end=1000
mm:node number=731
mm:setfield name=total_answers${_node.total_answers +
1}/mm:setfield
/mm:node
/c:forEach
executes about 10 times faster now (using mysql 5), while having no latency
in mmbase bridge (because the 'get' procesosr ensures the correct value is
returned), and latency of only 10 seconds (the 'delay' parameter in the
builder xml), in the database.
I think these 'processors' can serve much more general use, because they
could be used on any field which would possible change very often.
Should I make a hack-proposal to do that change in DatabaseStorageManager
and add those processors to mmbase.jar itself? Perhaps even for 1.8?
Any other remarks? Should I have anticipated that there can also be nodes
of which all fields change very often (which can of course all be done by
one sql update)? Does anybody know if it is essential that an actual update
occurs if you call the 'change' method in DatabaseStorageManager?
Michiel
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
[Developers] Memory leak in QueryResultCache
Hello Developers, Yesterday, I came back from a nice long christmas weekend and was confrontend with the fact that one of the cmsc demo instances had ran out of memory. I checked the access log files and this instance wasn't used for more than a week. So it could not have been this issue http://issues.apache.org/bugzilla/show_bug.cgi?id=37793 I didn't understand why it was complaining about memory after a week doing nothing. The jmap Object Histogram of java 5 showed this result. The jvm hosts 2 mmbase war files SizeCountClass description --- 250555201043980java.util.HashMap$Entry 10993632458068 org.mmbase.storage.search.implementation.BasicStepField 1085140090350java.util.HashMap$Entry[] 10757472448228 org.mmbase.storage.search.implementation.BasicStepField 6275544261481java.util.ArrayList 360924090231java.util.HashMap 264691282716 org.mmbase.storage.search.implementation.BasicFieldValueConstraint 262681682088 org.mmbase.storage.search.implementation.BasicFieldValueConstraint 216720054180java.util.TreeMap 119707224939org.mmbase.storage.search.implementation.NodeSearchQuery 118704024730org.mmbase.storage.search.implementation.NodeSearchQuery 118543249393 org.mmbase.storage.search.implementation.BasicCompositeConstraint 117681649034 org.mmbase.storage.search.implementation.BasicCompositeConstraint 86660854163java.util.TreeMap$1 86646454154java.util.TreeSet 77814424317 org.mmbase.storage.search.implementation.BasicFieldValueBetweenConstraint 77769624303 org.mmbase.storage.search.implementation.BasicFieldValueBetweenConstraint 68023228343java.util.Hashtable$Entry 64915227048org.mmbase.storage.search.implementation.BasicStep 61368025570org.mmbase.storage.search.implementation.BasicStep 52140816294org.mmbase.util.LRUHashtable$LRUEntry 4014723037java.util.Hashtable$Entry[] I was suprised about the fact that there were almost 25000 NodeSearchQuery instnaces in memory for each mmbase instance. We still use the default caches.xml which has max values of 300 entries. After some experiments it turns out the cache is filled by queries with a timestamp which are executed by a cronjob. More suprising is that the code explicitly sets the CachePolicy to NEVER. It turned out that the NodeManager.getList() did nothing with the CachePolicy which is easily fixed. I did some profiling and found the problem. The QueryResultCache registers observers and adds queries to a map which it should remove when nodes of a specific type change. The CacheImplementation, which is used by the QueryResultCache, can decide that queries are unsued and can be removed. This is what the LRUHashtable does. The query is still in the observer map after the CacheImplementation removed it. In other words, the QueryResultCache observers queries which are not cached anymore. As a side-effect, the performance of the cache release is bad, because more queries have to be evaluated than actually cached. In my case it was even worse, because the fields inside the query (selection, constraint and sortorder) are not updated often which will keep them in the observers. At the moment, I am investigating how to solve this issue. Suggestions are welcome. I have created an issue in jira: http://www.mmbase.org/jira/browse/MMB-1367 Regards Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Memory leak in QueryResultCache
Michiel Meeuwissen wrote: Nico Klasens wrote: At the moment, I am investigating how to solve this issue. Suggestions are welcome. I have created an issue in jira: http://www.mmbase.org/jira/browse/MMB-1367 IIRC there is code to remove observers, but perhaps it is not (any more?) working correctly. I don't have any immediate suggestions. Would have to dive in the code myself then too. Perhaps things are removed from the cache in an unanticipated manner (not using the remove-method or so). Good luck :-) Happy Hollydays, btw. Also to the rest of the list. MMBase 1.8 introduced a CacheImplementationInterface to support OSCache. The cache does not extend the LRUHashtable anymore The LRUHashtable calls the remove method for the least recently used key. This was the remove method of the Cache in 1.7. In 1.8, it is just the remove method of the LRUHashtable and it does not know that it is wrapped by a Cache. I am working on a fix, but don't know what the performance penalty will be. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] jira as issue management system
At the moment only the ALL module is monitored. Every jira project can monitor one CVS module. The component framework already has a jira component it is only not visible in the list, because it has no issues assigned to it. Nico Henk Hangyi wrote: Perhaps there should then also be JIRA entries for MMBase projects? E.g. how about all check-ins related to components-framework? Should we perhaps simply make a jira entry 'components project'? Hi Michiel, Yes i think also MMBase projects (and or subprojects) should also be added to JIRA. Probably the only commits which which we want to exclude from labelling are those from the speeltuin and from those from the contributions for which the JIRA is not used as issuetracker. Ok? Regards, Henk. ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] Maven repository
Hello Developers, This morning I updated the CMSContainer contribution with the latest sources. This week we are going to switch all developers to use mmbase.org, but for that the CVS files are not enough. We alos require a maven repository which is not finalist internal. Current files in cvs.mmbase.org still point to a maven repository on our intranet server. I would like to have one on mmbase.org which will contain the mmbase and cmsc binaries. So how can we set that up? Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Maven repository
André van Toly wrote: Hi Nico, Op 12-dec-2006, om 13:01 heeft Nico Klasens het volgende geschreven: Hello Developers, This morning I updated the CMSContainer contribution with the latest sources. This week we are going to switch all developers to use mmbase.org, but for that the CVS files are not enough. We alos require a maven repository which is not finalist internal. Current files in cvs.mmbase.org still point to a maven repository on our intranet server. I would like to have one on mmbase.org which will contain the mmbase and cmsc binaries. So how can we set that up? Do they need to be on cvs.mmbase.org or is www.mmbase.org enough? If the latter, please state what you would prefer and what would be the most convenient set-up? Just a dir on www.mmbase.org is enough eg (http://www.mmbase.org/maven/). A maven repository is just a directory on a webserver which follows a certain layout. It is enoguh when I can add files to this dir. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] developing mmbase applications independently
Hallo Ernst, Exactly for this question I moved to maven a year ago and only use maven in the cmsc project. The big picture of a cmsc project is MMbase CMSC core CMSC optional modules CMSC optional portlets Nijmegen project I don't want a developer on the nijmegen project bother with the fact that I upgrade the project to a new mmbase or cmsc version. At the moement, when the developer does an update on the cvs nijmegen project the maven files are renewed. The maven files contain the new version number and the maven build will download the new files. The technical lead of the cmsc project follows these steps to create a release 1 cvs update cmsc project 2 cvs tag on cmsc project 3 run clean maven build 4 deploy artifacts to remote maven repository 5 change version to the next version (maven builds will use the version for the binairies.You don't want to override the final tagged build in the maven repository) 6 checkin new version We use different version dependency strategies for each layer. MMBase - All jars have the same number (x.x.x) CMSC core - All jars have the same number (x.x.x) CMSC - optional modules - - Each jar can use the a different number, but must use the same major and minor number as the csmc it belongs to. (x.x) CMSC - optional portlets- - Each jar can use the a different number, but must use the same major and minor number as the csmc it belongs to.(x.x) Nijmegen - all jars and wars have the same version number. This number is based on the release to the customer. Regards Nico Ernst Bunders wrote: Hello Developers We at Dynasol are asked by Kennisnet to do some development/bugfixing for MMBob in the near future. They specifically requested that we should develop in the mmbase cvs repository, and build a specific Kennisnet release on top of the files produced by the mmbase contributions build. A requirement for us is that we can make releases that can be reproduced. it should be possible to branch from a previous release. To document what changes belong to a specific release. The trouble is that I can not think of a release model other than following the mmbase releases. Because the applications/contributions are dependent of mmbase and version tagging/branching follows mmbase. It is not a very good situation if we fix a number of bugs and than have to say: you can have the new version in three weeks because than a new mmbase release is being made. We could tag the mmbase repository for mmbob releases. This at least would give us the chance to recreate a release. The problem of this approach of course is that mmbase might at such a time be unstable itself. So, the crux is that an independent development model for applications is completely missing. I can not think of a way to do it right. I suppose maven could be used to disconnect the applications/contributions from mmbase as it is good at defining dependencies. But that is not the current situation. I wonder how other people look at this issue. is there something I miss? Can anybody suggest a way of working that would allow us to meet hour requirements apart from following the mmbase releases? I am looking forward to some reactions on this. regards, Ernst ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] CVS at mmbase.org
Is it just me or does the ssh login on cvs.mmbase.org fail for everyone? I can access cvs though pserver, but it fails with my ssh connection. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Bugtracker now available at www.mmbase.org/jira
André van Toly wrote: The urls http://www.mmbase.org/bug and http://www.mmbase.org/bugs now both jump to this location. With this the project of moving the bugtracker has finished (thanks all!) except for the small functionality that lists the weekly new and resolved bugs at the homepage. Does Jira have a functionality, like f.e. rss, with which i can rerealize this? Yes, jira rss is turned on by default. - go to http://www.mmbase.org/jira - click on Find issues - clik on button view - See link at top right XML This link represents your current search in a RSS feed. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] question: constraints on boolean fields
I really would suggest to use the query object. I think this works. NodeList nl= SearchUtil.findRelatedNodeList(pageNode, pagina, posrel, pagina.tonen, true, posrel.pos, up, destination); Nico Ernst Bunders wrote: hello I have a simple question, and i must say I'm quite surprised it seems to be an issue. I am using the new datatypes for the first time and i find it a problem to create a constraint on a boolean field. I have a field like this: field gui guiname xml:lang=nltonen/guiname /gui editor positions input3/input list3/list search3/search /positions /editor dt:datatype xmlns=http://www.dynasol.nl/xmlns/mmbase-shorthand; base=boolean dt:default value=true/ /dt:datatype db nametonen/name type key=false notnull=false size=50 state=persistentBOOLEAN/type /db /field this translate to a bit field in my (mysql) database: mysql desc mm_artikel; +--+-+--+-+-+---+ | Field| Type| Null | Key | Default | Extra | +--+-+--+-+-+---+ | number | int(11) | NO | PRI | | | | otype| int(11) | NO | MUL | | | | owner| varchar(12) | NO | | | | | naam | text| NO | | | | | intro| text| YES | | NULL| | | tonen| bit(1) | YES | | NULL| | | aanmaakdatum | datetime| YES | | NULL| | | door | text| YES | | NULL| | +--+-+--+-+-+---+ so far so good, but when i create a constraint using this field, ik get errors: NodeList nl = cloud.getList(null, object,posrel,pagina, pagina.number, object.number= + pageNode.getNumber() + AND pagina.tonen = 1, posrel.pos, up, destination, false); sqlConstraint = object.number=112 AND pagina.tonen = 1 exception: Invalid value for BOOLEAN field: 1.0, of type java.lang.Double i also tried: AND pagina.tonen AND pagina.tonen = true but nothing works (or, it works, but in legacy mode, and an exception is thrown each time. I havn't tried creating a Query object, because I am too lazy to do that. I think it should work like this... can anybody help me? regards, Ernst 8 rows in set (0.00 sec) ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] Bugtracker to JIRA
Hello MMBase community, After several bugfixes in the migration software I am happy to announce the transition to JIRA. All issues and useraccounts from the old bugtracker are transferred to Jira. Everybody should be able to login with his old username and password. Jira can be found on the following url: http:://www.mmbase.org/jira. Some of the features in Jira are not working yet. We are going to configure these in the upcoming weeks. Please let me know when something does not work for you. Kind regards, Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Users] Re: [Developers] Bugtracker to JIRA
Henk Hangyi wrote: Hi all, - I find that the comments are a bit chaotic. E.g. http://jira.vlamea.nl/browse/MMB-473 I think everything is present twice? But not everything? I did some research: the way this bug is presented now in jira follows the way the bug was stored in the bugtracker. E.g. http://jira.vlamea.nl/browse/MMB-246 is bug 4850 in the old bugtracker (= MMBase node 1282). This node has a description and a rational field containing the most recent bug description. Next to this, node 1282 is related to bugreportupdates 2832 and 2350 containing the history of the description. The bug with its related bugreportupdates is exactly what you see on page MMB-246. It would have been better if the information from the bugreportupdates was migrated to page: http://jira.vlamea.nl/browse/MMB-246?page=history What are we going to do with this? Leave it the way it is or ask Ryan to remove the history from the bugs in the bugtracker when migrating to Jira? I propose we do the first and leave it this way or is it to big a nuisance to live with? Regards, Henk. Imo, we have to leave it like this. The bugtracker and Jira handles changes differenrtly which results in this. In Jira you can only add Comments.When you observe the comments then you can see what has happend over time. The History page only displays the actions on the issue not the content. Now we have all the info from the bugtracker and in the way jira prefers it. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] Object with id was already registered
Hello developers,
Today, I tried to use the last version of MMBase 1.8 in my cmsc projectm
but I get the below stacktrace on this piece of code.
mm:listnodes
mm:field name=number write=false id=number/
/mm:listnodes
javax.servlet.jsp.JspTagException: Object with id number was already
registered in context 'PAGECONTEXT'PAGECONTEXT BACKING
{cloudusername=admin, number=1739}
at
org.mmbase.bridge.jsp.taglib.util.ContextContainer.register(ContextContainer.java:423)
at
org.mmbase.bridge.jsp.taglib.util.ContextContainer.register(ContextContainer.java:367)
at
org.mmbase.bridge.jsp.taglib.util.ContextContainer.register(ContextContainer.java:440)
at org.mmbase.bridge.jsp.taglib.FieldTag.doStartTag(FieldTag.java:311)
at
org.apache.jsp.editors.dashboard_jsp._jspx_meth_mm_field_0(dashboard_jsp.java:988)
at
org.apache.jsp.editors.dashboard_jsp._jspx_meth_mm_listnodes_0(dashboard_jsp.java:924)
at
org.apache.jsp.editors.dashboard_jsp._jspx_meth_mm_listnodescontainer_0(dashboard_jsp.java:721)
at
org.apache.jsp.editors.dashboard_jsp._jspx_meth_mm_haspage_0(dashboard_jsp.java:588)
at org.apache.jsp.editors.dashboard_jsp._jspService(dashboard_jsp.java:254)
I geuss this is caused by the fix for #6914 (tomcat 5.5.20, and
tagfiles. If tag used in mmbase list tag, in the tag mmbase variables
are not compatible with EL any more.)
Any ideas?
Nico
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Should we release 1.9 as MMBase 2.0?
Michiel Meeuwissen wrote: Nico Klasens wrote: A little late, but I was just too busy with other things. imo a major release is justified when we do a good implemtation of java 5. The api will change drasticly which makes it impossible to create a drop-in replacement. A good implementation should remove many of our convenience classes in the bridge. E.g. a NodeList should just become ListNode and not NodeListNode I played around with this at the component weekend and realized that it is impossible at the moment. The NodeList implementation does also some conversion of objects. You can add any object to the list and the NodeList will try to convert it to a Node. A good discussion on the API is required I think. I agree that it would be actually better to drop all List interfaces from bridge. But I am uncertain if something like that can be done, because it is obviously backwards incompatible. A thing which is, very in the bridge, undesirable. I see other options: - leave it (approximately) as is. NodeListNode is a sillyness, but you don't need to use it. You can still write simply NodeList. - roll it back. We simply don't support generics in bridge. Because of prior choices, that proves to be an impossibility. One can fear that stalling the release until a good discussion has taken place, may stall it a bit long. But anyhow those were my first 2c.. :-) On the other hand, '2.0' is only an arbitrary marker. Its main goal would be to sound better than '1.9'. It is not necessarily a mayor backwards compatibility break. If we want to do that later, we can also call it 3.0 or 4.0. There's plenty of room in that direction. I thought a little more about this and I realized that the scope for 1.9/2.0 is not clear to me. The abstract of the release plan would be transition to java 1.5 and first version of mmbase framework and component infrastructure. The above makes it sound like a minor change, but I believe it are big ones. At the component weekend we discussed a new config directory structure which would be much more future proof. When we are going to use that one then all webapps have to change. We are than not backwards compatible in respect to file locations. Source, build and deployment will change for all webapps. Transition to java 5 is still a scary thing when not well prepared. Does it mean only transition of the mmbase internals to java 5 or is it also exposed to the outside world? When only the internals are changed then it is not a major change for webapps, but when the api exposes java 5 then it is. Telling people to just use the erasure of our generic list type is stupid. The compiler will even warn you for these stupid statements. A generic type guarantees that only certain types can go in and out of the class. The NodeList does not have this constaint, because you can throw in a list of mixed types and retrieve only Node objects. Regards, Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] build broken?
It looks like the taglib does not depend yet on the new resources
application. This application will contain all sources related to
images. attachments, urls. iow the component resources which is now
hidden in the core.
Nico
Ernst Bunders wrote:
hello guys
I try to build mmbase for the first time in a while, and something
seems to be broken:
It seems that the classes in org/mmbase/util/image are removed.
regards,
Ernst
minimalistic.install:
init:
[echo] mmbase build dir:
/home/ebunders/mmbase/cvscheckout/head/mmbase/build/mmbase.jar
[mkdir] Created dir:
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/build
copy.metainf.dir:
[mkdir] Created dir:
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/build/metainf
[copy] Copying 2 files to
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/build/metainf
compile:
[mkdir] Created dir:
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/build/classes
[echo] java version: 1.5
[echo] copying to
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/build
[copy] Copying 10 files to
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/build/classes
[echo] compiling
[echo]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applicationsresources/build/mmbase-resources.jar
/home/ebunders/mmbase/cvscheckout/head/mmbase/build/lib/servlet.jar
[javac] Compiling 197 source files to
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/build/classes
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/ImageTag.java:20:
package org.mmbase.util.images does not exist
[javac] import org.mmbase.util.images.*;
[javac] ^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/ImageTag.java:22:
cannot find symbol
[javac] symbol : class Images
[javac] location: package org.mmbase.module.builders
[javac] import org.mmbase.module.builders.Images;
[javac] ^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/ImageTag.java:284:
cannot find symbol
[javac] symbol : class Dimension
[javac] location: class org.mmbase.bridge.jsp.taglib.ImageTag
[javac] public String getOutputValue(int mode, Node node,
String servletPath, Dimension dim) throws JspTagException {
[javac]^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/ImageTag.java:317:
cannot find symbol
[javac] symbol : class Dimension
[javac] location: class org.mmbase.bridge.jsp.taglib.ImageTag
[javac] public String getBaseAttributes(String url, Dimension
dim) throws JspTagException {
[javac] ^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/ImageTag.java:351:
cannot find symbol
[javac] symbol : class Dimension
[javac] location: class org.mmbase.bridge.jsp.taglib.ImageTag
[javac] public Dimension getDimension(Node node, String
template) {
[javac]^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/FieldInfoTag.java:388:
warning: [deprecation] getGUIType() in org.mmbase.bridge.Field has
been deprecated
[javac] show = field.getGUIType();
[javac] ^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/FieldListTag.java:166:
warning: [deprecation] getContextContainer() in
org.mmbase.bridge.jsp.taglib.util.ContextCollector has been deprecated
[javac] return collector.getContextContainer();
[javac] ^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/ImageTag.java:184:
cannot find symbol
[javac] symbol : variable Images
[javac] location: class org.mmbase.bridge.jsp.taglib.ImageTag
[javac] return node.getFunctionValue(cachednode, new
Parameters(Images.CACHE_PARAMETERS).set(template, template)).toNode();
[javac]
^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/ImageTag.java:210:
cannot find symbol
[javac] symbol : class Dimension
[javac] location: class org.mmbase.bridge.jsp.taglib.ImageTag
[javac] Dimension dim = getDimension(originalNode,
templateStr);
[javac] ^
[javac]
/home/ebunders/mmbase/cvscheckout/head/mmbase/applications/taglib/src/org/mmbase/bridge/jsp/taglib/ImageTag.java:352:
cannot
Re: [Developers] history.go(1) in editwizards
Hello Mischiel,
I can vaguely remember that I wrote that part. It depends which version
of the htmlarea you use. The default (/htmlarea/) has still this issue.
It removes all listeners already attached to the window onunload. The
xinha editor (bug fixed htmlarea) does not have this issue anymore. The
xinha editor does it through dom-calls and preserves the old listeners.
history.go has been in there as long as I can remember. I believe it is
IE specific, because Mozilla browsers don't understand it.
Nico
Michiel Meeuwissen wrote:
This implementation of editwizards to avoid that people push the 'back'
button of the browser is annoying me. I find that it breaks the browser,
and that there are better solutions to solve the issue. (bug #6810)
I would fix it, were it not that in javascript/editwizard.jsp the following
warning is present:
function doOnUnLoad_ew() {
// This code is still here to document not to use the onunload event handler
// Since 1.7 a new wysiwyg editor (HTMLArea) is installed which replaces the
// onunload handler with one of his own. It is hard to override that one,
// because a timer is used to wait a while before attaching it.
// In short, DON'T USE OR OVERRIDE THIS FUNCTION.
Does anybody know more about this? Why does htmlarea _replace_ the dounload
handler rather then attach one? It is actually true?
Michiel
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Should we release 1.9 as MMBase 2.0?
Hello Michiel,
A little late, but I was just too busy with other things.
imo a major release is justified when we do a good implemtation of java
5. The api will change drasticly which makes it impossible to create a
drop-in replacement.
A good implementation should remove many of our convenience classes in
the bridge. E.g. a NodeList should just become ListNode and not
NodeListNode I played around with this at the component weekend and
realized that it is impossible at the moment. The NodeList
implementation does also some conversion of objects. You can add any
object to the list and the NodeList will try to convert it to a Node. A
good discussion on the API is required I think.
Here are some informational PDF's to understand the java 5 migration
issues better.
http://www.agiledeveloper.com/download.aspx
* enums
* Java 5 Features - Part II
* Java 5 Features - Part I
* Generics in Java - Part III
* Generics in Java - Part II
* Generics in Java - Part I
Regards,
Nico
Michiel Meeuwissen wrote:
Hi,
In the light of the progresses in the 'component framework' project, the
idea rose to release the next version of MMBase not as 1.9, but as 2.0.
So an abstract of the release-plan of 2.0 could then be:
- transition to java 1.5
- first version of mmbase framework and component infrastructure
plus of course bugfixes, and other small improvements.
Completion of core changes ('core 2', see also 'MyVision'), would then
e.g. lead to an MMBase 3.0.
Michiel
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] MyVision on MMBase
Thanks Wouter, Your mail explains from a web developers point of view how I see MMBase. My focus is at the moment at installation, maintenance, security and performance on a conceptual level. How should we functional change mmbase to get these areas better. To put an idea in code has never been a problem. The problem is to let everyone have the same idea. Hope my document will accomplish this. Nico Wouter Westendorp wrote: Hello Nico and other developers, I've been following MMBase mailinglist and meetings for a few years now. During these years, I've seen many discussions about 'what is mmbase' :) I am a web developer in some way that I know PHP, SQL some Java and so on, but what is intresting me the most is the world of Content Management. I've been playing with several CMS systems like EZPublish, Mambo and Drupal, but MMBase is somehow my favorite. In my opinion, MMBase is in first case like a database abstraction layer. In the end, we all need some kind of data storage for our news, stories, projects and so on every time. Technically speaking, it is a Java layer we work on, while the RDBMS keeps our data safe and searchable. We don't have to speak SQL thanks to our editors, and we can choose any kind of DBMS manufacturer we want. Free choice, that's always nice. The best thing of MMBase however, is in my opinion the possibility to create our own object model. Every implementation has its own requirements to maintain data. What data needs to be stored, how we name it and how it interacts is a domain specific question. It is this part of MMBase which makes it very flexible and thereby a tool to use in many implementations. Take with that all the extra stuff like image and upload handling and all other technical advantages we can use and we have a lot of out ingredients for a complete CMS. Ready for tweaking of course. :) However, due to some things, it is in my opinion not a CMS, but as you name it a 'data repository'. That MMBase is not an Out of the Box CMS, is a result of its 'open domain model' which we have to implement our selves of course. As this is one of the MMBase selling points, this should be a tradeoff we cannot omit. But as a webdeveloper who want his site to be ready yesterday, I am still missing some features which distinguish it from other cms's available: First of all is a more sophisticted security mechnism. Today's multi user webapplications demand some kind of role based security system, where we can define who is allowed to access or perform changes on what kind of data. MMBase currently lacks objecttype level or fieldtype level authorization. Internationalization. I am writing web sites, so they are available world wide. So my content should be localized! I know there is a lot possible, but a generic way to translate or localize content is up to our imagination. Workflow, what's that? :) I know, better skip this one. Performance. Reading data is most of the time very fast due to caches and so on, but updates suck. Updates need to travel a long way trough all bridges and caches, so its not a surprise that this takes some time. However, for applications with a lot of updates, it is a weak point were our end user has to live with! Okay, we need a phat server for MMBase, true. Your proposal for snapshots may change this probably? Installation and maintenance is also quite diverse. One needs in depth knowledge of MMBase internals to get it running the way we want. Thanks to that, many of us have a full time job, but as a novice user, I just want to hit 'I Agree, Next, Next, Finish' :) Well, so far my complaints right now. I agree I should take a crash course Java programming and start developing MMBase 2.0 right now, but study duties prevent me from that. Till this time, I'll use MMBase as a meta-data framework editor over my content repository database system :) Greetz, Wouter Nico Klasens wrote: Hello Developers, Just before I went on vacation, a month ago, I wrote a document with my thoughts on MMBase. I just added some additional stuff to it. I like to start a discussion how to restructure and improve the MMBase system to get ready for the next stage. We don't have to implement things right away, but it could be a goal in the far future where we all can work towards. Regards, Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] MyVision on MMBase
Hello Developers, Just before I went on vacation, a month ago, I wrote a document with my thoughts on MMBase. I just added some additional stuff to it. I like to start a discussion how to restructure and improve the MMBase system to get ready for the next stage. We don't have to implement things right away, but it could be a goal in the far future where we all can work towards. Regards, Nico MyVision on MMBase.pdf Description: Adobe PDF document ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: [MMBASE CVS] src/org/mmbase/module Module.java
Pierre van Rooden wrote: An advantage is that a war tested on a development system can be copy onto a production server without any changes. I can see the usefulness, specifically for modules such as sendmail or jdbc. I would advocate to make it more generic by having Module apply it by default, rather than needing to call it for each module. I would rather experiment with it for now where it seems to be useful. I want to have a well thought design decision before we release it to the public. When everyone is going to use it we are stuck later on if we want it in some other way. I can imagine that you want to support the components in the future with the same feature. Perhaps your explanation is best added in documentation/administrators/configuration.xml, or perhaps a separate file in the administrators documentation dir. I will see if I have time between my vacation preparations to update the documentation. Regards, Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Sun Application Server
Easiest way is to zip the contents of the mmbase-webapp and call it mmbase.war. Nico achillea wrote: Dear community members, Below is a step describing how to deploy mmbase under Tomcat. 4. Copy the subdir mmbase-webapp into the servlet-engine's webapps dir, or point to it in a configuration file (e.g. server.xml of tomcat). I would be very grateful if someone could answer me how to deploy mmbase under Sun Application Server 9.0 which doesn't have server.xml and servlet-engine's webapps.I can install mmbase using tomcat, but it would be waste of memory and ports to install tomcat if Sun App server is capable to run servlets, Ear-s etc. best regards, Nikola Radakovic ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] CALL: Cloud.getPossibleContexts() / Authorization.getPossibleContexts()
Pierre van Rooden wrote: CALL FOR: Cloud.getPossibleContexts() / Authorization.getPossibleContexts() START OF VOTING: 2006-09-04 11:30 END OF CALL: 2006-09-07 11:30 [_] +1 (YES, in 1.8 and 1.9) ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] 'command server' (VOTE)
Michiel Meeuwissen wrote: START OF VOTING: 2006-09-04 15:00 END OF CALL: 2006-09-07 1500 [_] +1 (YES, in 1.8) ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] mmbase aselect samaccountnames
Sounds like a SSL handshake problem. Do you use your own signed certificate on the server? In that case you have to let the client know that it is a trusted (root) certificate.Something like java -Djavax.net.ssl.trustStore=testStore -Djavax.net.ssl.trustStorePassword=testPassword YourClient See http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html for more info. A last note, do not copy the keystore from the server to the client to use it as a trustedStore. The server keystore file also has the private key in it. ' Regards, Nico Klasens Ferdinandus, Humphrey wrote: Hi, Anyone experience with configuring mmbase aselect using samaccountnames? Keep getting “An communication error has occured, root cause: Remote host closed connection during handshake, Cause: simple bind failed” Any suggestions Kind regards, Humphrey ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] presentatie: Portlets en de CMS Container
Several times during the year we have some presentations at Finalist to inform others about new technologies or projects. We will have some presentations in august which might be interesting for mmbase users and developers. I am going to talk about portals and portlets in general. I already held this presentation on the mmbase meeting at Holland Open so you have a second change to view this. The other presentation will explain how the CMScontainer works and how it uses portals and portlets. Below is the dutch version of the email invitation on our mailinglist. You are welcome to join us on one of the below dates. Please send an email to Sander van Leeuwen ([EMAIL PROTECTED]) when you like to attend. Regards, Nico Klasens - LS, in augustus zullen Freek en Nico een presentatie geven. De volgende data zijn gepland: * Rotterdam: woe 9 augustus * Amsterdam: woe 16 augustus Het onderwerp van de presentatie gaat in op de portlet technologie en meer specifiek de CMS Container die deze technologie inzet. Het programma ziet er als volgt uit: * 18:00 - 19:00 ontvangs en maaltijd * 19:00 - 19:45 presentatie 1 o About portals + What are the problems a portal can solve? + The different portal responsibilities + Portal features at a glance o About Portlets + What are portlets? + Basic portlet concepts * 19:45 - 20:00 korte pauze * 20:00 - 20:45 presentatie 2 o Overview + Probleemstelling (waarom de CMScontainer?) + Korte uitleg over concepten + Bibliotheek (content beheer) + Pagina beheer + Rechten structuur + Workflow o Demonstatie + Dashboard/admin functies + Bibliotheek (Content beheer) + Pagina beheer * 20:45 - 21:00 discussie/afronding. Ben je geïnteresseerd in het bijwonen van een van deze sessies, of wil je collega's meenemen, mail mij dan ([EMAIL PROTECTED]). Vermeld daarbij lokatie en geef aan of je aanwezig zult zijn bij de maaltijd. groet, Sander van Leeuwen PS - als je bang bent dat een presentatie errug uitloopt dan kan ik die angst wegnemen. Tegewoordig wordt er flink geklokt zodat het programma binnen de tijd wordt afgerond. ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: [MMBASE CVS] applications/taglib/src/org/mmbase/bridge/jsp/taglib CloudTag.java
Michiel Meeuwissen wrote: Nico Klasens wrote: Download the war from http://cmsc.finalist.com and put your taglib jar So, I took the opportunity to try it out... Which gives me a list of remarks about CMSC first. Perhaps they're interesting, because I'm a naive user: The remarks are very relevant. What we try to reach is a point where we can drop a war into a configured installation without changing anything in the war. Every installation will tell the war what is expected from it. All remarks are on my wishlist, but don't have a high priority. The war you downloaded is the one which is running on cmsc.finalist.com and is not yet a drop-in war or even a demo war. - it took me quite some time to get it working. The installation notes are in the other download. I tried to get it working on hsql/jdbc.xml but did not succeed, but perhaps the problem was in something I later solved. The cmsc uses a datasource configured in tomcat. This datasource is installed the first time the war is deplayed in tomcat. The war contains a file META-INF/context.xml which is copied the first time to $TOMCAT_HOME/conf/Catalina/localhost/cmc-webapp.xml The default is currently for mysql with cmsc as db/user/password. tomcat also requires the libs for the conection pool in commn/lib - logging is configured so that configuration errors in the data-source appear in the SQL log. Which was not the file I was tailing, so I was flabbergasted for quite some time.. logging is overly specified anyway, because it is a hard job to set logging back to service. Also it may be better to leave logging on stdout in such a general download. ../logs did not exist for me. Logging is one of the things I want to move out of the war. The location and requirements of logging are always different on every system and environment. Developers like it on stdout and sysadmins in a daily rolling file in thier logs dir. - It depends on xerces. It was running tomcat 5.5 on java 1.5, with no xerces. This gave very very, huge, errors from AJAX in the editors, essentially saying that org.apache.xml.serialize.OutputFormat was missing.. Very irritating. I needed to place xercesImp.jar and xml-apis.jar in common/endorsed to get rid of it. I'd suggest to remove the dependency, which would make installation a bit easier. One of the things which are inherited from sources of old projects. I haven't found a solution yet to do it in a java standard way which supports all options. I haven't been looking very long. - If something goes wrong during start up, it remains in an eternal loop which is supposedly 'waiting for mmbase' (according to a thread-dump). On the front-end no 503 are reported, during this waiting, but requests are simply stalled. Also e..g the tomcat-manager is unreacheable during this (eternal) time. This is also a point which should be addressed, but there is not a nice solution present which can be used easily. - After a restart I needed to login again. I think that is not necessary any more, because the cloud object in the session is serializable. The tomcat context file defines a PersistentManager which turns of the session save feature. No good reason for doing it other than that the server starts in a clean state. Anyhow, finally I saw your problem with the locale. A replacement taglib-jar which is just checking the request property does not cause it, so I will add that, because it would make me happy too (I only want to set the locale in the outer-most JSP, perhaps even with mm:content language=client). So, I suppose the cause is somehow related with the checking for the parent ContextReferrers, because that is the only difference now. I think you added that at june 7, but I never quite got why. No, the issue is that it should not set the locale in the CloudTag to the mmbase locale when nothing is found in surrounding tags. It should leave the locale untouched. Okay, I know now how to refactor it nicely. I have to extract another method which only checks that the locale is set by something in the current request. The getLocale method will then call getDefaultLocale when the locale is not found by the new method. CloudTag.checkLocale will then only call the new method. Calling ContextReferrers is necessary to find the closest tag which can provide a locale. A CloudReferrer can then return the locale from the cloud. In this way you could use the cloud to keep track of which language the user has selected. It is just one of my attempt to figure out how to do localization with mmbase. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: [MMBASE CVS] applications/taglib/src/org/mmbase/bridge/jsp/taglib CloudTag.java
Michiel Meeuwissen wrote:
Nico Klasens wrote:
- it took me quite some time to get it working. The installation notes
are in the other download.
I tried to get it working on hsql/jdbc.xml but did not succeed, but
perhaps the problem was in something I later solved.
The cmsc uses a datasource configured in tomcat. This datasource is
installed the first time the war is deplayed in tomcat. The war contains
a file META-INF/context.xml which is copied the first time to
$TOMCAT_HOME/conf/Catalina/localhost/cmc-webapp.xml
The default is currently for mysql with cmsc as db/user/password. tomcat
also requires the libs for the conection pool in commn/lib
I understood how it should work, but it didn't because I didn't
immediately realise that I had to put stuff in common/lib. Happily I had
an old tomcat installation lying around which had them. It would be a
bit annoying to have to find them first. Pointers to where you can
download them would have been welcome :-)
I made a start with a maven project which should generate a zip which
constains the files to patch tomcat. Didn't finish that.
Logging is one of the things I want to move out of the war. The location
and requirements of logging are always different on every system and
environment. Developers like it on stdout and sysadmins in a daily
rolling file in thier logs dir.
We use the trick to specify the log-dir as :
!ENTITY logdir ${catalina.base}/logs/
No complete solution, and tomcat-only, but at least in our situtation it
helps a bit to make the same web-apps work in different tomcat
instances.
That is a solution, but not what I have in mind. For instance, log files
on linux/unix are usually stored in /var/log/. Good hosters have
maintenance tasks running on that part of the filesystem. What should be
logged is also different per environment. In development you want to
know a lot, but not in production.
- If something goes wrong during start up, it remains in an eternal loop
which is supposedly 'waiting for mmbase' (according to a
thread-dump). On the front-end no 503 are reported, during this
waiting, but requests are simply stalled. Also e..g the
tomcat-manager is unreacheable during this (eternal) time.
This is also a point which should be addressed, but there is not a nice
solution present which can be used easily.
There are some classes like MMBaseStarter en MMBaseStartThread which are
used by the MMBase servlets themselves. I don't know if they are useable
in this case, but they might...
I have to wait until the mmadmin module is ready. I don't want to start
mmbase. Leaving it like this will remind me that I have to fix this
nicely in time. A poor fix will very likely not be replaced by a good one.
- After a restart I needed to login again. I think that is not necessary
any more, because the cloud object in the session is serializable.
The tomcat context file defines a PersistentManager which turns of the
session save feature. No good reason for doing it other than that the
server starts in a clean state.
Ah, that's the reason. I only later realized that that line in the
Context-XML may have been the cause :-)
No, the issue is that it should not set the locale in the CloudTag to
the mmbase locale when nothing is found in surrounding tags. It should
leave the locale untouched.
Okay, I know now how to refactor it nicely. I have to extract another
method which only checks that the locale is set by something in the
current request. The getLocale method will then call getDefaultLocale
when the locale is not found by the new method. CloudTag.checkLocale
will then only call the new method.
Calling ContextReferrers is necessary to find the closest tag which can
provide a locale. A CloudReferrer can then return the locale from the
cloud. In this way you could use the cloud to keep track of which
language the user has selected. It is just one of my attempt to figure
out how to do localization with mmbase.
I think i'm going to make a few demo-jsps for this in
mmexamples/taglib or so, which will at least define the behaviour. I may
ask you to review those then.
That okay.
Nico
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: [MMBASE CVS] applications/taglib/src/org/mmbase/bridge/jsp/taglib ContextReferrerTag.java CloudTag.java
Michiel Meeuwissen wrote: Nico Klasens wrote: Update of /var/cvs/applications/taglib/src/org/mmbase/bridge/jsp/taglib In directory james.mmbase.org:/tmp/cvs-serv10927/applications/taglib/src/org/mmbase/bridge/jsp/taglib Modified Files: ContextReferrerTag.java CloudTag.java Log Message: When The ContextReferrerTag is the CLoudTag then return null for the default locale otherwise return mmbase locale But why?. It can break the on line 847: ResourceBundle bundle = ResourceBundle.getBundle(org.mmbase.bridge.jsp.taglib.resources.messages, getLocale()); ResourceBundle throws NPE if getLocale() would return null. So, it should never do that. I'll remove getDefaultLocale from CloudTag for now. Michiel Okay, I have reverted the CloudTag back to revision 1.135. I didn't have the time to look into it why it broke every locale logic in my app and came to the fix I checked in. Spend too much time today to track the real issue. Your simplification on checkLocale forces the cloud locale to be the mmbase locale. When you need that fix then some cloud.setLocale prevention should take place somewhere, because I am not going to pass around my locale on the request all the time. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: [MMBASE CVS] applications/taglib/src/org/mmbase/bridge/jsp/taglib CloudTag.java
Michiel Meeuwissen wrote: Nico Klasens wrote: Update of /var/cvs/applications/taglib/src/org/mmbase/bridge/jsp/taglib In directory james.mmbase.org:/tmp/cvs-serv11875/applications/taglib/src/org/mmbase/bridge/jsp/taglib Modified Files: CloudTag.java Log Message: Reverted the checkLocale method, because it breaks the locale setting of the cloud. The simplification forces the cloud to set the locale to the mmbase locale. I just wanted the cloud to pick up the locale, even in a dynamic include, withouth the need for yet another mm:locale. So, I was mainly interested in it picking up the javax.servlet.jsp.jstl.fmt.locale.request attribute, which is one of the functions of the default getLocale method. I don't realy undertand how this would break the locale setting of the cloud? Would it perhaps have something to do with also checking the parent ContextReferrer? I noticed nothing going wrong with locales, so perhaps your test-case somehow differs from mine. When excactly did this happen? greetings, Michiel Download the war from http://cmsc.finalist.com and put your taglib jar in it and click around in the bibliotheek Everything is in dutch except when strings and values are requested thought the cloud (node manager names and field names). When everything is in english then you have to turn on the dutch language in your browser, because we support two languages based on the accept-language http header. In the future we might provide the possibility to select a language so I want to set the locale at one point in the code. I don't want to use the mm:locale tag all the time for two reasons. One, I don't want to pass around the locale the user is going to select in every request (easy to forget) And two, the mm:locale tag is a jsp only thing and I am not always using jsp to render pages. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] VOTE: Xinha editor in editwizards
Pierre van Rooden wrote:
I'm in favour of dropping htmlarea for a version which we don't maintain
ourselves. Honestly, I did not succeed to get xinha working in
editwizards, but I trust that it will simply work fine after you're
ready.
I tried xinha but it totally broke the wizards.
The xinha javascript throws the error : xinha_config not defined'.
After that, the cancel button doesn't work, nor does calling a
subwizard. The area doesn't show either.
Some help here is appreciated.
okay, I made a small error in the my-htmlarea.js in the xinha editor. I
didn't notice it, because I forgot that I was overriding it in the build
process to extend the functionality.
Btw, I also get errors from the datepicker javascript, and for some
vague reason the datepicker image is blown out of proportions and
takes up the entire screen. I don't think it's related, but I am
pretty sure mister Tang Lin never grasped the concept of semicolons
(whose absense causes some of the issues).
The datepicker works for me agian after the xinha editor fix.
This css line should have prevented the full screen icon
editwizard\templates\style\layout\wizard.css - input.calendar { width:
17px; height: 17px; }
Nico
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Xinha VS. htmlarea
Hello Nadia, I think that xinha offers some nice functionalities for editors. But what happens with MMBase CMSs that already have a big content database with htmlarea? I see in the mail of Nico that the migration is 'not very hard' - but how hard is that? What are the wizard.xsl's? I cannot tell our editors to compare any wizard.xsl's... The only thing I know is that if we upgrade to the new mmbasexinha in the future that there is a possibility that people will try to open an old article and that it will not look exactly the same as it looked in the past. Then I will have to know what to advice them - of preferably know well in advance a lot more about the exact differences between htmlarea and xinha so that I can understand the impact of such a change. My main reason to propose xinha instead of TinyMCE or FCKeditor is, because everyone is familiar with the htmlarea. Xinha does not treat the html differently than htmlarea. Xinha is a big bug fix version of htmlarea. Xinha is finishing the work the htmlarea people started with In some cases Xinha reacts differently on user input than htmlarea. How hard the migration is, will depend on how much custom code you have in the htmlarea. The CMScontainer has extra icons to include content, attachments and images as inline links. I rewrote this code, because xinha has a more robust version to insert links. When you don't have custom code in the htmlarea directory then it is a drop-in replacement. The wizard.xsl is for rendering the html and only includes a different htmleditor. Xinha is started with less lines of javascript code. Will the htmlarea editor remain as an option, or is it the idea that it is not anymore part of a future release? In this case there should be clear guidelines for existing users on what to do when upgrading existing sites. I think that this matter should be also posted in the users list and maybe it's the best to involve the users as well in this decision making. The htmlarea will still be in the distro. 1.8 should be a stable release where we are not allowed to remove functionality without a VERY good reason. Based on the reaction in the other thread it is better to postpone the decision and provide some alternatives and let the users decide which htmleditor they like. I am a little afraid that in the end the developers which create the application will make the decision instead of the end-users. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] VOTE: Xinha editor in editwizards
André van Toly wrote: Hi Nico, Op 10-jul-2006, om 16:50 heeft Nico Klasens het volgende geschreven: Pierre van Rooden wrote: To make things a bit easier for people to test: the wizard.xsl for tiny_mce. This assumes tiny_mce (as downloaded from the site) is employed in its entirety under the mmbase/edit/wizard dir. Okay, let's cnacel the vote and rething about a nice way to support all these editors? Maybe by providing extended wizard.xsl files? Maybe your right, but would that not be a lot of work that maybe is not needed? What are your main reasons for choosing Xinha? I was a bit put off by it when I tried to integrate it in some JSP editors I was working on. Then someone pointed me to TinyMCE, since I had not enough time to evaluate both I have I haven't looked any further. I believe everybody agrees we should drop HTMLarea but I think it is a better idea to choose one new one in stead of supporting several. First, I like TinyMCE and many others too. It is used in many big (cms) projects. TinyMCE is very well maintained at the moment. Why is took Xinha? because it is the htmlarea code base. The code is cleaned up, but is still is in the same files. It is not another editor it is still the htmlarea only more stable. The code I have seen made more sense then the old htmlarea version which had hacks on hacks. Migration to the xinha editor is easier then to TinyMCE when you have custom code. Providing both options might be a good start to let the users decide which editor they like best. In Mambo, the admin user can decide which editor will be used in the edit screens. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] VOTE: Xinha editor in editwizards
CALL FOR: Xinha editor in editwizards Last week I added the xinha editor to cvs as a replacement for the htmlarea. The xinha editor is a much better version of the htmlarea code so I want to make it the default in the editwizards. Migration to the xinha editor is not very hard, because it is still the same htmlarea codebase. Just compare the wizard.xsl's Several patches we did are nicely solved in xinha. The editor has numerous fixes to work in IE and FF. The current htmlarea is a bit buggy in FF. START OF VOTING: 2006-07-10 END OF CALL: 2006-07-14 11:00 [_] +1 (YES) [_] +0 (ABSTAIN ) [_] -1 (NO), because : Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] VOTE: Calendar-contribution
Michiel Meeuwissen wrote: [_] +1 (YES) ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] VOTE: Xinha editor in editwizards
Michiel Meeuwissen wrote: Nico Klasens wrote: Last week I added the xinha editor to cvs as a replacement for the htmlarea. The xinha editor is a much better version of the htmlarea code so I want to make it the default in the editwizards. Migration to the xinha editor is not very hard, because it is still the same htmlarea codebase. Just compare the wizard.xsl's Several patches we did are nicely solved in xinha. The editor has numerous fixes to work in IE and FF. The current htmlarea is a bit buggy in FF. START OF VOTING: 2006-07-10 END OF CALL: 2006-07-14 11:00 [X] +1 (YES) I'm in favour of dropping htmlarea for a version which we don't maintain ourselves. Honestly, I did not succeed to get xinha working in editwizards, but I trust that it will simply work fine after you're ready. I suppose you want this for 1.8.1? Or 1.8.2? Or 1.9? 1.8.1 must be release very soon, I think. Michiel It should go into a 1.6 release. Xinha does noet have frequently checkins, but the last checkin was last week. I will check the xinha editor with the distro when I check in the new wizard.xsl Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] VOTE: Xinha editor in editwizards
Michiel Meeuwissen wrote: Nico Klasens wrote: It should go into a 1.6 release. Xinha does noet have frequently 1.6? IIRC That is where we introduced the htmlarea? But 1.8 is also fine :) checkins, but the last checkin was last week. I will check the xinha editor with the distro when I check in the new wizard.xsl Is there no possibility to actually depend on xinha code, rather then copying it to our CVS? Perhaps with an automatic checkout or download or so? I think it is easier to profit from up-stream bugfixes then. The situation with htmlarea was not very optimal. Michiel Actually I don't like that, because we then might distribute a broken version. The xinha editor is not released yet, but already more stable Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Maxlength: int or long?
Pierre van Rooden wrote: I am reworking fields and datatypes so that you can redefine a field by describing it's datatype instead of using the db tag. This should be in a next release - the old way will still work, ofcourse, but it is an additional option that is primarily ment to make builder xmls cleaner. The idea is that you can specify a field as follows: field name=mydata datatype base=eline xmlns=http://www.mmbase.org/xmlns/datatypes; required value=true / maxlength value=255 / /datatype /field Which would automatically deduce type (STRING), size (255), state (persistent) and notrnull (true, dependent on required). You van override state and readionly status as field tag attributes: field name=generatedinfo state=virual readonly=true ... and override type, size, and notnull using the storage tag: field name=mydata2 datatype base=xml xmlns=http://www.mmbase.org/xmlns/datatypes; maxlength value=255 / /datatype storage type=STRING size=1024 notnull=true /field (the example may not make much sense, but there could be situations where this is needed. I didn't want to use the db.type tag, as it has a lot of other stuff. So I added a storage key that overrides a datatype's default (or defines the datatype if you do not define it). Anyway, when working on trying to determine size using a LengthDatatYpe maxLength propery I found this: - Field.getMaxLenth() is an int - LengthDataType.getMAxLength() is a long Both are (as of 1.8) part of the bridge. This means that to solve the conflict between the two is hard to do without breaking backward compatibility in the bridge. I was wodnetring what should be done? I now downsize the long to int, which works for the 1.8 release, but should we change the type of either method? And if so, when? In 1.9? Or asap? I don't care when. What disturbs me is that there are already plans to introduce migration issues from 1.8 to 1.9 even before the 1.8 release is secured in a branch. I already spend a lot of time to convert builders from the old 1.7 to the 1.8 format. Builder files are one of those things which should be stable, because everyone must use them. Changing them every release will make it much more difficult to upgrade. Do we really need a new version again? If the sole argument is to make it more cleaner then I think my argument outweights that. When there are other argument then put them in a document so we can discuss it before implementing it. Regards, Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: [MMBASE CVS] src/org/mmbase/datatypes/resources datatypes_en.properties dirs_en.properties iso639_en.properties weekdays_en.properties
Pierre van Rooden wrote: Michiel Meeuwissen wrote: default locale is not necessary en, so _en files must be available too. (perhaps the normal .properties files can be removed?) IIRC the normal .properties files are used if no file can be found for the given locale. So even if you have a system with, say, default locale 'es', if you specify 'en' as a locale, and it can't find the _en file, it should use the normal property file instead. So why do we need an _en file if the default file contains this value and the system defaults to it? It only sounds like more work. And leaving the normal property files out means that systems with different default locales fail to load even the default (english) values, unlesh you explixitly specify 'en' or make custom localized property files. Anyway, I *thought* that's how it worked. If not, maybe you can elaborate? Yhis is the way ResourceBundles work. getBundle will try to match the locale as close as possible (language, country, variant). When no bundle matched the locale then the default will be used. It is sometimes hard to reproduce this behavior in your browser when you have multiple languages in your preferences. All languages are send to the server in the http accept-language header. The server will try all languages with the ResourceBundles in the order they arrive. Some scenarios to make it more clear Scemario 1 User semds en_US amd nl_NL Server has resourcebundles:: names.properties and names_nl.properties Response will display values from names_nl.proeprties Scemario 2 User semds en_US amd nl_NL Server has resourcebundles:: names.properties names_en.properties and names_nl.properties Response will display values from names_en.proeprties Scemario 3 User semds nl_NL and en_US Server has resourcebundles:: names.properties names_en.properties and names_nl.properties Response will display values from names_nl.proeprties Scemario 4 User semds fr_FR Server has resourcebundles:: names.properties names_en.properties and names_nl.properties Response will display values from names.proeprties Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] Editwizard htmlarea
Hello Developers, Last week I found a project which improved the htmlarea we are using in the editwizards. (http://xinha.python-hosting.com/) I like this xinha editor, because it fixes several issues which annoyed me for some time. One of these issues was the focus behavior of the htmlarea. I checked in a wizard_xinha.xsl which uses the xinha editor for others to try out. When others like it too then I want to replace the htmlarea. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] mysql, strings and blobs
Mihxil' wrote:
2006/6/29, Nico Klasens [EMAIL PROTECTED]:
I haven't used the jdbc.xml for a long time in favour of the external
datasource so I missed the new comment.
I gave it a try and it semms to work.
New idea. We create two mysql files in the database dir. One for utf8
and one for latin1. The utf8 version could be the default to match with
the mmbaseroot.xml encoding. The latin1 version could be used to switch
to the old behavior
I think the mmbaseroot.xml encoding can be ignored with new versions
of mysql, which actually do support Unicode. So I think the default
mysql.xml must be cleaned up from all hackery on this terrain
('database-force-encode-text' or so). It could also contain your
proposal. It sounds good, but I don't know what were the original
reasons not to do it like that in the first place.
Michiel
Most old databases are in latin1 which will not work anymore when we
switch the default to utf8. Switching from blob to text did not change
our default.
I have the new files ready for commit.
Nico
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] mysql, strings and blobs
I haven't used the jdbc.xml for a long time in favour of the external datasource so I missed the new comment. I gave it a try and it semms to work. New idea. We create two mysql files in the database dir. One for utf8 and one for latin1. The utf8 version could be the default to match with the mmbaseroot.xml encoding. The latin1 version could be used to switch to the old behavior Nico Kees Jongenburger wrote: On 6/28/06, *Nico Klasens* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: LS, In several projects I have come across the same issue. I want to fix this in the mmbase code Searches on fields with case-insensitive queries fail, because rhe column in the database is of type blob. The lower function does not work on blobs. I know that there are some issues with mysql and enoding which mmbase works around by adding bytes to the database in iso8859-1 format. I don't want to change this. Hi actualy I performed some extensive test with mmbase and mysql with mysql configured to use utf-8 and setting the database character encoding to utf-8 (see jdbc.xml from mmbase_head) The result wat that the database really contained what was expected and that searching also worked. This will create colums with type text to mysql which makes it possible to use the lower function. I have tested this change and didn't find side-effect. Euro signs and other chanacters still work. If I remeber correctly mysql only really searches the first 256 bytes/chars of the stream. just to you know. Anybody objections for this change? No, it will just help to do mysql full-text search on the fields. ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] mysql, strings and blobs
LS,
In several projects I have come across the same issue. I want to fix
this in the mmbase code Searches on fields with case-insensitive
queries fail, because rhe column in the database is of type blob. The
lower function does not work on blobs. I know that there are some
issues with mysql and enoding which mmbase works around by adding bytes
to the database in iso8859-1 format. I don't want to change this.
The only thing I want to change is the mysql.xml.
type-mapping name=STRING min-size=1 max-size=255
type=varchar({0}) /
type-mapping name=STRING min-size=256 max-size=65535
type=text /
type-mapping name=STRING min-size=65536 max-size=16777216
type=mediumtext /
type-mapping name=XML min-size=1 max-size=255
type=varchar({0}) /
type-mapping name=XML min-size=256 max-size=65535 type=text /
type-mapping name=XML min-size=65536 max-size=16777216
type=mediumtext /
This will create colums with type text to mysql which makes it possible
to use the lower function. I have tested this change and didn't find
side-effect. Euro signs and other chanacters still work.
Anybody objections for this change?
Nico
___
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] MMBase and IRA
Johannes Verelst wrote: The issue metioned in this thread and some others are fixed. The new export is available again on http://mmbase.finalist.com I must say, it looks very good. Kudos to those involved in the conversion. And I'm a big JIRA fan also :) So when will we abandon the old bugtracker en have jira running on mmbase.org? I vote to do that asap. I have asked Jo to request a license for MMBase. This will take about two weeks. When we have the license then we can install jira. The last step is to create the import jelly script from the bugtracker and import it into jira. Sounds to me this should be possible within a month Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Lucene and extended objects
Ferdinandus, Humphrey wrote: Hello, Lucene is giving a java.lang.NullPointerException. I have extended builder B from builder A. A is part of the lucene index. When adding a B node to the database the error occurs. What could be the problem? The mmbase my editors show node B in the nodelist of A. When selecting node B from the list, it gives me the editor for builder B. This is normal functionality. Could Lucene be confused by extended objects? I hope I am making sense here….. BTW: I am using Lucene 1.7.1 and MMBase 1.7.4 Kind regards, Humphrey Could you paste the Exception to see what is going wrong. Or you could try the 1.7.9 release from http://sourceforge.net/projects/mmapps/ which has many fixes Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] MMBase and IRA
The issue metioned in this thread and some others are fixed. The new export is available again on http://mmbase.finalist.com Nico Nico Klasens wrote: Hello Developers, As some of you know we were working on a tool to export bugtracker data to jira. We have finished the tool and the result is on http://mmbase.finalist.com. imo, it is a great success You can login with your own bugtracker account. If you don't have one then login with nico/mmbase We want to replace the bugtracker with jira and this is now possible within a month. Regards, Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] MMBase and IRA
Daniel Ockeloen wrote: On Jun 22, 2006, at 10:27 AM, Kees Jongenburger wrote: On 6/22/06, *Nico Klasens* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello Developers, As some of you know we were working on a tool to export bugtracker data to jira. We have finished the tool and the result is on http://mmbase.finalist.com http://mmbase.finalist.com. imo, it is a great success You can login with your own bugtracker account. If you don't have one then login with nico/mmbase We want to replace the bugtracker with jira and this is now possible within a month. are we allowed to use jira? if so I think it's a great tool The import looks good, there is a small issue with charencoding Nice to see the convertion worked, Jira is free for opensource projects i think as a project you just have to request a license. Jira has an open source licens. When you request one and provide proof of being an open source project then you will get one for free (as in beer) I will have a look at the char encoding. It could be a conversion issue or it went wrong while migrating from development to this jira instance. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] MMBase and IRA
Kees Jongenburger wrote: Nice to see the convertion worked, Jira is free for opensource projects i think as a project you just have to request a license. Jira has an open source licens. When you request one and provide proof of being an open source project then you will get one for free (as in beer) I will have a look at the char encoding. It could be a conversion issue or it went wrong while migrating from development to this jira instance. How did you do the conversion? I think it might be interesting for other two. It is a small program which opens a connection to the database and reads the tables which are involved. The data is send to velocity templates to generate a jelly script. This jelly script can be imported into jira. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] CALL ENDS: Contributions CMSContainer
Pierre van Rooden wrote: Call result: Vote succeeded. CNS COntaienr will be added to the contributions branche. Sources are added to cvs. Build documentation is not fully up to date. I know how to write windows batch files so those are present for the build. There is a very old build.sh script, but I don't know if that one still works. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] CALL: Contributions CMSContainer
Hello Developers, Many dev meetings are already filled with things about the CMSContainer, but it is not yet a 3rd Party Package for MMbase. This mail is going to change that. There are two reasons to do this. 1 We want to provide more insight in what we are doing with the cmsc and get some feedback on the direction we are going. 2 The cmsc could be an example implementation of the mmbase component framerwork which will be defined by the project started last week. The CMScontainer is an mmbase application which extends the mmbase product with functionality required for a repository based web application. Supported core committer: Nico Klasens Maintainer: Finalist IT Group License: MPL Build system: maven Coding conventions: Finalist codiing standards. These are only in detail different from mmbase. mmbase standards are allowed. The infrastuctural requirements are: - Space in the cvss contributions module - cvs account for finalist.Over time many finalist developers will work on the cmsc and one account for all provides ease of use. START OF VOTING: 2006-06-06 END OF CALL: 2006-06-10 00:00 [_] +1 (YES) [_] +0 (ABSTAIN ) [_] -1 (NO), because : Regards Nico Klasens ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] CALL: Contributions CMSContainer
Michiel Meeuwissen wrote: Nico Klasens wrote: [X] +1 (YES) Of course, in the long rung I would even rather see this thing to be 'community' maintained and as widely used as possible and therefore an 'application'. This is not a reason to be against it being a 'contribution' though. Future will tell how many others will work on this project. At the moment. Finalist wants to have the lead in this project and that is why it is now a contribution. When it shows to be value to the mmbase community then a new status will be discussed. The finalist cvs account will be used accoding to the 3rd party package rules which means that it does not have core comitter rights. What happened to the name 'karma'? Several reasons, but the main one is that it does not match with the objectives anymore. It is still a repository based application, but it is going to use the mmbase component framework. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] CALL: Contributions CMSContainer
Johannes Verelst wrote: - How do you see MMBase committers work on the cmsc? How will communication be done between finalist developers working in one building and oher committers working from their place? Do we need infratstructure (mailinglist) for that? Should there maybe be a mmbase project to facilitate this? No thoughts went into this yet. We need some time to redefine the development process. The current development is agile with an informal roadmap. This vote is to honor the request of last week to give more insight in the work in progress on the cmsc. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] CALL: Contributions CMSContainer
Daniel Ockeloen wrote: On Jun 6, 2006, at 1:03 PM, Nico Klasens wrote: Hello Developers, - Space in the cvss contributions module My guess is the cmsc name or karma or ? CMSContainer. - cvs account for finalist.Over time many finalist developers will work on the cmsc and one account for all provides ease of use. I think asking for this is a valid question what i personally would like to see is that this account will be used like the vpro used the wwwtech acount. That its nice to add your name to each commit line so we have some idea of who did it and once you on a regular base commit code to other projects you will ask to become a full commitor (as several of the finalist people already are) this will be less confusing. The account has committer status as described in http://www.mmbase.org/mmdocs/3rdparty.html. It is not a core committer account. The usage in restricted to the CMSCointainer space. This is different than the wwwtech account. START OF VOTING: 2006-06-06 END OF CALL: 2006-06-10 00:00 [X] +1 (YES) I do think there are a few smaller issues like package naming and build process but feel we should solve/discuss them in the upcomming component meetings and should not have a effect on this vote. Shouldn't affect the vote at all according to http://www.mmbase.org/mmdocs/3rdparty.html Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] CALL: Contributions CMSContainer
Pierre van Rooden wrote: Johannes Verelst schreef: - contribution is fine with me, application would've been my first choice, but maybe that is something it can grow to. It is important to note that while contributions are the responsibility of the maintainer, it is also the priviledge of the maintainer to determine the product's course. Making it an application includes relinguishing control. It is therefor not up to use to propose it as an application, but up to the maintainer. Right. The first version will be a contribution which should be a base to build on. There is still some functionality missing to call it 1.0. The intention is to change it into an application before 2.0. Of course, only when the core committers want to maintain it. On the dev meetings it seemed like this wasn't the case, but the responses now indicate otherwise. Nico For the people, who haven't seen the demo last week on the status of the cmsc, the latest version is running on http://cmsc.finalist.com ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] CALL: New project: MMBase framework
[X] +1 (YEA, and I want to be project member) ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] RFC: MMBase frameworks
Daniel Ockeloen wrote: On May 27, 2006, at 3:08 PM, Nico Klasens wrote: Hello Ernst, The below email makes me believe that your answer on 'What is mmbase?' is different than mine. This greatly influence how we use it and what we expect from it. If I have to answer that question then I like to rephrase the question to What issue does MMbase solve? My answer is the same on both questions What issue does MMbase solve? I already wrote this in my previous mail. MMbase solves the domain of a data repository which is backed by a database. MMbase has many data management features a data repository requires. Examples of these are: search, notification, access control and type, object and relationship management. A data respository consists of a repository engine and an API to interact with the engine. The engine has to solve every aspect of the issue like storage, configuration, object model, security, search, events, etc The mmbase solution for this issue can be found inside the mmbase.jar. 'What is mmbase?' For me, the mmbase.jar and not the full distribution Hai Nico, Your proposals allowed for both models, Its clear that you and Finalist have a different view on 'what parts' of MMBase make sense. Ive tried over the last few replies to define that but you found that to be too confusing, fine. But clearly here you only point to what you think MMBase is or should be but its clearly not how we all feel. I think this discussion should focus on how we can be so damn smart that we allow both models since we define components that we _demand_ run in all these and can itself be implemented in all ways needed to match the framework of choice. Let me be clear for me i expect to use a framework (no idea which) that will mostly use the taglibs or alteast ideas based on them. I expect i can abstract many of the heavy work into functions implemented in java. And i hope and expect that the components i build or update to become components to be able to run in mine but also the other (pluto/portlets) frameworks and i expect the same from all other components that claim to be follow these specs. What needs to be done is to create a few examples (even if they are not working examples) of what a component looks like so we can all check and get a better feeling if they would work for us and fit in our model(s) of working. The goals of the soon to be project is to start defining interfaces above the bridge so for the first time we have a real shot at creating components that we can share. This is both a techinical issue and a management issue (the will to share) lets not forget that upto now (as pointed out by Johannes in the proposal) this was almost impossible and allmost nothing was shared as a result above the bridge. Lets stay focussed on these components instead of how MMBase should be used... Hello Daniel, My previous reply was an attempt to scope the issue of components which we are solving in this thread. Every issue which you solve has a scope. Every solution should stay in that scope. The issues, which I described in the reply and solved by mmbase cvs code, are totally different from the component issues. The scope of these issues are completely different than the component scope. The taglib solves the issue of rapid and scripting-like access, but that is not one of the issues described in the document of Johannes. There are two main issues (with sub-issues) in the document and they both have a scope. 1 What do we need to define a mmbase component. This is quiet easy, because the applications module and Didactor are both examples of this. 2 How can we easily integrate a component in (existing) systems. this is a lot trickier, but it has a limited scope. We have to make a list of current existing systems and compare them. Every system solves a big issue namely the customer requirements. Some of the sub-issues are solved by mmbase. Others like the templating issue are custom solutions, because mmbase does not solve those issues. Ernst writes about a system (you call it a framework) which should also be able to use components. Some of the issues in that system are solved by mmbase. In scope is how that system can integrate a component, but not how that system will implement how a component.is integrated. The systen of Ernst provides solutions for issues/wishes, but they are again not the same issues as we are discussing now. Maybe it is just me, but I just don't understand what the models are. It can't be the way we develop web applications in our organization, because that is not even on the horizon of the components scope. My guess is that it is the templating mechanism. The templating mechanism is not about displaying nodes. It is about how to aggregate html fragments. This can be done though jsp-includes, leaf/tree-includes, portals, etc. This is already in the document of Johannes
Re: [Developers] RFC: MMBase frameworks
Daniel Ockeloen wrote: On May 28, 2006, at 4:42 PM, Nico Klasens wrote: Daniel Ockeloen wrote: Hello Daniel, My previous reply was an attempt to scope the issue of components which we are solving in this thread. Every issue which you solve has a scope. Every solution should stay in that scope. The issues, which I described in the reply and solved by mmbase cvs code, are totally different from the component issues. The scope of these issues are completely different than the component scope. The taglib solves the issue of rapid and scripting-like access, but that is not one of the issues described in the document of Johannes. There are two main issues (with sub-issues) in the document and they both have a scope. 1 What do we need to define a mmbase component. This is quiet easy, because the applications module and Didactor are both examples of this. ehmm 'mmbase cvs code' you mean mmbase as we build it now i guess, the issues are the same as the component issues since are are trying to extend 'mmbase cvs code' in a way that it allows the use of components. With this project we are trying to extend what we see as mmbase i hope. Yes, mmbase cvs code is all the zips files we currently have. No, we are not extending mmbase.jar. We are creating something which will help to let different customer systems look like the same. If they look the same then it is easier to intergrate a component inside those systems. When the systems look the same then it is easier to define rules where components should adhere to. 2 How can we easily integrate a component in (existing) systems. this is a lot trickier, but it has a limited scope. We have to make a list of current existing systems and compare them. Every system solves a big issue namely the customer requirements. Some of the sub-issues are solved by mmbase. Others like the templating issue are custom solutions, because mmbase does not solve those issues. Ernst writes about a system (you call it a framework) which should also be able to use components. Some of the issues in that system are solved by mmbase. In scope is how that system can integrate a component, but not how that system will implement how a component.is integrated. The systen of Ernst provides solutions for issues/wishes, but they are again not the same issues as we are discussing now. I only call it a framework because you call it a framework in the proposal, there is talk in chaper 2 of frameworks like didactor and karma. So thats the reason why i talk of frameworks that can run/use these components if that is the wrong word for it please tell me what i should call them. eh, yes that isn't smart, calling that we are going to build an mmbase framework and then calling systems a framework too. The problem is that the mentioned systems are not real customer systems. You have to configure them to get a customer system. Maybe it is just me, but I just don't understand what the models are. It can't be the way we develop web applications in our organization, because that is not even on the horizon of the components scope. My guess is that it is the templating mechanism. The templating mechanism is not about displaying nodes. It is about how to aggregate html fragments. This can be done though jsp- includes, leaf/tree-includes, portals, etc. This is already in the document of Johannes. This is the last time ill comment on this part because i think it takes away from the real questions, models of developement its clear that there is more than one view inside the community how todo this. I for one would like to talk to the bridge as little as possible and do indeed in some ways see mmbase as a scripting language in the form of the tags. In my opinion you are solving two issue in development. Issue one is a data management issue, because you want to store nodes. You use the mmbase.jar for this to solve it which is, in my opinion, mmbase (we never going to agree on this). Issue two is that you don't want to use the api and like to script away. The solution for this is the mmbase-taglib.jar. I have the same issues and use the same solutions for it. I also have some other issues. So where is the other view? But ill repeat my core point if i understand the components correctly any component following the specs should work in any of the frameworks without changes right ? yes, preferably. My previous email is also the way I view at the software world. Every piece of software is a solution for an issue someone had. When you know the issue you also know how big its scope is or should be. I know a lot of people don't view the software world in this way. As I mentioned in an earlier email, I am still searching and this is the way I can understand and decide where to use mmbase jars. And to stir up some more, most sucessful open source products are clear on which issue
Re: [Developers] RFC: MMBase frameworks
Hello Ernst, The below email makes me believe that your answer on 'What is mmbase?' is different than mine. This greatly influence how we use it and what we expect from it. If I have to answer that question then I like to rephrase the question to What issue does MMbase solve? My answer is the same on both questions What issue does MMbase solve? I already wrote this in my previous mail. MMbase solves the domain of a data repository which is backed by a database. MMbase has many data management features a data repository requires. Examples of these are: search, notification, access control and type, object and relationship management. A data respository consists of a repository engine and an API to interact with the engine. The engine has to solve every aspect of the issue like storage, configuration, object model, security, search, events, etc The mmbase solution for this issue can be found inside the mmbase.jar. 'What is mmbase?' For me, the mmbase.jar and not the full distribution The community provides additional functionality which makes working with mmbase easier. Every added piece of functionality solves another issue. Generic editors - solves the issue of easy access to reporitory data. Editwizards - solves the issue of user-specific and task-based access of repository data Taglib - solves the issue of rapid and scripting-like access to repository data Clustering - solves the issue of several system working with the same repository data RMMCI - solves the issue of remote access to repository data. ... - ... MMbase is not a scripting language. A scripting language solves a different issue. You choose Ruby or Python for a different reason then you choose for mmbase. The taglib address some of the same aspects of the scripting language issue. Funny to hear that code obscurity is easier introduced in a type-safe languauge then in a scripting language. I always thought it was the other way around. You could create something which solves the same issue as Ruby on Rails does, but then you are not solving the same issue as mmbase does. If you think this way in development then you should ask yourself with every issue: does mmbase solve this issue. In a lot of cases the answer is no and there is always another product which will solve it. The cmsc is a good example. I have content and want to store it somewhere. MMbase solves this issue for me, because it solves data management. I also want to create html blocks which are aggregated to one html page. MMbase does not solve this issue for me. Pluto does solve this. I want to make these html blocks configurable and store this some where. This is data management again so MMbase could be used. Nico Ernst Bunders wrote: Nico Klasens wrote: Hello Ernst, hello Nico, and all others who have responded to this thread Let me first say I'm quite happy with this discussion. It is not my intention to put anybody in the hot seat, but i think it is positive to get to know each other a bit better in this way, and also perhaps get a more clear idea about what we are all doing and where the whole thing is going. 'What is mmbase?' is an unanswered question and that seems to be one of it's prime features. Still i like to hear from other people how they look at mmbase, what they see in it and where they want to take it. Secondly, let me state I'm not against any kind of development. Mmbase is flexible enough to support different methods of application. For me it is important many people use it, which ever way they see fit. This does not mean i think mmbase is equally suitable for all purposes, on which more later. Your perception on what Finalist thinks of MMbase is not the same as we (or at least I) think of MMbase. This email is my personal writing, but I am confident Finalist is on the same line. In the past years we (Finalist) have selected frameworks and products to use in our custom-made applications. The selection process is based on what customers want, what we think can help in implementing quality applications and eases development. We have seen that MMbase is not always high-quality, but it is versatile and that is what customers want. It is also very flexible which makes development easy. MMBase is NOT a fancy database. It is a data repository which is backed by a database. A database lacks many data management features a data repository has. Examples of these are: search, notification, access control and type, object and relationship management. In the java world you can choose now between a pojo based persistency framework (EJB/hibernate) or a data repository (MMBase, Jackrabbit). One of the weaker points of MMbase is that it does not communicate which concepts are used, which design decisions were made and how it prefers to do thinks. Some of the answers can be found in the code and some in the community. I am involved for a few years now, but I am still searching. I am happy
Re: [Developers] Re: Lucene module with MMBase 1.8
Sorry, I had read your mail and forgot to ask Wouter what the status was of the 1.8 version of lucene on sf.net. We got the lucene module working on 1.8 a while ago, but we didn't had the time to incorporate it in sf.net. Don't know if Wouter found the time later. Wouter, can you let me know what you have done with the changes for 1.8? Nico Ruud Prein wrote: Thanx, But with maven the module as it was downloaded from sourceforge does not compile anymore... groet, Ruud Ruud Prein wrote: Hi, I am trying to install the Lucene module 1.7.9. After following the install instruction i get the following error: 2006-05-23 23:27:23,333 INFOorg.mmbase.module.Module - Starting module lucenemodule 2006-05-23 23:27:23,334 FATAL org.mmbase.servlet.MMBaseStartThread - Could not instantiate the MMBase module! java.lang.NoSuchMethodError org.mmbase.module.Module.getModule(Ljava/lang/String;)Ljava/lang/Object; 2006-05-23 23:27:23,334 ERROR org.mmbase.servlet.MMBaseStartThread - java.lang.NoSuchMethodError: org.mmbase.module.Module.getModule(Ljava/lang/String;)Ljava/lang/Object; at net.sf.mmapps.modules.lucenesearch.LuceneModule.init(LuceneModule.java:93) at org.mmbase.module.Module.startModule(Module.java:125) at org.mmbase.module.Module.startModules(Module.java:317) at org.mmbase.module.Module.getModule(Module.java:360) at org.mmbase.module.Module.getModule(Module.java:334) at org.mmbase.module.core.MMBase.getMMBase(MMBase.java:534) at org.mmbase.servlet.MMBaseStartThread.run(MMBaseStartThread.java:40) It looks like the module is not compatable with mmbase 1.8 ?? Seems like that. It probably only needs recompilation. I think the 'getModule' method of Module returned Object, which was very silly, and therefor changed to return Module now. This gives no compile time problems, but sadly, it does give this kind of run-time issues Michel ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] RFC: MMBase frameworks
Hello Daniel, The thing I don't want is limiting the versatile and flexible nature of MMbase. This is a reason we chose MMbase in the first place. We have done many mmbase projects now and asked ourself where the issues in these projects are which limit our productivity. We came to the conclusion that project startup time and re-implementation of functionality are among these issues. We always 'clone' a project which is similar to the new one and bend it until it fits. We don't wamt that. because it always gives a problem later in the process. MMbase is the starting point of our projects. With application functionality you can work on top of MMbase, but this is not an application issue we are dealing with. These are project issues and MMbase does not yet help to solve them. The proposal changes this situation. When only half of what is in the proposal is implemented then we will be a step closer to the solution. The proposal also tries to fill the gaps between several applications which are build on top of MMbase. Some functionaities are re-implemented in these applications. It would be nice to extract those to get robust code, because many people use them. Johannes and I (and others) discussed this and we came to the conclusion that this extraction process could go easier when we add some thing to MMbase .Maybe, Johannes and I got carried away by the idea and added more then is required, but on the other hand it shows how realistic we think it is. I don't think there are 2 views on MMBase. It is more a question: when do you use what in the implementation of an application. In several cases scripting is better suited then java code, but in other cases it is the other way around. I like to use the taglib and jsp to present the content. I don't have to write a lot of custom tags to get it done. Most custom tags are just a replacement when I have to write many lines of jsp code over and over again (jsp tag files are also great for this). When I write business process logic then I like java code more, because you can explain with method names and class structures what you are trying to do. For me it is very important how easy it is to read and understand what code does. Maintainability heavily depends on this. Writing maintainable code in a scripting language is much harder, but not impossible. Nico Daniel Ockeloen wrote: reposted it myself since i made even more language mistakes the normal sorry :) - We don't want to change MMbase to fit the cmsc. We also don't want to change the way you can develop with MMbase. We are only suprised that you can more easily develop with the taglib then with the bridge. Thanks for the reply Nico, i will have to read it a few more times to let it all sink in maybe ill reply a second time but this line stood out to me and i wanted to make a point and question about it. First the fear of not adding some rules to how to use MMBase (the principles and reason for components) resulted in a flexible product but also had the result that allmost nothing above the bridge was shared or shareable. This effort is all about us the mmbase developers starting to add rules (or atleast guidelines) on how to use MMBase. And we are hitting a topic that has been hidden (or we didn't want to admit it) for a few years now and this comment points to that i think. I like the fact that the proposal is make components that are shareable over mutliple frameworks and they can themselfsbe implemented in several ways because i think there are 2 main ways people use/see mmbase : 1) We make easer scripting tools so that others can make websites with it. taglibs/functions,objectbuilders, defining all in xml instead of sql or java codeare examples of this. Its felt dat non java programmers should be able to make or atleast change the products created with it. 2) All should be made by writing in java (or as you say talkto the bridge) this means there are no 'tool' builders but graphics designers and java programmers who make the needed code/interaction where configuration creates the wanted flexibility. Is this a valid view ? and a correct way to explain it to managers ? Now your proposal's main point is we might not be able to share frameworksn based on these2 models and we might not even implement the components made for these frameworks in the same way but by adding a few interface concepts we can atleast demand they are shareable and if we make them configurable very useable in all the frameworks. Is this a fair view ? Daniel. ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: Lucene module with MMBase 1.8
I will give it a try right now. Could you post the error you get? Nico Ruud Prein wrote: Hoi, I know what needs to be done, but I dont get it to compile with Maven. My knowledge of Maven is limited. Ruud Sorry, I had read your mail and forgot to ask Wouter what the status was of the 1.8 version of lucene on sf.net. We got the lucene module working on 1.8 a while ago, but we didn't had the time to incorporate it in sf.net. Don't know if Wouter found the time later. Wouter, can you let me know what you have done with the changes for 1.8? Nico Ruud Prein wrote: Thanx, But with maven the module as it was downloaded from sourceforge does not compile anymore... groet, Ruud Ruud Prein wrote: Hi, I am trying to install the Lucene module 1.7.9. After following the install instruction i get the following error: 2006-05-23 23:27:23,333 INFOorg.mmbase.module.Module - Starting module lucenemodule 2006-05-23 23:27:23,334 FATAL org.mmbase.servlet.MMBaseStartThread - Could not instantiate the MMBase module! java.lang.NoSuchMethodError org.mmbase.module.Module.getModule(Ljava/lang/String;)Ljava/lang/Object; 2006-05-23 23:27:23,334 ERROR org.mmbase.servlet.MMBaseStartThread - java.lang.NoSuchMethodError: org.mmbase.module.Module.getModule(Ljava/lang/String;)Ljava/lang/Object; at net.sf.mmapps.modules.lucenesearch.LuceneModule.init(LuceneModule.java:93) at org.mmbase.module.Module.startModule(Module.java:125) at org.mmbase.module.Module.startModules(Module.java:317) at org.mmbase.module.Module.getModule(Module.java:360) at org.mmbase.module.Module.getModule(Module.java:334) at org.mmbase.module.core.MMBase.getMMBase(MMBase.java:534) at org.mmbase.servlet.MMBaseStartThread.run(MMBaseStartThread.java:40) It looks like the module is not compatable with mmbase 1.8 ?? Seems like that. It probably only needs recompilation. I think the 'getModule' method of Module returned Object, which was very silly, and therefor changed to return Module now. This gives no compile time problems, but sadly, it does give this kind of run-time issues Michel ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Re: Lucene module with MMBase 1.8
Actuallu, I meant the maven error. There are some things before you get a compiled 1.8 version. First, you need a working mmbase 1.8 maven build, because you have to install the mmbase 1.8 jars in the maven repository Second, the mmbase dependency in the project file of the lucene module should be set to the mmbase 1.8 jar Third, you need the lucene-core-1.9-final.jar and lucene-misc-1.9-final.jar from lucene.apache.org and install it in your local maven repository. I did this and placed my result on the maven repository on mmapps.sourceforge.net. I haven't tested the result so let me know if it is not ok. The files are at http://mmapps.sourceforge.net/distributions/mmapps/jars/ (only the jar) http://mmapps.sourceforge.net/distributions/mmapps/mmbase-modules/ (zip archive with all required files) Regards, Nico Ruud Prein wrote: Thanx, The error: The return variable of the getModule has been changed. I think thats all that need to be changed. Further more, the project.xml of Maven does not work anymore. I am trying to install the Lucene module 1.7.9. After following the install instruction i get the following error: 2006-05-23 23:27:23,333 INFOorg.mmbase.module.Module - Starting module lucenemodule 2006-05-23 23:27:23,334 FATAL org.mmbase.servlet.MMBaseStartThread - Could not instantiate the MMBase module! java.lang.NoSuchMethodError org.mmbase.module.Module.getModule(Ljava/lang/String;)Ljava/lang/Object; 2006-05-23 23:27:23,334 ERROR org.mmbase.servlet.MMBaseStartThread - java.lang.NoSuchMethodError: org.mmbase.module.Module.getModule(Ljava/lang/String;)Ljava/lang/Object; at net.sf.mmapps.modules.lucenesearch.LuceneModule.init(LuceneModule.java:93) at org.mmbase.module.Module.startModule(Module.java:125) at org.mmbase.module.Module.startModules(Module.java:317) at org.mmbase.module.Module.getModule(Module.java:360) at org.mmbase.module.Module.getModule(Module.java:334) at org.mmbase.module.core.MMBase.getMMBase(MMBase.java:534) at org.mmbase.servlet.MMBaseStartThread.run(MMBaseStartThread.java:40) I will give it a try right now. Could you post the error you get? Nico Ruud Prein wrote: Hoi, I know what needs to be done, but I dont get it to compile with Maven. My knowledge of Maven is limited. Ruud Sorry, I had read your mail and forgot to ask Wouter what the status was of the 1.8 version of lucene on sf.net. We got the lucene module working on 1.8 a while ago, but we didn't had the time to incorporate it in sf.net. Don't know if Wouter found the time later. Wouter, can you let me know what you have done with the changes for 1.8? Nico Ruud Prein wrote: Thanx, But with maven the module as it was downloaded from sourceforge does not compile anymore... groet, Ruud Ruud Prein wrote: Hi, I am trying to install the Lucene module 1.7.9. After following the install instruction i get the following error: 2006-05-23 23:27:23,333 INFOorg.mmbase.module.Module - Starting module lucenemodule 2006-05-23 23:27:23,334 FATAL org.mmbase.servlet.MMBaseStartThread - Could not instantiate the MMBase module! java.lang.NoSuchMethodError org.mmbase.module.Module.getModule(Ljava/lang/String;)Ljava/lang/Object; 2006-05-23 23:27:23,334 ERROR org.mmbase.servlet.MMBaseStartThread - java.lang.NoSuchMethodError: org.mmbase.module.Module.getModule(Ljava/lang/String;)Ljava/lang/Object; at net.sf.mmapps.modules.lucenesearch.LuceneModule.init(LuceneModule.java:93) at org.mmbase.module.Module.startModule(Module.java:125) at org.mmbase.module.Module.startModules(Module.java:317) at org.mmbase.module.Module.getModule(Module.java:360) at org.mmbase.module.Module.getModule(Module.java:334) at org.mmbase.module.core.MMBase.getMMBase(MMBase.java:534) at org.mmbase.servlet.MMBaseStartThread.run(MMBaseStartThread.java:40) It looks like the module is not compatable with mmbase 1.8 ?? Seems like that. It probably only needs recompilation. I think the 'getModule' method of Module returned Object, which was very silly, and therefor changed to return Module now. This gives no compile time problems, but sadly, it does give this kind of run-time issues Michel ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list
Re: [Developers] RFC: MMBase frameworks
Hello Daniel, You can't make make a hard line between 2 groups of mmbase users (I am not talking about users which work with application build on MMbase). You can only divide users based on technical skill level. On one side are users who work/change/rewrite taglib pages or add javascript, flash or other parts. On the other end there are users who are working for companies like Finalist. Most of the MMbase users are somewhere between these ends. The end with less technical skills is covered by MMbase, but there are still some wishes from the point where I am standing. The proposal grants some of my wishes. It is not an xor situation where we have to take away something from the other side to fulfill my wishes. What makes thier life easier applies for me too. Didactor shows how some of my wishes could be granted. This is what is in the proposal. The proposal also address the issue with exisitng templating mechanisms currently in use and how to support them all. I don't think all users will going to use one templating mechanism Everyone will choose his templating mechanism based on his technical skill level and what is comfortable for him. MMbase only has to provide an infrastructure where all technical skill levels can do their thing. It will actually be much easier to meet customer requirements when you can choose between templating mechanisms. A lot of projects at Finalist will probably use the portlet templating mechanism, because that meets our customer wishes. MMbase only has to realize that many new customers who select the product are willing to accept higher costs for hosting. Java hosting is much more expensive than php. There are many php cms implementations which meet customer requirements when the customer doesn't want to pay for java hosting. This means that MMbase belongs to the more expensive applications and that customers in this segment demand more from their application. This also applies for the templating mechanism in their application. Nico Daniel Ockeloen wrote: Hai, Henk, Nico, I won't copy all the comments since i think it will make it more confusing to read. My main goal in trying to say there are 2 views was to make the discussion more clear on why you propose what you did. You seem to point out its more complex and its not the reason why you will allow multiple frameworks but with compatible components. Since it seems to make in more confusing ill drop this way of explaining it. Let me repeat myself i fully support the plan and think its a great starting point, I agree with Nico that you want applications in java but i personally like to bring them to the frontend using taglibs. Im not sure yet where i start in the portal stuff but i fully agree that we need one for people who want to work in that model. I don't fully agree with Henk in that there are many people who for example never used a ant compiler or changed a class file but who do work/change/rewrite taglib pages or add javascript, flash or other parts. MMBase sofar was build from zero or reuse what you used before, this also means that by design it exclused alot of people if you don't have atleast access to a programmer. But i can see more people being able to change (on all levels) things in something like didactor. It might be just settings that change what components are on/off and in what 'mode' or changing stylesheets. For others it might be changing a few simple jsp's or adding some views (these small html parts) they don't all need to have the same level of programming and i for one think its our task to think about it. Nico i tried to explain the 'why' i guess i failed, can you give me a idea of how you think this will evolve over time ? Do you feel we will merge to one framework over time ? Daniel. ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
[Developers] images/attachments filename state
Hello, Today, I noticed that the filename field is not filled anymore when you use the editwizards. The reason for this is that Dove marks the field as non-editable. Dove does this, because the state of the field is not persistent (The state is system). This has been changed in februari so I wonder what it should be. I thought system means set and maintained by mmbase. This is not the case for the filename field, because only the upload jsp can extract the uploaded name. Any insight in this would be great. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] RFC: MMBase frameworks
Hello Ernst, Your perception on what Finalist thinks of MMbase is not the same as we (or at least I) think of MMbase. This email is my personal writing, but I am confident Finalist is on the same line. In the past years we (Finalist) have selected frameworks and products to use in our custom-made applications. The selection process is based on what customers want, what we think can help in implementing quality applications and eases development. We have seen that MMbase is not always high-quality, but it is versatile and that is what customers want. It is also very flexible which makes development easy. MMBase is NOT a fancy database. It is a data repository which is backed by a database. A database lacks many data management features a data repository has. Examples of these are: search, notification, access control and type, object and relationship management. In the java world you can choose now between a pojo based persistency framework (EJB/hibernate) or a data repository (MMBase, Jackrabbit). One of the weaker points of MMbase is that it does not communicate which concepts are used, which design decisions were made and how it prefers to do thinks. Some of the answers can be found in the code and some in the community. I am involved for a few years now, but I am still searching. I am happy to hear what the 'mmbase way of things' is. (+1 for the principles) The current cmsc demo includes these mmbase dependencies: mmbase.jar, mmbase-cloudcontext.jar, mmbase-dove.jar, mmbase-editwizard.jar, mmbase-email.jar, mmbase-rmmci.jar, mmbase-taglib.jar. Some others will be used when we add some things from the wishlist. The cmsc makes a clear distinction between content repository and site management. The sole reason for this is to be able to use the content repository and another site management implementation. We decided to use pluto as the base for our small portal product. We have considered to use one of the other portal products (Liferay, jetspeed, jboss portal, etc) which would push MMbase in a position as external information system. These portal products provide many advanced features which some of our customers might need. We decided to use pluto and a stripped portal implementation to reduce complexity to have a better change of acceptance in the mmbase community. We also made sure that the mmbase taglibs could be used inside portlets. At the moment, MMbase is the base library in the cmsc. All other libraries are just utilities. The initial and still the main goal of the cmsc is to solve several development issues. It is nice that it has also benefits for our customers. We are spending time on this MMbase framework, because it has some of the same goals as we have set for the cmsc. The cmsc can be a test case for this framework. The framework is a success when we and someone else are happy in the way it works. It is a great success when a jsp based webapp and our cmsc can both benefit from it. We don't want to change MMbase to fit the cmsc. We also don't want to change the way you can develop with MMbase. We are only suprised that you can more easily develop with the taglib then with the bridge. Many of us expected to have a mmbase engine with an mmbase api. The api should allow applications to interact with the engine. All other tools (taglib, editors, etc) only makes it a better product to choose it as the base for a custom-made application. Many of us know how to apply other frameworks to solve specific issues. Not being able to use features (because they are only implemented in the taglib) makes MMbase a less interesting product for us. If MMbase prefers the taglib above the bridge then it should communicate that. We will accept that decision. As I understand from the below email, MMbase should more rely on code by convention? Then MMbase and Java are not a good fit. Java is a very type-safe programming language. Especially now in java5 with typed parameters. Not using the strong points of Java is a loss to me. I think, it is very narrow minded to say that default builders will be enough to solve all component type issues. It is also a lot of work to migrate a database to integrate the default builders. Currently, several organizations have invested a lot in their mmbase systems and they are not going to like it to convert them. Ease of collaboration is still requested. The development meetings about this subject did send us a clear message that what we visioned was not the same as what the mmbase developers had in mind. This is one of the reasons that we dropped the name karma. We will contribute with feedback to the mmbase component framework to make it a success. Next to this we continue to set out a repository standard in the mmbase world. We like to deliver several mmbase components which together create a base system for a content repository application. The first is important to you, the second is important
Re: [Developers] Call for new committer: Henk Hangyi
André van Toly wrote: CALL FOR: Making Henk Hangyi committer [_] +1 (YEA) ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] RFC: MMBase frameworks
Hello Johannes, Good idea to put this document out in the draft phase, now everyone can contribute. So here are my additions and clarifications which could be incorporated in the document. Chapter 4 There are actually 2 issues with object types. First is semantics and the second is naming collisions. We haven't discussed the naming collision and prevention in our session, but it might be nice to mention it. The semantic issue is more important for component sharing, but mmbase should deal with the naming collission too somewhere in the future. Naming collisions can be resolved by introducing namespaces like xml has. In xml namespaces are used to mix elements and attributes from different sources and applications. Every element or attribute name can be prefixed by a string which is mapped to a namespace URI. The URI namespace is universally managed and provides universal uniqueness of elements and attributes. This will have a major impact on the source code of mmbase and will also have impact on applications on top of mmbase. How often name collisions occur in practice is not clear. 4.1 should clarify that the only way mmbase component currently can operate on models by defining several base types in the inheritance tree. The base types are usually hard to integrate in existing applications and will most likely contain fields which are not used by all applications. 4.2 describes nicely how mmbase mixin types could be used. The example is similar with an existing issue in the email application. The email builder has several properties which define in which builder and field the email address of a user is stored. This sections should also make clear that the concept of mixin types is from jsr-170, but that mmbase applies it differently. Mixin types in jsr-170 are always in addition to the primary node type. MMbase uses a mixin type to map several fields to a standardized node type which is not possible in jsr-170. A mixin type in jsr-170 is assigned after creation to a node. In our proposal the mixin type is assigned to a primary node type to map fields. Considering these differences it might be wise to drop the usage of "mixin type" as name. 5.2 The cmsc already has something in place like this. A portlet is also not allowed to know how a url looks like in the browser. A portal is allowed to provide a base url or a string which can be replaced in a post process to the real url. The cmsc uses two tags for this. The renderURL tag can be used to generate a url to tell the portal to call only the render method of a portlet. The actionURL tag is used to create a url to tell the portal to call the processAction and render methods of a portlet. Both tags can have paramters which should be added to the url. A PortalURL consists of global and local navigation elements. The global navigation elements are used to retrieve the page the portlet is on and the local navigation elements are to find the portlet on the page. For example, global is /news/2006/may/ and local is position_poll. To clarify, the new tag might be similar as the mm:url, but than without the page attibute. The page attribute should be retrieved from the application framework. Nico Johannes Verelst wrote: Hi all, As some of you know (and probably others don't), I have been busy together with Nico Klasesn to see if there is a way to create an "MMBase framework". The reason is simple: many companies have spent huge amounts of money for custom MMBase implementations, and components in those implementations are never given back to the community. One of the reasons is because of the 'lock-in' to their own framework which was built on top of MMBase. With many frameworks already in existance, and the need for "generic components", I looked with Nico at Didactor, the EO site and to finalist's Karma/CMSC. The result of this session is now a word document that I attach here (html version also added). The main suggestion is: don't enforce a "great unified mmbase framework", but work the other way around: define some interfaces that frameworks should implement and components must use. That way every framework can keep its own way of doing things. So, don't enforce people to use either tree-include or leaf-include, but create an interface for creating URLs for which the EO will write an implementation for their framework which generates urls based on leaf-include. Next week, on the symposium organized by Jo, I will present this proposal to parties interested in a mechanism to share components between parties. Currently it is "my" proposal (together with Nico), but I would hope it could be "our" proposal. For that I need your comments, insights and possibly even flamewars :). Johannes ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] DateParser and calculation as offset
Michiel Meeuwissen wrote: Nico Klasens wrote: Hi, I like to write the following functionality and I was wondering if the DateParser can help with thus. I want to write a CommitProcessor on a datetime field which sets the value based on another fields value minus an offset. I like to give the CommitPorcessor a param almost like the defaultvalue of a datetime field (e.g. param name="offset"2 weeks/param). Can I use the DateParser as is or do I have to (re)write some stuff. I think you can use the DateParser 'as is'. You first must take the existing time and present is so that it can be parsed again. I think e.g. 2006-05-18 14:53 will do. Then you can add the string '- 2 week' (units are always singular!). Didn't test it, but I suppose it would work. Great. I tested it and it works. Saved me some time digging through the DateParser code Thanks, Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] MMBase 1.8.1, 1.9.0 and beyond
Kees Jongenburger wrote: On 5/12/06, Ernst Bunders [EMAIL PROTECTED] wrote: Kees Jongenburger wrote: -Hybernate is better in performance but less flexible in it's datamodel approach. it's the opposite you mean it's performace is worse but it is more flexible? Sorry , I was talking about the flexible datamodel. Hybernate is more flexible in it's data model. It can even use existing database. wana try modeling the mmbase model in hybernate ? This is exactly the point in which MMbase and Hibernate made different design choices. The hibernate guys will tell you never to use many-to-many relations anywhere. There is always a better alternative. MMbase uses many-to-many relations everywhere. But they both solve the persisitency problem Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] MMBase 1.8.1, 1.9.0 and beyond
Hello Michiel, The below is all very focused on code rhings. I am not sure that we need a CoreNode and CoreNodeManager and that we have to drop MMObjectNode or MMObjectBuilder. I rather would take a step back and observe MMBase from a distance. There are many parts in MMbase which are bloated with things that don't match the initial goal. The bridge is a very good example. It was added on top of the core to streamline many templating languages, but now it takes over some of the features the core should do. This is okay, but then we have to redefine what the responsibilities are of these parts. Another thing I don't like is the changes set and oldValues in MMObjectNode. All users are sharing these collections and can commit the MMObjectNode. The TemporaryNodeManager and the bridge are doing some magic stuff to prevent some of the issues which arise. I am vague on this, because I have never figured out how it exactly works and that is the real issue. Another one is the difference between MMObjectNodes, VirtualNodes and ClusterNodes. How can VirtualNode extend MMObjectNode and not be persistable? It inherits a feature and removes it? It is also not clear in the bridge which type of node (MMObjectNode, ClusterNode) is returned in lists, because they are both wrapped by a BasicNode. This gives a lot of confusion for application developers. The above are not examples of things that are wrong, but things that show we need more then the old concepts are providing. We should analyze them and design a solution which includes them in a nice way. When we do a step back and view at the ugly things then we should also look at other frameworks how they handle them. MMBase is a persistency layer with additional services and features. Hibernate, EJB3 and jsr-170 have some concepts which might be appliable to MMBase. For example, Hibernate makes a clear distinction between POJO's and RowSets. A POJO is our MMObjectNode and the ClusterNode matches more or less with a RowSet. We also could make that distinction instead of inheritance? Another example is the workspace and session concept of jsr-170. You login to the repository providing credentials and a workspace name. This all sound very similar as the ContextProvider and cloud login. jsr-170 returns a session. MMBase returns a cloud. The only difference is that we don't have a well defined concept for what a cloud is. When I try to explain the mmbase cloud concept I usually use the vague phrase: 'it is almost like .., but then with ... and without ...' IOW, I am not going to work on something which is anticipating what we need in a good architecture. I would love to work on something which promises me a good architecture. When you know what you are going to build then it is easier to refactor in steps. I also doubt that our end-users (the application developers) would wait for all the features you mention for 1.9. I think they rather like to see a less confusing architecture. Regards, Nico Michiel Meeuwissen wrote: Since 1.8.0 is out, we can now think about what we can do for upcoming releases. If I may start making suggestions: 1.8.x: - bugfixes (also when related to performance only) - loose ends on datatypes (XML presentation and javascript, commons-validator wrapper, LIST db type?) - loose ends on applications and contributions. 1.9.0 - dropping support for java 1.4, dropping backport-concurrent, using other java 1.5 features in the code. Evaluate what we must do with things like 'NodeList' (should it not become ListNode?) - 1.8 has made a start with a new org.mmbase.core package We must discuss how we progress with this. CoreField suggest that also CoreNode, CoreNodeManager may follow. We may introduce these in 1.9 already. - Changes necessary for the upcoming application/portlet framework. E.g. to accomodate versioning, workflow and application-packaging features more easily. - 1.8.0 is shipped with succeeding junit test-cases. 1.9 must be shipped with standardized bench-marks for performance of core, bridge, taglib etc. I feel it is a problem that must be addressed that we don't well perceive performance regressions or improvements. Something like that seems to be enough for a new major release. It should not take over 2 years again. I'd say we must strive to a release of 1.9 in 2006. And after that: 2.0 (yeah! core2, finally!, after so many years ...) - Completing of the 'code clean up' (optimization project) - Dropping MMObjectBuilder MMObjectNode, in favour of more bridge like interfaces all around (as we may have anticipated in 1.9 by filling org.mmbase.core..). - - ... Please, comment and contribute. Greetings, Michiel ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] For discussion changes the Contributions README.txt as placed in cvs
André van Toly wrote: Op 11-apr-2006, om 16:31 heeft Daniel Ockeloen het volgende geschreven: On Apr 11, 2006, at 4:15 PM, Nico Klasens wrote: Daniel Ockeloen wrote: Hai, In the vote on principles it became clear that we lost the rules on what makes a contributions. To have something ive placed the following file in CVS (in the root of contributions). Please correct any language errors ive made in this fine and place comments on the dev-list if you don't agree (i am doing this from memory even google count not fine the rules anymore). Uhh, google: MMBase 3rd Party and the first hit is http://www.mmbase.org/mmdocs18/3rdparty.html well i asked 4 developers on irc (all commitors) and they didn't know. The document is not very clear either that we are talking about the contributions cvs. If these are the rules fine but then i don't really see how for example the lucene got abstrain votes. we need to make this more clear im a commitor and i didn't get it. I want to share things i make with others and this is not helping. I believe the confusion on irc was about 'contributions' and 'applications'. The term 3rd Party packages maybe another one that adds to the confusion :-) allthough the document Nico refers to is quite clear that is neither a community application nor a contribution. ---André See http://lists.mmbase.org/arc/developers/msg11785.html Later in the thread it has been decided to call the CVS module 'Contributions'. iow contribution == 3rd Party packages Later in time, I tried to start a discussion what is suitable for this CVS module, but never had a clear anwser. So everything which is not community maintianed is eligible for proposal in this CVS module. Core committors decide if it is suitable. -1: it is NOT suitable 0: it might be suitable +1: it is suitable Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] For discussion changes the Contributions README.txt as placed in cvs
Daniel Ockeloen wrote: On Apr 11, 2006, at 5:15 PM, Nico Klasens wrote: André van Toly wrote: -1: it is NOT suitable 0: it might be suitable +1: it is suitable Nico Thanks Nico, i hope you don't mind i added the readme ill update and link it. One thing i really don't like is the gray areas in these rules, I want rules that are so clear a +1 can be expected if you follow them. Only if we feel its 'important' and 'maintained by all' we should have a deeper discussion and move it from contributions to applications. We must not forget that contributions are done by people who would like to share what they have made in the hope it will help someone. In return they will get a 'free' cvs system to make working and sharing easer. Quoted from the document A 3rd party package should be useful for others. A package which is highly customized for one person is in most cases not interesting for others. This is very vague, but you can probably judge better if it should be shared then we, as community, can. I don't think we should have very hard rules to guarantee a +1. This CVS module is created to make it EASIER for outsiders to contribute. The vote is just to ask the core committors if they think it is in the boundaries of these vague rules. An abstain can also mean that you don't have enough information to judge that, but don't want to be in the way to let the vote pass. Other committors may have the required information to judge. If the vote didn't pass, because all abstained then the next step is to explain more why you think it is suitable. Nico ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] CALL: Contributions / Lucene Module
Pierre van Rooden wrote: START OF VOTING: 2006-04-06 14:00 END OF CALL: 2006-04-11 14:00 [_] +1 (YES) [X] +0 (ABSTAIN ) [_] -1 (NO), because : ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] MMbase multicast
Hello Arjen, One vital piece of information is missing in your post. Which version of MMBase are yoy using. The multicast configuration changed during the 1.7.* releases. In 1.7.1 the settings were in the config/modules/mmbaseroot.xml file. Based on the info of your post I ttink you found the properties in this file. 1.7.2 and up moved the properties to config/utils/multicast.xml and the mmbaseroot.xml has a property sharedstorage. In 1.8 this is renamed to clustering. in 1.7.1 and previous release the logging of multicast was all on debug level. It didn't even mention that it was starting. 1.7.2 and up echos the settings from the config in the logfile on startup. When you use 1.7.1 add a logger for class org.mmbase.module.core.MMBaseMultiCast with debug in the log4j.xml and you should see some messages passing around. Another thing nice to know is: are the machines on the same wire or are there any routers/switches between them. The implementation uses a ttl of 1 which means that the packets won't leave the wire. Nico Klasens Arjen Roodselaar wrote: Hi all, I'm trying to setup MMbase to run in a cluster environment. So far I failed however and I'm running out of options to try. Maybe someone reading this will be able to point me in the right direction. The relevant part of my MMbase configuration: node 1: property name=machinenameou.work2/property property name=multicasthost226.0.0.2/property property name=multicastport9119/property property name=hostwork2.esp/property node 2: property name=machinenameou.work3/property property name=multicasthost226.0.0.2/property property name=multicastport9119/property property name=hostwork3.esp/property To avoid confusion, work2.esp and work3.esp do resolve to a valid IP address (we're using a private tld's inside our cluster) The weird thing is that I don't see any MMbase multicast traffic going over the wire when sniffing, using tcpdump ip multicast. I do see muticast traffic coming from both Tomcat processes, but it's addressed to port 8012 which seem to be some default value. Multicast is active on the OS layer as ifconfig is telling me my NIC is running in multicast mode and I'm able to ping 224.0.0.1 and receive a response from all machines. I've a feeling I'm missing some sort of master switch, which I need to turn from false to true to enable MMbase clustering. Something I noticed in the log when editing nodes (which should trigger multicast traffic): 2006-03-23 11:34:14,382 WARN mmbase.module.core.ClusterBuilder addRelationDirections.1656 - No relation defined between educations and images using RelationStep(tablename:pos2rel, alias:pos2rel, nodes:[], dir:destination, role:498) with direction(s) BOTH. Searching in 'destination' direction now, but perhaps the query should be fixed, because this should always result nothing.2006-03-23 11:20:04,826 FATAL STDERR println.258 - java.lang.NullPointerException 2006-03-23 11:20:04,827 WARN STDERR println.250 - at org.mmbase.module.builders.MMEvents.probeCall(MMEvents.java:119) 2006-03-23 11:20:04,827 WARN STDERR println.250 - at org.mmbase.module.builders.MMEventsProbe.run(MMEventsProbe.java:56) 2006-03-23 11:20:04,828 WARN STDERR println.250 - at java.lang.Thread.run(Thread.java:534) I'm told however this is should not be directly related to my multicast problem. Somebody who has an idea of what I'm missing? Thanks in advance for any input! Arjen Roodselaar ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Node loss during conversion
Didn't comment on this in my previous post. Or you are missing the typerel for allowed relation learnblocks-pos2rel-images or the application does a call for relatednodes which is not possible in the current model. First case is configuration. Second case is code Nico Arjen Roodselaar wrote: 2006-03-09 22:37:18,467 WARN mmbase.module.core.ClusterBuilder addRelationDirections.1656 - No relation defined between educations and images using RelationStep(tablename:pos2rel, alias:pos2rel, nodes:[], dir:destination, role:51130) with direction(s) BOTH. Searching in 'destination' direction now, but perhaps the query should be fixed, because this should always result nothing. 2006-03-09 22:37:18,930 WARN mmbase.module.core.ClusterBuilder addRelationDirections.1656 - No relation defined between learnblocks and images using RelationStep(tablename:pos2rel, alias:pos2rel, nodes:[], dir:destination, role:51130) with direction(s) BOTH. Searching in 'destination' direction now, but perhaps the query should be fixed, because this should always result nothing. While I'm at it; does anybody know what the ClusterBuilder error means exactly, whether this is a code of a configuration problem, and how this can be fixed? ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] Node loss during conversion
It could also be a newer version of the mysql driver which causes this. The code I patched receives a list with partially loaded nodes and converts them to fully loaded nodes. It uses a select fields from table where number in (numbers); The old code just adds all numbers from the passed-in list to the numbers. Newer versions of mysql remove duplicate numbers and return the records only once. Older version just returned duplicate records. The code checked if the passed-in list size is equal to the size of records returned from the database. This was correct for older version, but is a wrong assumption. To verify if it is the above problem, you could change the logging for org.mmbase.module.database.MultiConnection to debug. This will log all sql queries. Just look for the queries with the same signature as mentioned above. What you also could try is replacing the WEB-INF/lib/mysql*.jar with an old version. For example use the jar from the old didactor application. When the errors go away then you don't have to worry other then that the logfile will be spammed. An easy fix for that is to change the log4j.xml When the errors still appear then you are in trouble and the database is inconsistent. In that case some records in the object table don't match records in other tables. It could also be that the insrel table has numbers in the snumber and dnumber field which don't exist anymore in the object table. Bico Arjen Roodselaar wrote: Nico, Thanks for your input! On Wednesday 15 March 2006 13:28, Nico Klasens wrote: let me guess. You have upgraded or started using mysql 4.1. This version returns an optimized resultset which filters out duplicate nodes. We're currently using MySQL 4.0.18. The test/staging and production databases are currently running on the same MySQL server. The only difference between the test/staging and production environment is the Didactor version. A developer did mention however that they did something with the storage layer and since this particular database has been running (and migrated) for quite some time now it could be we're currently looking at plain old database inconsistency. Could you please explain, from a developer perspective, what piece of the code is triggering this error so I can have one of our developers look into this? The one question remaining is: how serious is this error? What happens when this piece of software is put in production without fixing what's causing this error? Or you are missing the typerel for allowed relation learnblocks-pos2rel-images or the application does a call for relatednodes which is not possible in the current model. First case is configuration. Second case is code This could be the missing typerel. I'll have a look at this. Thanks again! Arjen ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers ___ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
