You can't open the application "Microsoft Outlook.app" because it is not supported on this type of Mac

Today all of a sudden Outlook crashed on my MacBook Pro. When I try to restart it, I got "You can't open the application "Microsoft Outlook.app" because it is not supported on this type of Mac" pop up.

Rather disturbing I thought. Immediately, I started to ask around if anyone has encountered this same problem before. No luck.

Great, I thought. Time to ask Uncle Goog.

Fortunately, I found this link.  Particularly the part that said:

Update using the Microsoft Autoupdater (MAU):

• Open any Office application and select "Check for Updates" under Help in the Menu bar. Once MAU is launched, select "Keep in Dock"
• Log out/in as described above.
• Select the MAU in the Dock and download the updater.
• After it downloads, quit the MAU then install.
• RESTART

In my case it's a bit simpler:

• Open any Office application and select "Check for Updates" under Help in the Menu bar.
• Once MAU is launched, click "Check fir updates"
• In my case, I happen to find updates I can apply to Office. Follow the instructions to apply the updates.
• My Outlook icon on the Dock which previously doesn't look healthy, now looks good again. I clicked it and it works as expected.

Your mileage may vary.

Eclipse Juno "Updating Maven Project" error

During my current project, quite often I'll see a red X on my maven project top level on eclipse Juno when something changed. When that appeared, I'll do a right click and select "Maven -> Update Project." That fixed the issue. But before it did, I'll see an error message popped-up with the following message:

An internal error occurred during: "Updating Maven Project". Unsupported IClasspathEntry kind=4

So I looked to see if there's a "common cure" for this and found:

http://stackoverflow.com/questions/11832647/an-internal-error-occurred-during-updating-maven-project

Essentially the proposed fix is (Adjusted for Juno with m2e plugin):

1. Right-click on the project, select Maven -> Disable Maven Nature.
2. Open a terminal window, go to your project folder and run "mvn eclipse:clean"
3. Right click on the Project and select “Configure -> Convert to Maven Project”

I'll have to see in a few cycles, if this will fix the original issues that caused the first red X mark to appear in the first place.

MongoDB "norepl" Exception

I was using MongoDB 2.0.4 (mongodb-win32-x86_64-2.0.4) with spring-data-mongodb-1.0.1-RELEASE and spring-framework-3.1.1-RELEASE to do a data insert.

The insert method was as follows:

 public static final String FOO_COLLECTION = "foos";

 @Autowired private MongoTemplate mongoTemplate;

 public void add(Foo foo) {
  mongoTemplate.save(foo, FOO_COLLECTION);
 }

It's supposed to be simple and yet I got the following error:

org.springframework.data.mongodb.UncategorizedMongoDbException: norepl; nested exception is com.mongodb.MongoException: norepl
 at org.springframework.data.mongodb.core.MongoExceptionTranslator.translateExceptionIfPossible(MongoExceptionTranslator.java:70)
 at org.springframework.data.mongodb.core.MongoTemplate.potentiallyConvertRuntimeException(MongoTemplate.java:1538)
 at org.springframework.data.mongodb.core.MongoTemplate.execute(MongoTemplate.java:370)
 at org.springframework.data.mongodb.core.MongoTemplate.saveDBObject(MongoTemplate.java:784)
 at org.springframework.data.mongodb.core.MongoTemplate.doSave(MongoTemplate.java:720)
 at org.springframework.data.mongodb.core.MongoTemplate.save(MongoTemplate.java:707)
 ... ...
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
 at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
 at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
 at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
 at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
 at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
 at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
 at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
 at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
 at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
 at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
 at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: com.mongodb.MongoException: norepl
 at com.mongodb.CommandResult.getException(CommandResult.java:87)
 at com.mongodb.CommandResult.throwOnError(CommandResult.java:121)
 at com.mongodb.DBTCPConnector._checkWriteError(DBTCPConnector.java:131)
 at com.mongodb.DBTCPConnector.say(DBTCPConnector.java:155)
 at com.mongodb.DBTCPConnector.say(DBTCPConnector.java:138)
 at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:261)
 at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:211)
 at com.mongodb.DBCollection.insert(DBCollection.java:57)
 at com.mongodb.DBCollection.insert(DBCollection.java:87)
 at com.mongodb.DBCollection.save(DBCollection.java:728)
 at org.springframework.data.mongodb.core.MongoTemplate$11.doInCollection(MongoTemplate.java:792)
 at org.springframework.data.mongodb.core.MongoTemplate.execute(MongoTemplate.java:368)
 ... 33 more

The data got inserted into MongoDB, but the Exception still got thrown.

I look around and eventually found out that the way I define my "WriteConcern" in the mongoTemplate bean definition in applicationContext.xml caused the Exception.  It seems that anything other than the default will cause the Exception similar to above.

Here's how my mongoTemplate originally defined:

<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
        <constructor-arg name="mongoDbFactory" ref="mongoDbFactory"/>
        <constructor-arg name="mongoConverter" ref="converter" />
        <property name="writeResultChecking" value="EXCEPTION" />
        <property name="writeConcern" value="NORMAL" />
    </bean>

Here's the changes that "fixed" the Exception:

<beans ...
xmlns:util="http://www.springframework.org/schema/util"
 ...
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.0.xsd
 ... >
     <bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
        <constructor-arg name="mongoDbFactory" ref="mongoDbFactory"/>
        <constructor-arg name="mongoConverter" ref="converter" />
        <property name="writeResultChecking" value="EXCEPTION" />
        <property name="writeConcern">
          <util:constant static-field="com.mongodb.WriteConcern.NORMAL" />
        </property>
    </bean>

Apparently, changing:

<property name="writeConcern" value="SAFE">

to

<property name="writeConcern">
    <util:constant static-field="com.mongodb.WriteConcern.SAFE"></util:constant>
<property>

Seems to resolve the issue.

"Same url pattern" error on GlassFish OSE 3.1.1 deployment

When I was experimenting with JSF 2.0 deploying into GlassFish Open Source Edition 3.1.1 using MyEclipse 10, I encountered an error I can't explain, since the source code set was previously tested on eclipse indigo + tomcat 7 combination and seems to work fine.

So I went and get jsf-blank.zip from coreservlets.com JSF 2.0 Tutorial - build and deployed it to GlasshFish from eclipse. Simple project, simple test and it's now proven to work. I copied the source code into MyEclipse and deploy the project into GlassFish, and sure enough it blows again.

The short version of the error is:

Exception while deploying the app : java.lang.IllegalStateException: Servlet [xxxxx] and Servlet [yyyyy] have the same url pattern: [/zzz]at org.glassfish.apf.AnnotationInfo@f3b0e2

Here's the error log associated with the exception:

[#|2011-11-11T10:09:09.367-0800|SEVERE|glassfish3.1.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=16;_ThreadName=Thread-2;|Servlet [RegistrationRequesterPortImpl] and Servlet [RegistrationPortImpl] have the same url pattern: [/RegistrationService_V11]|#]

[#|2011-11-11T10:09:09.368-0800|SEVERE|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-2;|Exception while deploying the app [jsf-blank]|#]

[#|2011-11-11T10:09:09.368-0800|SEVERE|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-2;|Servlet [RegistrationRequesterPortImpl] and Servlet [RegistrationPortImpl] have the same url pattern: [/RegistrationService_V11]at org.glassfish.apf.AnnotationInfo@f3b0e2
java.lang.IllegalStateException: Servlet [RegistrationRequesterPortImpl] and Servlet [RegistrationPortImpl] have the same url pattern: [/RegistrationService_V11]at org.glassfish.apf.AnnotationInfo@f3b0e2
 at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:490)
 at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432)
 at com.sun.enterprise.deployment.archivist.WebArchivist.postAnnotationProcess(WebArchivist.java:358)
 at com.sun.enterprise.deployment.archivist.WebArchivist.postAnnotationProcess(WebArchivist.java:89)
 at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:409)
 at com.sun.enterprise.deployment.archivist.Archivist.openWith(Archivist.java:267)
 at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
 at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:171)
 at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
 at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:828)
 at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:770)
 at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
 at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
 at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
 at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:360)
 at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
 at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
 at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
 at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
 at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:145)
 at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:575)
 at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:461)
 at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:389)
 at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:380)
 at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:209)
 at java.util.TimerThread.mainLoop(Timer.java:512)
 at java.util.TimerThread.run(Timer.java:462)
Caused by: Servlet [RegistrationRequesterPortImpl] and Servlet [RegistrationPortImpl] have the same url pattern: [/RegistrationService_V11]at org.glassfish.apf.AnnotationInfo@f3b0e2
 at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367)
 at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375)
 at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289)
 at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:195)
 at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134)
 at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:606)
 at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:445)
 ... 26 more
Caused by: java.lang.IllegalArgumentException: Servlet [RegistrationRequesterPortImpl] and Servlet [RegistrationPortImpl] have the same url pattern: [/RegistrationService_V11]
 at com.sun.enterprise.deployment.WebBundleDescriptor.addWebComponentDescriptor(WebBundleDescriptor.java:362)
 at org.glassfish.webservices.annotation.handlers.WebServiceHandler.processAnnotation(WebServiceHandler.java:433)
 at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
 ... 32 more
|#]

Long story short, I googled for previous solutions and after a while found an answer in java.net GlassFish forum as it turns out, to resolve the issue a metadata-complete="true" attribute need to be added into web.xml web-app tag.

Here's an example:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
      http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
  version="2.5"
  metadata-complete="true">
    ...

That additional attribute seems to fix the issue, though I'm still not clear why it works OK through eclipse but not myEclipse.