Crappy coding

Java på OSX Lion

2011-11-02T13:47:00.000-07:00

Om man vill köra Java 1.4 eller 1.5 i OSX Lion är det inte mycket att göra åt om man inte råkar komma över en variant av Leopard-tar.gz filerna för dessa. Sen kan man ju passa på att stoppa in dessa i OSX Frameworkkatalog och länka till dessa istället för att låta länkarna peka på 1.6.

tar xzvf java.1.4.2-leopard.tar.gz

sudo mv 1.4.2 /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2-leopard

sudo rm /System/Library/Frameworks/JavaVM.framework/Versions/1.4

sudo rm /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2

sudo ln -s /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2-leopard/ /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2

sudo ln -s /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2 /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2

tar xzvf java.1.5.0-leopard.tar.gz

sudo mv 1.5.0 /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0-leopard

sudo rm /System/Library/Frameworks/JavaVM.framework/Versions/1.5

sudo rm /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0

sudo ln -s /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0-leopard /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0

sudo ln -s /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0 /System/Library/Frameworks/JavaVM.framework/Versions/1.5

... och bob är din onkel.

Oracle XA

2011-10-06T15:12:00.000-07:00

Eftersom det visade sig vara så att man måste granta rättigheter för att köra XA transaktioner på en Oracledatabas från en jboss så passar jag på att påminna mig själv om att det krävs för din dbuser som jag ska köra med från appservern.
Om man inte gör det dyker detta mysiga felmeddelande upp som en varning i loggen med cirka 3 minuters mellanrum.
2011-10-06 23:31:45,099 WARN [com.arjuna.ats.jta.logging.loggerI18N] (Thread-12) [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR

Så passa på du med, granta dig själv till en bättre värld.
GRANT SELECT ON sys.dba_pending_transactions TO <dbuser>;
GRANT SELECT ON sys.pending_trans$ TO <dbuser>;
GRANT SELECT ON sys.dba_2pc_pending TO <dbuser>;
GRANT EXECUTE ON sys.dbms_system TO <dbuser>;

Hotswappa sessioncontext i en ejb2-böna med spring.

2011-03-23T08:59:00.001-07:00

Eftersom jag för andra gången glömde bort hur man sätter upp en fin liten hotswappable target source för att swappa in sessionskontextet i en gammal böna tänkte jag att jag lägger upp en liten komihåg på det nu.

Först tar vi och lägger till ett target i sessionsbönan vi ska swappa den från:

public class Bean extends AbstractStatelessSessionBean implements SessionBean {
private HotSwappableTargetSource sessionContextTarget;
protected void onEjbCreate() throws CreateException {
BeanFactory beanFactory = getBeanFactory();
sessionContextTarget = = (HotSwappableTargetSource) beanFactory.getBean("hotswappableSessionContext");
}
}

samt att vi lägger till själva swappen i set-metoden:

@Override
public void setSessionContext(SessionContext sessionContext) {
super.setSessionContext(sessionContext);
this.sessionContextTarget.swap(sessionContext);
}

Därefer passar vi på att konfigurera den i springxmlen,

<bean id="sessionContextBean" class="nu.danielsundberg.FejkSessionContext"/>
<bean id="hotswappableSessionContext" class="org.springframework.aop.target.HotSwappableTargetSource">
<constructor-arg><ref local="sessionContextBean"/></constructor-arg>
</bean>

lägger till den injectad i vår andra böna vi vill ha access till contextet i

<property name="sessionsContext">
<ref local="sessionContextBean"/>
</property>

och avslutar med att lägga till den i mottagande bönan.

private SessionContext sessionsContext;
public void setSessionsContext(SessionContext sessionsContext) {
this.sessionsContext = sessionsContext;
}

Och bob är min onkel.

@Hide på metoder i Android

2010-11-01T18:10:00.000-07:00

Efter att ha letat oavbrutet i ungefär 2 timmar efter vettiga (eller på något sätt befintliga) sätt att tjuvtitta på en befintlig ström mot Audioslinger (Androids underliggande tjusiga ramverk som skjuter data på ljudhårdvaran) som man inte skapat själv i Androids medialibbar så har jag kommit fram till följande.

Androids medialibbar suger hästdelar.
Allt bra "kommer sen" (i det här fallet Open AL och mer native-nära funktioner)

Så tills vidare trodde jag förstås att jag var, som undomarna säger idag, rökt. Men av en magisk slump (eller idogt googlande) landade jag på implementationen av de medföljande visualiseringarna av musik i Androidkällkoden, där en metod med namnet "snoop"användes flitigt på mediaspelarklassen som jag ansåg vara värd en extra titt. Efter att ha förundrats över det faktum att jag tydligen inte kunde anropa denna fina metod (eller ens bevisa dess existens i min utvecklingsmiljö) fick jag en snabb lektion i en annotering med det snillrika namnet @Hide. Denna annotering används på metoder som inte anses vara dokumenterbar/förvaltningsbar i Androids källkod (men förmodligen kommer att bli det iom att den finns kvar). Eftersom jag inte har lust att kompilera några stubbar/bygga om Androidprylar från source kom jag raskt att tänka på perfektionen i att reflektera. Så utan mera omsvävningar, här kommer hur du anropar en metod i Android (förslagsvis snoopmetoden på MediaPlayer i det här fallet) på ett mer eller mindre tjusigt sätt tills den slutar gömmas:

short [] mVizData = new short[1024];
try {
  Class<MediaPlayer> myEvilMediaPlayer = (Class<MediaPlayer>) Class.forName(MediaPlayer.class.getName());
  try {
   Class[] parameterTypes = new Class[] {short[].class, int.class};
   Method snoop = myEvilMediaPlayer.getMethod("snoop", parameterTypes);
   snoop.setAccessible(true);
   Object[] arguments = new Object[2];
   arguments[0] = mVizData;
   arguments[1] = 0;
   int x = (Integer) snoop.invoke(myEvilMediaPlayer, arguments);
   System.out.println(x);
  } catch (SecurityException e) {
   e.printStackTrace();
  } catch (NoSuchMethodException e) {
   e.printStackTrace();
  } catch (IllegalArgumentException e) {
   e.printStackTrace();
  } catch (IllegalAccessException e) {
   e.printStackTrace();
  } catch (InvocationTargetException e) {
   e.printStackTrace();
  }
} catch (ClassNotFoundException e) {
  e.printStackTrace();
}

In your face @Hide annoteringen, det där är vad man får om man försöker gömma metoder för folk.

Ternary operators i Java

2010-10-19T23:07:00.000-07:00

Okej, jag kan vara lätt kod-fascistisk ibland, och jag uppskattar ett fläskigt syntax-solo lika mycket som the next nerd, men ternary operators, eller shorthand eller the child ny any other name osv borde avskaffas omedelbart i kod som skall läsas av många människor. Jag är ju ogärna gnällig men efter att ha stött på detta fenomen som kräver massor av tid varje gång av mig (eftersom det inte är direkt uppenbart vad ditt statement gör så måste jag naturligtvis läsa det och tolka det) så tänkte jag att jag bloggar en liten kommihåglapp så jag kan översätta snabbare.

Ta exemplet

minVal = (a < b) ? a : b;

där vi trivialt sätter det minsta av 2 värden (a och b då i det här fallet) till minVal. Motsvarande vanlig ifsats borde typiskt vara

if ( a < b ) { minVal = a; } else { minVal = b; }

men det är ju helt förkastligt att skriva om man vill imponera på folk med sin syntax-skill. Vilket natruligtvis är häftigt i nördsammanhang där och då, men när nyanställda putte ska laga ett PMD-fel från cruisecontrollen och hittar en lång jäkla harrang som han inte riktigt hänger med i så öppnar man ju upp för skapande av ett fel i koden som enbart beror på att man inte kunde kamma sig och skriva en vanlig bond-ifsats istället.

Naturligtvis är det inte fel att använda denna fina funktion som Sun stoppat in i specen, men jag skulle säga att det nog kan tänkas vara moraliskt snarare än tekniskt. Generellt så funkar det iaf så här

resultat = test ? värde1 : värde2;

eller med if/else

if ( test ) { resultat = värde1; } else { resultat = värde2; }

så det är ju förstås inte helt svårt när man väl vänjer sig. Ett bra exempel taget ur vanliga livet (något förvanskat förstås men ändå) är följande.

Iterable<Grupp> kanskeTom = listaMedPoster.iterator().hasNext() ? listaMedPoster : Arrays.asList(Grupp.EMPTY);

och efter en städning (fick PMD-warnings på raden)

Iterable<Grupp> kanskeTom = null;

if(listaMedPoster.iterator().hasNext()) {

kanskeTom = listaMedPoster;

} else {

kanskeTom = Arrays.asList(Grupp.EMPTY);

}

så nästa gång du funderar på att köra shorthand, tänk på mig som istället för att skumma igenom din kod kommer behöva tänka flera sekunder till på din ifsats.

Android och IPSec/L2TP på Ubuntu.

2010-10-07T23:19:00.000-07:00

Efter att ha trollat med att sätta upp en VPN som min telefon kan använda kan jag lätt konstatera att det inte fanns så där jättemånga "bra" howtos på teh internets. Så här gjorde jag.

1. Installera/configurera Openswan
För att kryptera IP-paketen vill vi installera Openswan som tillhandahåller kryptering och autentifiering för att skeppa paket mellan din enhet och din server. Här kör alla Openswan så det gjorde jag med.

sudo aptitude install openswan

och därefter så passade jag på att stoppa in följande i min /etc/ipsec.conf :

version 2.0
config setup
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
oe=off
protostack=netkey

conn L2TP-PSK-NAT
rightsubnet=vhost:%priv
also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=no
ikelifetime=8h
keylife=1h
type=transport
left=VPNSERVERNS.INTERNA.IP
leftprotoport=17/1701
right=%any
rightprotoport=17/%any

och passade därefter på att sätta lösenordet för att kryptera paket in till mitt fina intranät genom att skriva följande i min /etc/ipsec.secrets :

VPNSERVERNS.INTERNA.IP %any: PSK MITT LÖSENORD

och eftersom Openswan gnällde en hel massa på diverse så passade jag på att köra följande kommando i mitt fina shell :

for each in /proc/sys/net/ipv4/conf/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done

och därefter så verifierade jag att allt var ok och därefter starta om Openswan genom att yppa de magiska orden (tillsammans med en magisk gest) :

sudo ipsec verify
sudo /etc/init.d/ipsec restart

Om man har lust att se vad som händer så visas helt magiskt allt som händer i detta sammanhang i loggen /var/log/syslog. Leta efter det magiska IPSec connection established.

2. Installera/konfigurera L2TP
L2TP är alltså delen som tunnlar data från din klient till ditt säkra nät. Det krypterar inte och det autentifierar inte (vilket är typ anledningen till att man måste köra IPSec framför, vilket alla, läs microsoft och apple, undviker att tänka på).

Hur som helst, installera paketet xl2tp från en apt nära dig :

sudo aptitude install xl2tpd

och konfigurera i en trevlig fil som heter /etc/xl2tpd/xl2tpd.conf :

[global]
ipsec saref = yes

[lns default]
ip range = 10.1.2.2-10.1.2.255
local ip = 10.1.2.1
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

Där alltså ip range betyder vilken range dina devices kommer få addresser i och local ip är vilken address som "vpn-adaptern" på servern kommer att få. Bra att inte sätta den i ranget som devices får ip av kan tilläggas.

Därefter passar vi på att (som vi just konfigurerade) sätta ppp-options i filen /etc/ppp/options.xl2tpd vilket osökt för oss in i nästa steg.

3. Installera/konfigurera PPP
Vi vill förstås ha nått som hanterar användarna, och till det väljer vi PPP.

sudo aptitude install ppp

som vi konfigurerar i ovan nämnda fil /etc/ppp/options.xl2tpd :

require-mschap-v2
ms-dns 8.8.8.8
ms-dns 8.8.4.4
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4

och eftersom vi nu är på den så kallade "home strech" så passar vi på att lägga till ett lösenord för användaren vi tänkte oss använda när vi loggar in (man har alltså ett username/password och en delad "secret" till nätet, typ som WLAN men bättre). Detta görs med fördel i filen /etc/ppp/chap-secrets :

# user server password ip
test l2tpd testpassword *

och därefter passar vi på att starta om l2tp-demonen :

sudo /etc/init.d/xl2tpd restart

4. Routing, the final frontier.
Nu borde allt vara friden och fröjden, men det är det inte direkt eftersom man inte kommer åt nått utanför intranätet. Detta känns lite tråkigt eftersom hela poängen med vpn för mig är att kunna verka komma hemmifrån. En liten lätt routingförändring i iptables löser biffen :

iptables --table nat --append POSTROUTING --jump MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

och därefter är du good to go. Ett litet aber är förstås att om man kör debianpaketet för openswan från ubunturepot t.ex. så leker den inte bra nog med xl2tp på grund av versionsförbistringar, så att köra med en OSX-baserad klient funkar obra, men androidtelefoner verkar kirra biffen. Lösningen är enligt uppsago att kompilera en nyare version av openswan men det skiter jag i just nu.

Cheers. Skål och tack för en till.

Android ListPreference stuff.

2010-08-09T12:54:00.000-07:00

Okej, så efter att ha fått nullpointer en hel kväll och tillslut googlat lite så visar det sig att Androids ListPreference inte kan kombinera string-array med integer-array. Inte så smidigt när man vill spara en int med ett namn typ.

Dvs:

<resources>

<string-array name="entries">

<item>En minut</item>

<item>Två minuter</item>

<item>Tre minuter</item>

<item>Tio minuter</item>

</string-array>

<integer-array name="entry_values"> 

<item>1</item> 

<item>2</item> 

<item>3</item> 

<item>10</item> 

</integer-array> 

</resources> 

fungerar inte, så istället får man göra en

<resources>

<string-array name="entries">

<item>En minut</item>

<item>Två minuter</item>

<item>Tre minuter</item>

<item>Tio minuter</item>

</string-array>

<string-array name="entry_values">

<item>1</item>

<item>2</item>

<item>3</item>

<item>10</item>

</string-array>

</resources>

Kanske kan detta inlägg få mig att slippa jäklas lika länge nästa gång. :P

Sensors i android.

2010-06-24T06:52:00.000-07:00

Android är ett hejjigt operativ och nu när jag behöver komma ihåg hur man kommer åt sensorerna postar vi lite sånt.

Först behöver man registrera sin listner hos sensormanagern (förslagsvis i onCreate):

SensorManager sm;
sm = (SensorManager) getSystemService(SENSOR_SERVICE);

// Register your SensorListener
sm.registerListener(sl, SensorManager.SENSOR_ORIENTATION SensorManager.SENSOR_DELAY_NORMAL);

sen så kan det vara händigt att i din sensorlistner ha:

private final SensorListener sl = new SensorListener() {
public void onSensorChanged(int sensor, float[] values) {
}

public void onAccuracyChanged(int sensor, int accuracy) {
}
};

Inline XSLT/XML

2010-03-19T03:44:00.000-07:00

Jag ogillar att komma ihåg saker som inte längre är aktuella så jag sparar ned informationen här i hopp om att jag nån gång slipper använda den. Eftersom det kan vara bra att kunna xsltransformera lite xml nån gång så poppar jag in den här

<c:set var="xsl">
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<xsl:text>Antal XMLposter:</xsl:text><b><xsl:value-of select="count(*[local-name()='Test'])"/></b>
<a href="#" onClick="showhide('xmlData'); return false;">Visa/dölj detaljer</a><br/>
<div id="xmlData" style="display: none">
<xsl:apply-templates select="*[local-name()='TestPost']" />
</div>
</xsl:template>


<xsl:template match="ns:Test">
<xsl:text>Test:</xsl:text><b><xsl:value-of select="ns:Value"/></b>
</xsl:template>


<xsl:template match="text()">
</xsl:template>
</xsl:stylesheet>
</c:set>


<c:set var="xml" scope="page" value="${test.xml}" />
<x:transform doc="<?xml version='1.0'?>${xml}" xslt="${xsl}" />
</c:set>

Ett händigt verktyg för att testa sin XSL finns passande nog att hitta här om man känner dragning åt det hållet.

WS & Android

2009-10-11T07:53:00.000-07:00

Har grejjat lite med Androidappar efter att jag styrde upp mina fina bönor som webbservicear på Glassfish. Det finns en skön patchad KSOAP2 implementation för Android så man enkelt kan snacka med sina servicar. Funkar ju onekligen, men jag vet väl inte om jag tycker det är direkt smidigt. Bara för att man kan göra soapanrop betyder ju inte att det är smidigt att använda. Kanske enklare att bara köra RESTful prylar och skippa hela soap-biten. Men så jag kommer ihåg hur det var jag grejjade så bloggar jag koden iaf.

import org.ksoap2.SoapEnvelope;
import org.ksoap2.serialization.SoapObject;
import org.ksoap2.serialization.SoapSerializationEnvelope;
import org.ksoap2.transport.AndroidHttpTransport;

...

    private static final String SOAP_ACTION = "getTest";
    private static final String METHOD_NAME = "getTest";
    private static final String NAMESPACE =

"http://test.danielsundberg.nu/";
    private static final String URL =

"http://services.danielsundberg.nu/TestService/TestBean?wsdl"; 
    private Object resultRequestSOAP = null;
   
...

      private void search() {
        SoapObject request = new SoapObject(NAMESPACE, METHOD_NAME);

       //SoapObject
       request.addProperty("arg0", imeibox.getText().toString());
       SoapSerializationEnvelope envelope =

         new SoapSerializationEnvelope(SoapEnvelope.VER11);
       envelope.setOutputSoapObject(request);

       AndroidHttpTransport androidHttpTransport =

         new AndroidHttpTransport(URL);
       try {
           androidHttpTransport.call(SOAP_ACTION, envelope);
           resultRequestSOAP = envelope.getResponse();
           SoapObject resultsRequestSOAP = (SoapObject) envelope.bodyIn;
           SoapObject result =

(SoapObject) resultsRequestSOAP.getProperty("return");
           text.setText("Result: "+result.getProperty("firstResult");
           }         
       }
       catch (Exception e) {
           text.setText("An error occured while searching '" +
             e.getClass() + "'");
       } 
    }

Funkar men är ju inte direkt smidigt, har inte lyckats casta till några typer andra än bastyperna, men jag har väl inte undersökt jättenoga heller. Hur som så är det ju ballt att kunna snacka soap från en androidapp bara sådär. Kanske inte direkt skivat bröd, men väl som en kasse bärs.

EJB3 & WLS10

2009-10-08T10:41:00.000-07:00

Efter att ha testat runt lite känns det som om jag missat nått. Jag verkar inte vara ensam om att inte lyckas accessa mina remotebönor på en klient heller. Först var det lite forskning att hitta åt mappingName (som förstås var specifikt för weblogic) men nu hittar jag iaf bönorna i JNDI. Dock när jag försöker instansiera dem i klienten så får jag ett spännande ClassCastException. Var ju också ruskigt smidigt att få till en webbservice av bönorna.

Bönan

@Local({TestLocal.class})
@Remote({TestRemote.class})
@Stateless(name="TestBean", mappedName="ejb/Test",

description="Test implementation.")
@WebService(endpointInterface =

"nu.danielsundberg.service.TestRemote",

serviceName="TestRemote")
public class TestBean implements TestLocal, TestRemote {
    @javax.jws.WebMethod()
    public int test(int tal1, int tal2) {
        return tal1+tal2;
    }
}

Localinterface

@Local

public interface Test{
    int test(int tal1, int tal2);
}

Remoteinterface

@Remote
@WebService
@SOAPBinding(style =

javax.jws.soap.SOAPBinding.Style.DOCUMENT)
public interface TestRemote extends Test{
}

Bönorna dyker upp i domänens JNDI-träd okej, frågan är om jag har packat ihop mitt projekt på nått fel sätt så att klassladdarstrul uppstår. Webbservicen blir iaf klockren. Ska replikera mitt projekt och testa i Glassfish istället och kolla om den klarar sig lite bättre.

Dock verkar EJB3-standarden vara lite som skivat bröd, jäkligt smidigt dvs.