Re: [Hibernate] JCL classloading headache
Max, Its not noteworthy, but keep an eye on it. A plug-in with a buddy policy will look in its buddies whenever it can't find a class by normal means. Its not bad until the plug-in has lots of buddies and needs to find lots of classes through the buddy policy. I don't have a quantitive response, sorry. John Max Rydahl Andersen wrote: thanks - i saw it earlier today. good stuff...wish it were easier. I noticed you mentioned performance issues with buddy classloading - is it noteworthy/bad? I wrote about logger plugins with SLF4J, and submitted it to EclipseZone. It was just posted today. I hope its useful to you. http://www.eclipsezone.com/eclipse/forums/t55300.html John --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Provision of source-only downloads for releases
Barry, Hibernate provides a source only distribution, accessible via CVS (not FTP or HTTP). See: http://www.hibernate.org/6.html John Barry Hawkins wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hibernate Dev Team, Thanks for this wonderful tool. Apologies in advance if this topic has been discussed and I have missed it, but would it be feasible to have a source-only download for Hibernate releases starting with 3.1? Have there been logistical issues in the past which have prevented this? This is very desirable for the Linux distributions packaging Hibernate. Regards, - -- Barry Hawkins All Things Computed site: www.alltc.com weblog: www.yepthatsme.com Registered Linux User #368650 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfjkhHuKcDICy0QoRAm0HAJ4+eba1z8wzqxjsjw2wxJham5rm2gCgw3vU EbW0oIeDMl2UItt7aBjNmVs= =fsJp -END PGP SIGNATURE- --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] JCL classloading headache
Max, Sorry for the delay. Attached are the manifest files. The attachment is a zip file disguised. SourceForge bounces mail that has extension '.zip', so I used a different extension. John Max Rydahl Andersen wrote: yes, this is the right forum since im interested in this for the eclipse plugins. would be good if you could send the manifest.mf so i can relate it to the text. thanks. /max I can send the MANIFEST.MF file for each of the code library plugins I've created. Is this the right forum? John mf.piz Description: Binary data
Re: [Hibernate] JCL classloading headache
Max, 1: Centralize all logging configuration to a single file: jdk1.4 logging: By default, jdk logging finds config file in jre/lib directory, but this doesn't put control of the configuration into the rcp provider unless the provider is also delivering a full jre. Better to set the java.utils.logging.config.file property. log4j: By default, log4j will find the config file 'log4j.properties' in the classpath. Relying on this in Eclipse is possible (you can use eclipse classloading buddy policy), but is non-deterministic because you can't predict which pluguin Eclipse will find the file. Better to set the command line property: log4j.configuration. At productization time, command line properties for your rcp product are set in the launching arguments section of the configuration page in the product editor. During plugin development and testing, you can set command line properties in the VM arguments text panel your plugin's Run configuration. Find the Run configuration by selecting Run... from the Run workbench menu. 2: Appender in hibernate plugin can be found by the log4j plugin: Assuming there is a log4j plugin. The log4j plugin must have a Buddy Policy that will make visible appenders contributed by other plugins. I choose 'registered': Eclipse-BuddyPolicy: registered in its Manifest.MF file. Then, any plugin that has an appender would register as a buddy with the log4j plugin with Eclipse-BuddyRegister: org.apache.log4j This assumes the log4j plugin is named org.apache.log4j. This is a good assumption because McAffer's book promotes the convention that a code library plugin is named for the java package within. In reality, there isn't an eclipse log4j plugin. McAffer's book suggests this would be a job for Apache logging project. 3: How to swap among logging frameworks: log4j, jdk1.4, SimpleLog, nlog4j Assume there are code library plugins for slf4j, one plugin for each framework that slf4j supports. For example, org.slf4j.log4j is a plugin that contains interface code to log4j, org.slf4j.jdk14 contains interface code for jdk logging api. Also, each of these plugins contains a copy of slf4j's commons-logging implementation. All of these plugins export the org.apache.commons.logging packages and the org.slf4j packages. Your plugin that invokes the logging api must import the logging api. Use 'import' not 'required' to declare to eclipse your plugin's dependencies. 'Required' means your plugin depends on a specific plugin by name; 'import' means your plugin depends on any resolved, enabled plugin that exports the named packages. In the dependencies page of your plugin's manifest editor, put the logging api packages in the 'import' panel: org.apache.commons.logging, org.apache.commons.logging.impl, org.slf4j, org.slf4j.impl, org.slf4j.spi. I hope you have setup a plugin development target. It isolates your development bed from your eclipse installation plugins. Load the log4j plugin and the org.slf4j.log4j plugin into your target. To swap from one framework to the other, say from log4j to jdk logging, load and enable the org.slf4j.jdk14 plugin into your target, and disable the org.slf4j.log4j plugin you have been using. I think the swap capability is cool but not something an rcp end user would be interested in taking advantage of. For a developer of a code library plugin, like hibernate or its dependencies, this capability means that the rcp developers which use your plugins won't be tied to log4j. I also think this capability is useful for hibernate, like for swapping multiple cache implementation plugins, but I don't know enough about the cache api and am guessing. Sidebar: Creating a code library plugin is very easy and takes only a few minutes. Create a new project - plugin development - plugin from existing jar files, select the jar files to be included, modify the manifest (imports, exports), and thats it. Wouldn't it be nice if providers of code libraries did this for you? I can send the MANIFEST.MF file for each of the code library plugins I've created. Is this the right forum? John Max Rydahl Andersen wrote: I also found solutions to some other issues like: how to centralize all logging configuration to a single file, and how an appender in hibernate plugin can be found by the log4j plugin, and how to swap to a different slf4j implementation library so jdk logging, nlog4j or simple log I'm willing to share the details if you are interested. I'm definitly interested. /max John Max Rydahl Andersen wrote: yes, i also find slf4j interesting, but afaik it won't help solve the logging problem while other components i use uses common logging. And it will also still have issues with duplicate configuration etc., but im not sure. /max Hi. When developing eclipse plugins, I ended up with
Re: [Hibernate] JCL classloading headache
Max, Alexandre, Also available from slf4j is the common logging layer implemented atop slf4j layer. This will support both APIs at the same time for a smooth transition from commons logging to slf4j. Eclipse class finding algorithm will find classes imported to a plugin before it finds the classes 'local' to the plugin. This means that if you name org.apache.log4j packages in your plugin's imports and enable a plugin in your target which exports org.apache packages, then eclipse class finder will find the classes from the log4j plugin. Don't export the org.apache.log4j packages from more than one plugin in your target, eclipse will choose at random. See chapter on OSGi classloading in McAffers RCP book for documentation of the class finding algorithm. By the way: I prototyped the following: 1) a log4j plugin containing the apache log4j implementation 2) an slf4j for log4j plugin containing slf4j library and its common logging layer libary. 3) my own custom hibernate plugin minus logging implementation. 4) my rcp plugin that used hibernate and slf4j logging. This works great. Just so you know: I am not a member of any of the above software teams. But plan to feed this back. to log4j, slf4j and hibernate. I also found solutions to some other issues like: how to centralize all logging configuration to a single file, and how an appender in hibernate plugin can be found by the log4j plugin, and how to swap to a different slf4j implementation library so jdk logging, nlog4j or simple log I'm willing to share the details if you are interested. John Max Rydahl Andersen wrote: yes, i also find slf4j interesting, but afaik it won't help solve the logging problem while other components i use uses common logging. And it will also still have issues with duplicate configuration etc., but im not sure. /max Hi. When developing eclipse plugins, I ended up with a severe limitation when a plugins makes reference to the apache-commons-logging library AND each other. Well, digging around I found the slf4j library (http://www.slf4j.org/) that seems to solve my problem. The cenario where the problem arose was eclipse, where my plugin may reference or not hibernate's plugin, and both had apache log. Each plugin MAY exist without the other, so each one must have logging, but when they are both used, we got classloading problems. I'm testing this new library now in the java.tri plugin. It may be usefull to the hibernate-tools. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] autobuild is runnable but fails
Max, and all, I've got the autobuild running to a very minimal level. Its properly configured, it checks-out source and tries to generate build.xml scripts in each plugin. Unfortunately, at the time I was running this, there are failures when it tries to generate build.xml scripts for each plugin. I would have gone farther, but I'm requesting some checkins to the extenstions cvs tree. Once these are in then I'll go back in and write the prebuild callouts that would copy needed libraries into org.hibernate.eclise/lib. The following problems with the source at HEAD of cvs tree were verified using the eclipse ui and then corrected in my local copy. For each affected file, I put the revision that was HEAD during the time I was truing to get this to work (week of 10 April). Should I put these in JIRA? 1) in org.hibernate.eclipse: META-INF/MANIFEST.MF (cvs r 1.1) names packages that are not present in jar files copied in by 'hibernate-build.xml update': org.hibernate.tool.cfg2hbm, org.hibernate.tool.test.jdbc2cfg, org.objectweb.asm, persistentclasses. Removing these from the file resolves this build problem, and pushes the issue to runtime. 2) In org.hibernate.ecplise.console: plugin.xml (cvs r 1.11) does not have id, version, and name attributes. Restoring values from r 1.10 resolves this build problem. Also, plugin.xml does not have any dependencies. Restoring dependency list from r 1.10 resolves this build problem. In addtion to r1.10, these plugins are new dependencies: org.eclipse.ui.editors, org.eclipse.jdt.ui. 3) In org.hibernate.eclipse.console.test: plugin.xml (cvs r1.2) does not have id, version and name. Restoring values from r1.1 resolves this build problem. Also, plugin.xml has no dependencies. Adding org.junit resolves build problem. 4) org.hibernate.eclipse.mapper: I found this tree was moving underneath me on 15-april, so I stopped trying to make it work. But, the plugin.xml is incomplete: it also lacks that id, version and name attributes. As a matter of status: I tried to patch these locally and continue the build process. but the PDE Build was unable to resolve a plugin in wst 1.0M3 (needed by hibernate's mapper plugin). It complained of a corrupt file in the wst plugin. I have not yet isolated the problem, but since you are upgrading to M4 soon, and the HEAD in mapper on 15-april indicate dependency on M4, I'll move up to M4 too. John --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] autobuild is runnable but fails
Max, I've posted jira HBX-228. The root cause of some of my trouble is: confusion and ignorance, but that's not to say all the trouble is gone. If you could just take a look at the patch files in the jira issue and resolve, then I'll be happier. Sorry for the confusion. John Max Rydahl Andersen wrote: On Fri, 15 Apr 2005 21:25:03 +0200, John Franey [EMAIL PROTECTED] wrote: Max, and all, I've got the autobuild running to a very minimal level. Nice affected file, I put the revision that was HEAD during the time I was truing to get this to work (week of 10 April). Should I put these in JIRA? Yes please. Add them as *patches*, not just complete files as otherwise I have no good chance of detecting what the changes are. 1) in org.hibernate.eclipse: META-INF/MANIFEST.MF (cvs r 1.1) names packages that are not present in jar files copied in by 'hibernate-build.xml update': org.hibernate.tool.cfg2hbm, org.hibernate.tool.test.jdbc2cfg, org.objectweb.asm, persistentclasses. Removing these from the file resolves this build problem, and pushes the issue to runtime. hmm - ok these should not but needed, except org.objectweb.asm which sounds reasonable. 2) In org.hibernate.ecplise.console: plugin.xml (cvs r 1.11) does not have id, version, and name attributes. Restoring values from r 1.10 resolves this build problem. Also, plugin.xml does not have any dependencies. Restoring dependency list from r 1.10 resolves this build problem. In addtion to r1.10, these plugins are new dependencies: org.eclipse.ui.editors, org.eclipse.jdt.ui. It looks like you are using 3.1M5 and not 3.1M6 ? These changes were done do comply with the new improvements in the M6 runtime engine. 4) org.hibernate.eclipse.mapper: I found this tree was moving underneath me on 15-april, so I stopped trying to make it work. But, the plugin.xml is incomplete: it also lacks that id, version and name attributes. Hmm...again need to see that patch to truly follow this. As a matter of status: I tried to patch these locally and continue the build process. but the PDE Build was unable to resolve a plugin in wst 1.0M3 (needed by hibernate's mapper plugin). It complained of a corrupt file in the wst plugin. I have not yet isolated the problem, but since you are upgrading to M4 soon, and the HEAD in mapper on 15-april indicate dependency on M4, I'll move up to M4 too. yes - please just use a recent I-build from WTP and it should work now. -max John --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] plugin builds: what dependencies
Max, and all: What plugins and builds does the head of the plugin cvs tree depend on? I know that it now depends on wst: what build? Anything else? Thanks, John --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] automated plugin build script
Max, and all,
I don't know what is in place or planned for automating plugin builds.
I searched this mailing list archive and found discussions in Jan 2005,
and Dec 2004 regarding builds of plugins and source directory structure,
but neither of these addressed an automated mechanism. This email is a
contribution. I hope its helpful at this stage. Attached is a
prototype build file to show a possibility and I can continue if it fits
into your plans.
Here are goals of the hibernate plugin build script:
- builds all plugins from one command: ant -f plugin-build.xml target
- deposits zipped binary and source of plugins into a drop directory.
- supports build directly after 'cvs checkout' of the plugins, but
after other libs in Ext are built.
- simplify directions on the plugin contribution howto by providing
additional build targets (to be identified).
- will copy resources into a plugin before building (leverages
org.hibernate.eclipse/hibernate-build.xml update target.)
- synchronize with the plugin build environment used by developer in
PDE session. In other words, if a new library is added into the
plugin's build path by a plugin developer using the eclipse PDE, the new
dependency should be picked up without further manual intervenetion
(like adding a jar file to an ant property).
According to Clayberg and Rubel (in Eclipse: Building Commercial
Quality Plug-ins, Addison-Wesley), there are two cool mechanisms in
eclipse that helps: 1) the PDE can generate a build.xml, and 2) the
generated build.xml can be run 'headless' (without the user interface).
Here is proposed files and structure:
HibernateExt
plugin-build.xml
org.hibernate.eclipse.* (for each plugin)
build.xml (eclipse generated file)
hibernate-build.xml (provided by plugin developer)
Attached is a the initial prototype of plugin-build.xml. There is more
to do; this is a proof-of-concept demo. It can build
org.hibernate.eclipse zip files if org.hibernate.eclipse/build.xml was
generated by developer in eclipse PDE, and if you have 3.1M6 installed
(Headless build in 3.1M5a didn't work). Modify the eclipse.home and
workspace properties in plugin-build.xml. Run in HibernateExt as:
ant -f plugin-build.xml zip.plugin
By convention, each plugin's hibernate-build.xml would have well-known
public targets for the plugin-build.xml to run: 'pre-build', and others
as needed. In org.hibernate.eclipse/hibernate-build.xml, the target
pre-build would antcall 'update'. A set of properties would be made
available to hibernate-build.xml (to be defined).
To generate a build.xml by hand: in eclipse, right click on the
plugin.xml in the plugin's project and select PDE Tools Create Ant
Build File. I expect there is a way to generate this file headless,
and I will look for it. If so, then generating the build.xml file per
plugin would be part of the automatic build, and PDE developer wouldn't
have to remember to generate it manually, and it wouldn't be in cvs.
I'm on the lookout for examples. I looked into the PDE plugin source
code, but not enough to assure myself it can be reused; I spent only
enough time to realize that I need to spend much more time on it :-).
If anyone can assure me that this or some other plugin build scripts can
be reused here, I'll pursue it.
Comments?
John
?xml version=1.0 encoding=UTF-8?
project name=plugins
property name=eclipse.home location=/opt/eclipse-3.1-M6/
!-- use an absolute path, the workspace directory will be created if non-existent --
property name=workspace location=/usr/tmp/eclipse-build-workspace/
!--
- if you don't want eclipse output set value to
- if you do want eclipse output, set value to -consolelog
--
property name=eclipse.console.flag value=/
target name=eclipse-launcher description=Invoke a 'headless' eclipse
java classname=org.eclipse.core.launcher.Main fork=true dir=${work.dir}
classpath
pathelement location=${eclipse.home}/startup.jar/
/classpath
arg line=-data ${workspace} /
arg line=-application ${application}/
arg line=${eclipse.console.flag}/
arg line=${application.args} /
/java
/target
target name=ant-runner description=Invoke an ant build within 'headless' eclipse
antcall target=eclipse-launcher
param name=application value=org.eclipse.ant.core.antRunner /
param name=application.args value=-buildfile ${buildfile} ${targets} /
param name=work.dir value=${plugin.name}/
/antcall
/target
target name=zip.plugin description=run 'zip.plugin' target in a plugin's build.xml
antcall target=ant-runner
param name=buildfile value=build.xml/
param name=targets value=zip.plugin/
param name=plugin.name value=org.hibernate.eclipse/
/antcall
/target
/project
