Wednesday, January 18, 2017

LG Tablet Frozen on Firmware Update

I've been having a frustrating time with an LG tablet that I got from T-Mobile. The specific model that I have is the V496, also known as LG G Pad X 8.0. The steps to reproduce:

- battery drained completely, cannot be turned on because battery is at 0%
- plug in the tablet to charge
- screen displays (paraphrasing a bit): Firmware updating, do not unplug.
- screen displays a progress bar under the message and the progress bar never progresses

I am fairly certain I have figured out what was causing my issues, and perhaps maybe causing your issues. I was trying to charge from an outlet using the USB cable that came with my XBox. It never occurred to me this could be an issue until it was pointed out that the cable would not charge a Samsung phone. I think there is some extra electronic bits in the connector that is triggering the LG tablet (and possibly other LG equipment) to think it needs a firmware update.

That being said, my tablet was now stuck in an off state since it would not take a charge. To solve this part, I found my solution on this forum, which I will repeat below

  1. Unplug the tablet from the USB cable
  2. Find either a non-branded USB cable or the cable that came with the tablet. In my case, I'm pretty sure I am using the LG USB cable that came with either my LG phone or my LG tablet. Have this cable ready, i.e. one end of it should be plugged into a power source.
  3. Hold down the power button on the tablet for 10 seconds
  4. While still holding down the power, plug the tablet in and then let go of the power button
  5. You should see the outline of a large battery saying 0% for a second and the screen goes blank
  6. Leave the tablet plugged in to complete charging
Thanks for nothing Microsoft 

Friday, October 7, 2016

GWT 2.7.0 and Java 1.8

Well hello there, here's a quick post before I forget of some aggravating "errors" I encountered while trying to compile my code. We currently use GWT 2.7.0 and just upped our code to finally (stop laughing) use Java 1.8. Sounds great right?

Now, to be fair, I'm sure GWT mentions these issues in their documentation... but I'm also sure most of you haven't read through every iota of documentation and probably missed these awesome warnings.

The current warning I get when I compile my GWT module is:

[INFO] Tracing compile failure path for type 'org.eaglei.ui.gwt.search.SearchApplication'
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/SearchApplication.java'
[INFO] [ERROR] org.eaglei.ui.gwt.uiconfig.rpc.SearchUIConfigServiceRemoteAsync cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/common/SearchTopPanel.java'
[INFO] [ERROR] org.eaglei.ui.gwt.search.common.SearchBarWidget cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/SearchApplicationController.java'
[INFO] [ERROR] org.eaglei.ui.gwt.search.SearchApplicationContext cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-common-ui-gwt/4.5.0-SNAPSHOT/eagle-i-common-ui-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/uiconfig/rpc/SearchUIConfigServiceRemoteAsync.java'
[INFO] [ERROR] org.eaglei.services.uiconfig.SearchUIConfig cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/common/SearchBarWidget.java'
[INFO] [ERROR] org.eaglei.ui.gwt.search.SearchApplicationContext cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/SearchApplicationContext.java'
[INFO] [ERROR] org.eaglei.services.uiconfig.SearchUIConfig cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-common-services/4.5.0-SNAPSHOT/eagle-i-common-services-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/services/uiconfig/SearchUIConfig.java'
[INFO] [ERROR] org.eaglei.common.util.nodeinfo.NodeConfig cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-common-util/4.5.0-SNAPSHOT/eagle-i-common-util-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/common/util/nodeinfo/NodeConfig.java'
[INFO] [ERROR] Line 308: Type mismatch: cannot convert from List to List

So what the crap? I tried googling that last bit about List and only got results about people failing to use generics correctly. That's not my issue, I'm not using generics in this particular block of code.

It turns out it is because of a Java 1.8 enhancement I was using. Instead of:

List thingList = new ArrayList();

You can now omit the second type specifier:

List thingList = new ArrayList<>();

Fantastic!

Except if you use it in one of those fancy schmancy one line tertiary statements. In my code, the offending line of code was:

final List otherInstitutions = (other.getInstitutions() != null) ? other.getInstitutions() : new ArrayList<>();

By specifying the type in the tertiary statement, all was good:

final List otherInstitutions = (other.getInstitutions() != null) ? other.getInstitutions() : new ArrayList();

Yay?

Wednesday, February 19, 2014

Getting Apple Mail's Smart Mailboxes to remember Outlook Exchange folders

I've been trying to get Apple Mail's Smart Mailbox to look inside my Outlook Exchange folders for mail and for whatever reason, the Smart Mailbox doesn't seem to be able to remember the Exchange folder I selected.

For example, I have created a folder named test in my Exchange account.  I then created a Smart Mailbox named Test Mailbox to look at this folder:


After I click OK, and go to edit the Smart Mailbox again:


Ah! Where did my folder go?  I've tried googling various combinations of terms to get information, and I've come across a couple of posts on Apple's forum, but nothing that points to a solution or a workaround.

I initially started down the path of creating a Smart Mailbox with the following filters:
1) Look for Messages not in Mailbox and select Inbox
2) Build a complex filter that is the same as the rules being applied to move messages to the desired folder

It turns out I needed to build some complex filters (combinations of OR and AND) which the dialog doesn't allow for.  The dialog only gives the option of doing one or the other.  I stumbled across this post that helped me build some more complicated filters.

One thing I'd like to point out is that the folder & file name has changed since the post:

[User]/Library/Mail/V2/MailData/SyncedSmartMailboxes.plist

** CAVEAT: Please be sure you back up any of the *.plist files you are going to play with in case things go horribly awry. **

After playing around with this for awhile, I got curious as to why Apple Mail wouldn't remember my folder.  So I re-created the Smart Mailbox named Test Mailbox to look in my Exchange folder test and then I looked in the file and searched for this Smart Mailbox:


And that long garbled string is the problem. For whatever reason, the destination mailbox URL gets completely mangled.

The next thing to do is to find out what the actual destination mailbox URL is.  I happen to have rules in Mail that are applied to incoming messages which filter my email into the various folders.  This file lists these rules:

[User]/Library/Mail/V2/MailData/SyncedRules.plist

I searched this file for my Test folder and found a not garbled URL to my folder:


Copy this URL and paste it in place of that garbled string:


And ta-da!  I now have a Smart Mailbox that is looking inside my Exchange folder.

To summarize:
1) Create a rule that moves emails to the desired folder.
2) Create a Smart Mailbox, as you normally would, pointing to the desired folder and any other conditions.
3) Search the [User]/Library/Mail/V2/MailData/SyncedRules.plist file for the desired folder and look for the CopyToMailboxURL key.
4) Copy the URL under the key.
5) Search the [User]/Library/Mail/V2/MailData/SyncedSmartMailboxes.plist for the new Smart Mailbox.
6) Paste the URL over the garbled string.

Enjoy!

Thursday, December 26, 2013

Xbox One & WPA2 router

Today's post is slightly off topic.  This isn't about any programming .. but a far more important topic .. how to get your xbox one online ;-).  I have my priorities straight.

We spent about 40 minutes repeatedly trying to connect the xbox one to our WPA2 router, doing everything from restarting the console, rebooting the router, using the push button on the admin console for the router ..

The solution? Don't use the auto discovery.

It turns out when you got to network settings, choose 'Add new network' instead of selecting your network from the list.  This will allow you to specify the security, and ta-da .. you're online and can game away.

Happy holidays everyone!

Tuesday, December 10, 2013

Getting eclipse to co-operate with maven & subversion

Oh my, I didn't realize it's been over a year since my last post.  This isn't to imply at all that my past year has been without frustrations.  In fact, I have several stubs for blog posts in my evernote that I just haven't had the time to fully flesh out and put up.  I'll start with today's, since it is very self contained and I have been able to work out a few variations for documenting here.

Today's frustration has been brought to you by maven, subversion and eclipse.

I was first introduced to the notion of having to use eclipse with maven and subversion was several years ago with Eclipse Ganymede.  The sheer pain of having to configure Eclipse to play happily with maven and subversion made me very adverse to updating my Eclipse installation.  In fact, I've waited until updates to features stopped being issued and the features themselves became more or less unsupported.  Point in fact, as of Monday morning, I have been using Eclipse Helios.

Due to some quirkiness in my workspace, I finally decided to bite the bullet and upgrade to Eclipse Kepler.  I had some hiccups getting the correct incantation to have everything work well, but after I repeated the steps a few times (for documentation sake), I can actually say, it's not that painful.

So, to help myself (as well as anyone else floundering) avoid painful eclipse updates, here are the steps for the following configuration:

  • Local (my machine):
    • Eclipse Kepler Release 1 - Java EE
    • Mac OSX Mountain Lion (10.8.5)
  • Server (somewhere in the wild wild web):
    • Maven 3.0.5
    • Subversion 1.6.11
The following documentation assumes a fresh install, with no other extensions/plugins/thingamabobs installed on top of the Eclipse.  Note that in my set up, I do not touch JavaHL with a ten foot pool.  No particular reason except it causes extra confusion, pre-requisites, steps to get it to work.

Also, before we start, there are TWO different options for working with subversion.  I don't have a strong preference for either.  I'm used to Subclipse, but Subversive has prettier icons.

Without further ado, here we go.
  1. Start Eclipse
  2. Help -> Eclipse Marketplace ...
  3. Install Maven Integration
    • ~ EDIT ~
      • If you have installed the Jave EE version of Eclipse, you can skip this step.  Maven Integration is already bundled in. Continue on to step 4.
    • Type in 'Maven Integration' in the search box
    • Scroll down until you find:
      • Maven Integration for Eclipse (Juno and Newer) 1.4
      • eclipse.org, epl
    • Click 'Install'.
    • Do not finish the install yet
    • Click '< Install More'
  4. Install a Subversion solution (NB: There are two options, both are listed)
    • Type in 'Subversion' in the search box
    • Option 1: Subversive
      • Scroll down until you find:
        • Subversive - SVN Provider 1.1.1
        • eclipse.org, epl
      • Click 'Install Now'
      • Break (Go to step 5)
    • Option 2: Subclipse
      • ~ EDIT ~
        • Apparently between writing this up earlier today and now (about 6 hours), there is a new version of Subclipse available via the Marketplace.  For whatever reason, installing this new version (Subclipse 1.10.x) causes an inability to install the SCM connector.
      • Exit the Eclipse Marketplace
      • Install the solution directly:
        • Help -> Install New Software
        • Add a new software style:
          • http://subclipse.tigris.org/update_1.8.x/
      • Go to step 7.
      • Scroll down until you find:
        • Subclipse 1.8.22
        • Subclipse Project, epl
      • Click 'Install Now'
      • Break (Go to step 5)
  5. You will now see screen with a list of all of the items that will be installed for the selected solutions.  
  6. If you are using Option 1: Subversive, there are no additional steps.  All the features should be selected for the two solutions.
  7. If you are using Option 2: Subclipse, you will need to perform an additional step to avoid future headaches.


    • Expand the Subclipse folder
      • Uncheck 'Subversion JavaHL Native Library Adapter'
    • Expand the SCNKit folder
      • Ensure that 'SVNKit Client Adapter' is checked
  1. You will now be prompted to restart eclipse, restart eclipse.


  1. Welcome back! Switch to the 'Java' perspective.  
    • If you don't have the 'Java' perspective as an option, do this:
      • Window -> Open Perspective -> Other... -> Java


  1. Select the 'Package Explorer' view.
    • If you don't have the 'Package Explorer' view, do this:
      • Window -> Show View -> Other... -> Package Explorer
  2. Right click in the empty area and select 'Import'
  3. Filter the import source for 'Maven'
    • Select 'Check out Maven Projects from SCM'
    • Click 'Next >'

  1. Select the m2e Marketplace link
    • NB: This is not the same marketplace as the eclipse marketplace

  1. Scroll down until you see the section 'm2e Team providers'.
    • If you are using Option 1: Subversive (from step 4), select the option that has been highlighted in blue.
      • m2e-subversive
    • If you are using Option 2: Subclipse (from step 4), select the option that has been highlighted in pink.
      • m2e-subclipse
  2. Click 'Finish' and follow the prompts to complete installation. You will be prompted to restart eclipse again, so restart eclipse.
  3. C'est Fin!
You should now be able to check out maven projects from your svn repository.  Enjoy!

    Thursday, November 15, 2012

    Debugging GWT using eclipse and tomcat

    Everything I've heard and read online indicated that setting up my eclipse to debug the client side portions of a GWT app is super easy ... so of course I end up flailing around helplessly into the wee hours trying to debug a supposedly simple client side bug.  My process up to this point has been to insert a crazy amount of ridiculous log statements into the code, compile, deploy, repeat.  I know that this is messy and sloppy, but I was adamantly against using the GWT debugger because of a prior attempt to get it going a year and half ago that turned into a huge time-suck and frustrations.  After having spent an exceedingly long night trying to debug something a few months ago that ended up taking as long as it did because of the multiple repetitions of inserting log statements, compile, deploy, repeat, I conceded that I had to get the GWT debugger working.

    First off, I am deploying the application in a local tomcat, so I need to be able to debug what eclipse considers an external server ( as opposed to having eclipse / gwt spin up a server within eclipse ).  A quick google search for the keywords of interest brings up as the first result a very helpful stackoverflow answer:


    1. Get google plugin for eclipse
    2. The in eclipse, right click on your project and choose Debug as -> Web Application (running on external server)
    3. Enter URL of your web app on tomcat (like http://localhost:8080/YourApp/YourApp.html and eclipse will give you new one - it will add stuff like ?gwt.codesvr=127.0.0.1:9997

    Simple, right?  Sadly step 2 did nothing for me.  I select it, and nothing happens.  So what I ended up doing was to set up my own debug configurations.  When I did this, I kept getting this annoying error:


    Working directory does not exist: /Users/myStuff/Documents/workspace/myProject-TRUNK/webapp/helloWorld/target/helloWorld-webapp-1.7-MS2.01-SNAPSHOT


    I thought that perhaps this may have been related to the fact that we use maven and maybe that was throwing another complication into the mix.  As it turns out, if you don't provide a location of the deployed war to the configurations, GWT tries to access what it thinks the location.  The directory does in fact not exist, nor is it where my deployed war lives.  After some random clicking around and setting the directory to different places that may make sense, I figured out what it was looking for.  So, in summary, this is another way to get the GWT debugger to work by manually configuring things:

    1. In eclipse, right click on your project and choose Debug as -> Debug Configurations ...
    2. In the left hand panel, scroll down to "Web Application", select it and then click new.
    3. Click on the New_configuration to edit it
    4. In the Main tab, change the name of the configuration to something meaningful to you so you know what this configuration is for.  The project should be pre-filled with the name of the GWT app that you right clicked over. If it isn't, or it is not correct, click on the browse button to select the project.  This was a slight point of confusion for me, what project should I use? The code base I work on is very large with many modules. I chose the entry point into the application for the client as the GWT project ( and I chose correctly it seems ). I didn't know what main class to use or read up on what my options were, so I just left the default value.
    5. Now go to the Server tab.  Because I am running tomcat locally on my machine, I do not want to use the embedded server, so uncheck this option.
    6. Now go to the GWT tab.  Type in the name of the URL you would use in a browser to access your application. If you don't see the URL field, you probably forgot to uncheck the use embedded server in the previous step.  In my case, my application is running on https and the url needs to reflect this.  Additionally, note that the class that has your entry point should show up here.
    7. Now go to the Arguments tab.  Here's where I ended up flailing for a bit.  At the beginning of the program arguments, add the following:
      -war /opt/tomcat6/webapps/helloWorld/
      You should use the fully qualified path to the your deployed application folder (not the *.war file)
    8. Finally, you should probably add all the source for your project if you want to step through the debugger to the Source tab.
    And that's it!  When you click on debug, you should see a tab on your screen where your console is that says "Development Mode".  One other probably obvious thing is that you want to start up tomcat first before clicking debug.  After this, you'll see in the Development Mode console a URL you can copy and paste into a browser and use for debugging the client side.

    Yes, I know, this should be simple and straight forward, but I figured if I was having trouble ... I'm sure (hopefully) someone out there on the interwebs is having similar troubles.

    Tuesday, March 20, 2012

    The quest for the upgrade continues ...

    After my last post, I was confident that things would go smoothly, having assumed that those were the most deceptive issues I would encounter.  Sadly, that was not at all the case.  Upon doing a mvn install on the command line, I got this error:
    (Listing 1)
    |Loading Grails 2.0.1
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 7.298s
    [INFO] Finished at: Sat Mar 17 19:22:13 EDT 2012
    [INFO] Final Memory: 20M/81M
    [INFO] ------------------------------------------------------------------------
    [ERROR] Failed to execute goal org.grails:grails-maven-plugin:2.0.1:exec (default-cli) on project caffiendFrog-webapp-service: Unable to start Grails: java.lang.reflect.InvocationTargetException: Provider for javax.xml.parsers.SAXParserFactory cannot be found -> [Help 1]
    [ERROR] 
    [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR] 
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
    

    A quick google search for the error, in various combinations of keywords, didn't produce anything that helped.  I turned to the footnote in the error, which suggests an article that may help.  It basically says that there is something wrong with your pom.xml file, specifically some configuration is done correctly or something else is wrong.  It's a rather general article, but it did help in that I was able to focus my efforts digging through my pom.xml.

    Here are some red-herrings (i.e. false leads) that I tried:

    • The message mentions something about my grails-maven-plugin, so I spent a lot of time commenting out various bits of it.  
    • Tried a mvn clean install and got a similar message, only instead of (default-cli), I got (default clean).
    • And many more combinations of commenting things and searching for the plugin's information online to see if my configurations were incorrect.
    As a last ditch effort, I created 2 dummy test applications, using the grails instructions for creating a maven-ized project, to take a look at their poms.  Up until now, I had assumed that most of the stuff in my pom.xml was stuff we had intentionally put in there (keep in mind as I said, it's been awhile and I can't remember what we added and what grails put in for us).  So I created a blank project using Grails version 1.3.7 and a blank project using Grails 2.0.1.   And lo and behold ... the poms are very different indeed:
    Given the vast difference, what I did next was:
    1. Compare our original (v1.3.7) pom.xml to the generated one above.
    2. Noted the differences between them, these difference would be items that we had put in.
      • i.e. We added an additional exclusion to the dependencies from org.grails:
      • (Listing 2)
        
           jcl-over-slf4j
           org.slf4j
         
      • i.e.We had an additional dependency in our original file:
      • (Listing 3)
        
         org.slf4j
         jcl-over-slf4j
         ${slf4j-version}
        
        
      • i.e. We had a "hack" in place to synchronize the app.version in Grail's application.properties file with the version in our POM. See MAVEN-79 and MAVEN-128, as well as an additional execution in our configuration of the grails-maven-plugin:
      • (Listing 4)
        
         org.grails
         grails-maven-plugin
         ${grails-version}
         true
         
          
          
           sync-versions
           validate
           
            set-version
           
          
          
          
           grails-clean
           clean
           
            set-version
            clean
           
          
          
         
         
    3. Changed the pom.xml to look like the v2.0.1 (i.e. the dependencies, plugins, repos, etc.)
    4. Inserted the differences into the new pom.xml.
      • i.e. Inserting the additional exclusion from Listing 2, note that in the v2.0.1 pom.xml, there is only one dependency to org.grails and it contains none of the exclusions that were listed in v1.3.7:
      • (Listing 2a)
        
         
         org.grails
         grails-dependencies
         ${grails-version}
         pom
          
          
           jcl-over-slf4j
           org.slf4j
          
          
        
        
      • i.e. Added in our additional dependency:
      • (Listing 3a)
        
         
         org.slf4j
         jcl-over-slf4j
         ${slf4j-version}
        
        
      • i.e. Upon further investigation, the tickets have been resolved and the hack is no longer needed. Inserted the additional execution into our new plugin definition:
      • (Listing 4a)
        
         org.grails
         grails-maven-plugin
         ${grails-version}
         true
         
          
          
           grails-clean
           clean
           
            set-version
            clean
           
          
          
         
        
        
    You get the idea.

    Some other things to note:

    • The plugin JAXRS & Hibernate have a dependencies on org.restlet*.  This is no longer available via maven central.  You will need to add:
    mavenRepo "http://maven.restlet.org"
      To your BuildConfig.groovy file and/or your pom.xml file as an external repository.
    • I initially had trouble getting the archetype for v2.0.1.  For some reason the command mvn archetype:generate just would not pick up the new version, even though it is there and available.  To resolve this, I trashed my .m2 folder and when the dependencies were pulled in, it pulled in the new version of the archetype.
    As always, I think there were some issues I ran across, but at the moment I can't think of them.  Also, at this point, the upgrade still isn't complete, and I'm getting errors, but at least the errors seem to be related to the code and possible re-naming and re-factoring that occurred in the new version.