Main | January 2006 »

December 28, 2005

Road-coder's haven: the Apollo Café in Milwaukee

It is not often that I will write a rave review of a Café, but the Apollo in Milwaukee (1310 E Brady St, across from Rochambo) is like a dream come true, especially for a road-coder like myself, away from home over a holiday.

Excellent dining meets good, honest, black coffee (and plenty of it) in a clean, smoke-free, well managed and unobtrusive atmosphere. I highly recommend the food, the prices are excellent, and the entire experience lends itself to study and especially to software development.

I found several electrical outlets, and was able to piggyback on the Rochambo coffee shop's wireless network (password protected, you might want to stop in and make a purchase, get the password and relocate across the street for a smoke-free afternoon.) I have been more impressed with this little gem than with any other Café in Milwaukee, including Rochambo and Anodyne, both of which came highly recommended but left much to be desired. I will definitely look forward to stopping into the Apollo during my next visit to Milwaukee.

December 26, 2005

UPDATE: AbstractMethodError: org.jpox.PersistenceManagerImpl.makePersistent jpox-2.0-beta-5

Andy Jefferson helped me resolve the problem I reported in http://www.jpox.org/servlet/forum/viewthread?thread=2959&lastpage=yes

It seems that the JDO 2.0 snapshot7 is the correct JDO snapshot, not snapshot8, which is what I was using when I wrote this. Andy is gruff in his responses, but I should have noted the dependency on the download page. He means well and he's certainly prompt. Hats off to Andy, then.


December 25, 2005

AbstractMethodError: org.jpox.PersistenceManagerImpl.makePersistent jpox-2.0-beta-5

Received the following error when using maven with jpox-2.0-beta-5

java.lang.AbstractMethodError: 
        org.jpox.PersistenceManagerImpl.makePersistent
            (Ljava/lang/Object;)Ljava/lang/Object;
	at ...
	at sun.reflect.NativeMethodAccessorImpl.
            invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.
            invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.
            invoke(DelegatingMethodAccessorImpl.java:25)

I have not yet solved this problem, but it seems as though my persistence manager is not able to store my items. It's a shame the error message is not more descriptive, because now I have to go read the code for JPOX. I'll report more when I know the solution. I had to hack together a maven plugin for JPOX 2.0 beta 5 this morning, and that seems to be working very well, except I'm getting this strange error.

See Also:

http://www.jpox.org/servlet/forum/viewthread?thread=2959&lastpage=yes

music: "spread your love", brmc

December 21, 2005

Autoretrieval of 1-1 bidirectional single foreign key fields using Fetch Plans or the Default Fetch Group

While using JPOX for autoretrieval of 1-1 bidirectional single foreign key fields using Fetch Plans or the Default Fetch Group, I get the following error:

Here's the error message:

Testcase: testIPM(org.eremite.*.*): Caused an ERROR
JPOX doesn't yet support having 1-1 bidirectional 
single-FK fields being retrieved in the DFG/FetchPlan
javax.jdo.JDOUserException: JPOX doesn't yet 
support having 1-1 bidirectional single-FK fields 
being retrieved in the DFG/FetchPlan

at org.jpox.store.mapping.Mappings.
selectMapping(Mappings.java:119)
at org.jpox.store.rdbms.scostore.AbstractSetStore.
newResultObjectFactory(AbstractSetStore.java:1067)
at org.jpox.store.rdbms.scostore.AbstractSetStore.
iterator(AbstractSetStore.java:250)
at org.jpox.sco.Collection.
loadFromStore(Collection.java:688)
at org.jpox.sco.Collection.
iterator(Collection.java:454)
at org.jpox.sco.Collection.
detachCopy(Collection.java:234)
at org.jpox.state.DetachFieldManager.
fetchObjectField(DetachFieldManager.java:62)
at org.jpox.state.StateManagerImpl.
replacingObjectField(StateManagerImpl.java:2500)
at org.eremite.*.*.*.jdoReplaceField(*.java)
...

Apparently, JPOX doesn't support this functionality yet. I'm using the 1.1.0-Beta-03 release, and this might have been implemented since then. The latest release was Beta-05, which I'll try before I go any further on this. When I'm done, I'll have to write some information on using Fetch groups and Fetch plans in persistence management. Systematically walking through your object trees and detaching fields is not something you should have to do, and JDO 2.0 provides utilities around it in the Spec.

In trying to resolve this problem, I decided to attempt to upgrade to jpox-2.0-beta-5, which does not have a maven plugin. So, I upgraded the beta-3 plugin, and I've got different problems now. I'm still not certain that making the leap to 2.0-beta-5 was wise.

music: bach, "Gleich wie der Regen und Schnee vom Himmel fällt"

December 12, 2005

JPOX MetaDataForPersistenceCapableClassNotReachableException

Here's a solution I found for a strange error in JPOX. While working with JPOX, Clover, JUnit and Maven, I kept getting the following:

Testcase: testIdeaPersistenceManager(org.eremite.triune.hypernym.IdeaTest):	
Caused an ERROR
The class "org.eremite.triune.hypernym.Idea" is required to be 
  Persistence-Capable yet no Meta-Data can be found for this class. 
  Please check that the Meta-Data is defined in a valid file 
  location for JDO.
org.jpox.exceptions.MetaDataForPersistenceCapableClassNotReachableException: 
  The class "org.eremite.triune.hypernym.Idea" is required to 
  be Persistence-Capable yet no Meta-Data can be found for this 
  class. Please check that the Meta-Data is defined in a valid 
  file location for JDO.
	at org.jpox.AbstractPersistenceManager.
	  assertPersistenceCapable(AbstractPersistenceManager.java:414)
	at org.jpox.AbstractPersistenceManager.
	  internalMakePersistent(AbstractPersistenceManager.java:897)
	at org.jpox.AbstractPersistenceManager.
	  makePersistent(AbstractPersistenceManager.java:995)
	at org.eremite.triune.persistence.IdeaPersistenceManager.
	  storeIdea(IdeaPersistenceManager.java:34)
	at org.eremite.triune.hypernym.IdeaTest.
	  testIdeaPersistenceManager(IdeaTest.java:85)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.
	  invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.
	  invoke(DelegatingMethodAccessorImpl.java:25)

However, I was not getting the same error when just using JPOX, Maven and JUnit. The tests were only breaking with Clover. The trick is that the package.jdo files were not being copied to the target/clover/classes/ directory. I was copying them in a <postGoal> element for java:compile in my maven.xml, but I was not doing the same in a <preGoal> element for clover:test. So, adding the following block to my maven.xml completely resolved the problem:

  <!-- Perform enhance directly after compilation -->
  <preGoal name="clover:test">
      <copy todir="${basedir}/target/clover/classes/">
          <fileset dir="${basedir}/src/java">
              <include name="**/*.jdo"/>
          </fileset>
      </copy>
      <attainGoal name="jpox:enhance"/>
  </preGoal>

Hope this helps someone.

December 01, 2005

Relations between contractions of Idea

One of the several ways in which physical (textual) artifacts of an idea are distinct from those of a perception is that noncontracted ideas relate to one another in a continuous manner, whereas noncontracted perceptions do not relate to one another. Idea is in this sense a manifold of continuous action, whereas perception is a discrete manifold of existing or not-existing. One perception, for instance, does not permit or lead to another perception. If one needs proof, one can just flip on the television and channel surf. The series of images you perceive while flipping from channel to channel do not cause each other to exist.

Idea, however, is the mental process of apperception or hypothesis, by which we come to understand the universal meaning that corresponds to those objects of our sense perceptions. While a perception merely is, idea becomes, in a continuous process. The discrete "snapshots" of this continuous process are manifold, but exist in definite relation to each other in a progression of evolving mental action. The continuity of idea necessitates, then, the existence of relationships between instances of itself when it is contracted to a discrete manifold. This distinction is further elucidated in the Parmenides dialogue.

Whether the relationships between contractions of a given idea are causal, modal, or temporal, is the subject of my present investigation. Does the process of idea flow like a pebble flows along currents of gravity toward the earth? Can multiple ideas come together in a higher idea to form a continuous action of a higher order, such as planetary orbit? The answer to both of these questions appears to be yes. Is this in fact a "coming together", or are the two ideas products, projections or contractions of the higher idea? In which direction does order flow? The cognitive process of discovery appears to be able to travel in either direction.

As such, any electromechanical system which aims to contract the continuous relationships that exist between discrete states of an apperceptive process should permit the existence of complex or compound ideas, which are characterized as ideas of a 'higher order', or those which exist on a 'higher' manifold of action. Vis, "governing dynamics".

Of course, any system capable of storing these contracted relations must itself be a contraction of a yet higher idea. The apperception of this contraction, indicates a continuum of higher ideas. Our apperception of this continuum itself indicates a yet higher continuum of continuums. The process repeats itself, becomes fractal, and resolves itself into an analogue of Cantor's Paradise.

The views and opinions expressed in this page are strictly those of the page author. The contents of this page have not been reviewed or approved by the University of Minnesota.