|
|
|
|
bluecove with pMEA dual stack
Posted:
Jun 9, 2008 4:24 PM
|
|
|
Hello everyone,
someone was able to use bluecove regularly in a midlet with pMEA dual stack?
Thanks Pagano
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 3, 2008 12:29 PM
in response to: paganopaganino
|
|
|
(bluecove is a really nice jsr-82 implementation)
I have been trying this for the last week or so using both the feature and Advanced version. The bottom line is I wasn't able to load the bluecove classes from within a Midlet using phoneME and it failed with ClassFormatError when it tried to load the bluecove classes. I tried both
255#"\phoneme\midp\bin\arm\runMidlet.exe" -classpathext "\phoneme\bluecove\bluecove-2.0.2.jar;\Storage Card\midlets\BTCheck\BTCheck.jar" "\Storage Card\midlets\BTCheck\BTCheck.jad" BTCheck
and
255#"\phoneme\foundation\bin\cvm.exe" -f "\Storage Card\midlets\BTCheck\BTCheck.txt"
BTCheck.txt:
-Xmx2m -Dmicroedition.profiles=MIDP-2.1 -Dsun.midp.library.name=midp "-Dsun.midp.home.path=\phoneme\foundation\midp\midp_wince" -Dcom.sun.midp.mainClass.name=com.sun.midp.main.CdcMIDletSuiteLoader sun.misc.MIDPLauncher -midppath "\phoneme\foundation\midp\midp_wince\classes.zip;\phoneme\bluecove\bluecove-2.0.2.jar" -suitepath "\Storage Card\midlets\BTCheck\BTCheck.jar" -1 BTCheck
I was able to load the bluecove classes using the cdc version on a standard java class successfully and was able to run the bluecove tester using phoneME cdc
254#"\phoneme\foundation\bin\cvm.exe" -cp "\Storage Card\midlets\BTCheck\bluecove-tester-mobile.jar" net.sf.bluecove.awt.Main
I also posted this issue on the bluecove forum and Vlad responded with this :
"Would be nice if somebody found the document describing how to add
additional libraries to phoneMe installation. Then bluecove can be
adapted to follow this guidelines. "
I wish someone here can provide some guidelines. For anyone wanting to develop bluetooth apps using MIDP on Windows mobile 5, phoneME with bluecove seems to be the perfect solution. Unfortunately it doesnt work within a midlet.
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 3, 2008 4:39 PM
in response to: gsekar
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> (bluecove is a really nice jsr-82 implementation)
>
> I have been trying this for the last week or so using both the feature and Advanced version. The bottom line is I wasn't able to load the bluecove classes from within a Midlet using phoneME and it failed with ClassFormatError when it tried to load the bluecove classes. I tried both
>
> ...
> I also posted this issue on the bluecove forum and Vlad responded with this :
>
> "Would be nice if somebody found the document describing how to add
> additional libraries to phoneMe installation. Then bluecove can be
> adapted to follow this guidelines. "
>
Hi gsekar,
The Java ME CDC Runtime Guide is free to access online:
http://java.sun.com/javame/reference/docs/cdc_runtime_guide.pdf
In that doc, go to Chap. 4, page 4-5 and read about the -Xbootclasspath
command-line option. That is what you use to add system library classes
(as opposed to app classes that you add to the -classpath).
So, maybe you can read through the CDC Runtime Guide and find some
things to try.
Such as changing around your BTCheck.txt like this?
255#"\phoneme\foundation\bin\cvm.exe" -f "\Storage Card\midlets\BTCheck\BTCheck.txt"
BTCheck.txt:
-Xmx2m -Dmicroedition.profiles=MIDP-2.1 -Dsun.midp.library.name=midp "-Xbootclasspath/a=\phoneme\bluecove\bluecove-2.0.2.jar" "-Dsun.midp.home.path=\phoneme\foundation\midp\midp_wince" -Dcom.sun.midp.mainClass.name=com.sun.midp.main.CdcMIDletSuiteLoader sun.misc.MIDPLauncher -suitepath "\Storage Card\midlets\BTCheck\BTCheck.jar" -1 BTCheck
I'm not sure if that will help, but you can try that and see if something along those lines will make things better.
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
bluecove with pMEA dual stack
Posted:
Jul 4, 2008 12:39 PM
in response to: Hinkmond Wong
|
|
|
|
|
On Friday 04 July 2008 01:39:14 Hinkmond Wong wrote:
> Hi gsekar,
>
> The Java ME CDC Runtime Guide is free to access online:
> http://java.sun.com/javame/reference/docs/cdc_runtime_guide.pdf
>
> In that doc, go to Chap. 4, page 4-5 and read about the -Xbootclasspath
> command-line option. That is what you use to add system library classes
> (as opposed to app classes that you add to the -classpath).
>
> So, maybe you can read through the CDC Runtime Guide and find some
> things to try.
>
> Such as changing around your BTCheck.txt like this?
>
> 255#"\phoneme\foundation\bin\cvm.exe" -f "\Storage
> Card\midlets\BTCheck\BTCheck.txt"
>
> BTCheck.txt:
> -Xmx2m -Dmicroedition.profiles=MIDP-2.1 -Dsun.midp.library.name=midp
> "-Xbootclasspath/a=\phoneme\bluecove\bluecove-2.0.2.jar"
> "-Dsun.midp.home.path=\phoneme\foundation\midp\midp_wince"
> -Dcom.sun.midp.mainClass.name=com.sun.midp.main.CdcMIDletSuiteLoader
> sun.misc.MIDPLauncher -suitepath "\Storage
> Card\midlets\BTCheck\BTCheck.jar" -1 BTCheck
>
>
> I'm not sure if that will help, but you can try that and see if something
> along those lines will make things better.
>
>
> Hinkmond
Hi,
I did some experiments with the bluecove test applications:
http://www.bluecove.org/bluecove-examples/bluecove-tester/
I was able to run the bluecove-tester-mobile.jar application with pMEA PP on a
WM2003 device. Due to some bug with the AWT Menu on WM5 and WM6 (the menu
does not show although it is the same binary), I cannot initiate a BT
discovery. I did another quick console application and that seemed to work on
my WM6 device. I haven't been able to run the bctest bluecove midlet with the
dual stack though. It gives me an exception saying that it could not find the
class javax.bluetooth.UUID. This class is available in the bluecove-2.0.2.jar
that I appended to the bootclasspath, but it seems that it does not work.
-Xmx2m -Dmicroedition.profiles=MIDP-2.1 -Dsun.midp.library.name=midp
"-Xbootclasspath/a=\memory card\test\bluecove\lib\bluecove-2.0.2.jar"
"-Dsun.midp.home.path=\memory card\dual\midp\midp_wince"
-Dcom.sun.midp.mainClass.name=com.sun.midp.main.CdcMIDletSuiteLoader
sun.misc.MIDPLauncher
-midppath "\memory card\dual\midp\midp_wince\classes"
-suitepath "\memory card\midlets\bctest.jar" -1
net.sf.bluecove.BlueCoveTestMIDlet
I did not try to integrate the bluecove sources into phoneME Advanced, but I
did try to do so for phoneME Feature. I was hoping that it would be enough to
get the bluecove java sources compiled into runMidlet and have them load the
native bindings. However, several J2SE classes and methods are used for which
we need a workaround. Here is a summary of the 73 compilation errors I get:
* package java.net does not exist
java.net.InetAddress;
java.net.ServerSocket;
java.net.Socket;
* package java.security does not exist
java.security.MessageDigest;
java.security.NoSuchAlgorithmException;
java.security.AccessControlContext;
java.security.AccessController;
java.security.PrivilegedActionException;
java.security.PrivilegedExceptionAction;
* package org.apache.log4j does not exist
org.apache.log4j.Logger;
org.apache.log4j.Level;
* other missing classes:
java.util.Properties;
java.io.File;
java.io.FileOutputStream;
java.util.WeakHashMap;
java.lang.StackTraceElement;
java.lang.ClassLoader;
* missing methods or other errors:
Thread.interrupted()
Thread.setDaemon()
Throwable.getStackTrace()
Throwable.printStackTrace()
Runtime.addShutdownHook()
System.getProperties()
System.setProperty()
System.clearProperty()
System.loadLibrary()
Vector.add()
Some of these could be rather trivial, while others are definitely not. If I
can figure out what I need to modify to build jsr82 with pMEA/MIDP/Jump/...,
I might test again, but I would prefer a jsr that works for both pMEA and
pMEF.
Regards,
Davy
--
Davy Preuveneers
K.U.Leuven - http://www.kuleuven.be
Department of Computer Science - http://www.cs.kuleuven.be
DistriNet - http://www.cs.kuleuven.be/~distrinet
Celestijnenlaan 200A, B-3001 Heverlee (Leuven), Belgium
Room: 02.152
Phone: (+32) (0)16 327853
E-Mail: Davy.Preuveneers@cs.kuleuven.be
Web: http://www.cs.kuleuven.be/~davy
[signature.asc]
|
|
|
|
|
|
|
|
|
bluecove with pMEA dual stack
Posted:
Jul 7, 2008 12:18 PM
in response to: Davy Preuveneers
|
|
|
I have had some success with BlueCove for midlets on pMEA, but I would like
some feedback from the pMEA experts about the approach.
I was looking into integrating bluecove into pMEA and pMEF to have bluetooth
support midlets. Supporting pMEF is not straightforward as Bluecove is J2SE
based, so I went ahead with pMEA. It appears that adding an external jar and
native libraries to a classpath or bootclasspath does not seem to work as the
required packages cannot be found when running a JSR82 midlet.
My next step was to try integrate the java sources into the pMEA build process
in order to get them recognized by the midlet. What I did was create build
and configuration files similar to jsr172. The compilation of the Java
sources of Bluecove succeeded and everything went fine except for the last
build step where all native objects are linked into a binary. At that step I
got linking errors about missing JNI methods. These methods are the native
methods declared in the java sources for which an implementation is provided
in the bluetooth stack native libraries of BlueCove. After creating several
stubs the compilation succeeded, but of course I needed a proper native
implementation. But then I faced the following issues:
-I cannot replace the stubs with the c and c++ source files of Bluecove
because the various libraries require different compilers and compilation
flags
-the BlueCove java files cannot load external libraries at runtime because the
java classes do not have the required privileges / security permissions.
-Even if you work around the permission issue to load a dll, the java files
still use the stubs and not the proper library loaded by the java files. So
we need to compile and link a proper implementation into the binary while
avoiding the compiler dependencies.
So what I did was create a script that creates a plain C file to replace the
stubs file. This new C file contains function pointers for the JNI methods
with some extra code to load the original Bluecove native library and map the
JNI methods in the bluetooth stack libraries to these function pointers. I
have the bluecove bctest midlet working this way (pMEA Foundation + MIDP
without JUMP), but only tested it for the Widcomm and Microsoft bluetooth
stack on WinCE. However, the process of adding JSR82 support was rather
cumbersome and that is why I am left with the following questions:
-Is it possible to add jars to the (boot)classpath so that a midlet can use
them (i.e. without recompiling the VM)? Or do the java classes need to be
romized?
-Can I also add jars with native methods and JNI libraries or is there no way
to bypass the security permissions to load external libraries from within a
java file?
-If not, is there a better way than function pointers if you cannot compile
the original dll sources (for example, if you do not have them)?
Regards,
Davy
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 7, 2008 2:41 PM
in response to: Davy Preuveneers
|
|
|
Davy Preuveneers wrote:
> ...
>
Hi Davy,
I think trying to debug why -Xbootclasspath with
-Dsun.booth.library.path are not working is the easiest route for you.
It's supposed to work in your case, however there is one case where I
can think of that _won't_ work: If you try to add java.* or javax.* APIs
(which is a no-no, since that would mean your build would become
non-spec. compliant with additional non-spec.'d APIs for CLDC/MIDP that
are being API Hidden):
> -Is it possible to add jars to the (boot)classpath so that a midlet can use
> them (i.e. without recompiling the VM)? Or do the java classes need to be
> romized?
>
Yes (but see caveat above). You can add the path (or JAR file(s)) to
-Xbootclasspath/a=... (as long as they are not java.* or javax.* APIs)
(NOTE: make sure to use /a to append to the bootclasspath), and you can
add the native path to the supporting native shared libs you need (like
libX.so) to -Dsun.boot.library.path=... as long as you have a
System.loadLibrary("X") call in your Java code.
Example:
cvm -Xbootclasspath/a=./X.jar -Dsun.boot.library.path=./ ...
Note: On WinMobile, just put your .dll in the same directory as where
the cvmi.dll file is (no need to use -Dsun.boot.library.path...) , since
our WinMobile build will look there for all .dll files. Also note that
debug builds will look for a dll or shared lib calls libX_g.so or
libX_g.dll (it automatically appends a "_g" to the end of the name you
use in the System.loadLibrary("X") call.
> -Can I also add jars with native methods and JNI libraries or is there no way
> to bypass the security permissions to load external libraries from within a
> java file?
>
Yes, you can do that on a command line that starts the cvm (this mimics
that you are the system integrator deciding what libs/system classes are
going into the platform, so you have the privilege to make mods as long
as you have access to create a cvm command line)
See:
http://java.sun.com/j2se/1.4.2/docs/tooldocs/findingclasses.html
> -If not, is there a better way than function pointers if you cannot compile
> the original dll sources (for example, if you do not have them)
Should be OK as long as you have the proper header files for those
original dlls so that you can use the JNI tool (javah).
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 7, 2008 3:23 PM
in response to: Hinkmond Wong
|
|
|
|
|
Thanks Hinkmond for the answer,
On Monday 07 July 2008, Hinkmond Wong wrote:
> Davy Preuveneers wrote:
> > ...
>
> Hi Davy,
>
> I think trying to debug why -Xbootclasspath with
> -Dsun.booth.library.path are not working is the easiest route for you.
> It's supposed to work in your case, however there is one case where I
> can think of that _won't_ work: If you try to add java.* or javax.* APIs
> (which is a no-no, since that would mean your build would become
> non-spec. compliant with additional non-spec.'d APIs for CLDC/MIDP that
I should have thought of this. The problem is that JSR 82 has two packages
javax.bluetooth and javax.obex which I need to add. However, see my comment
below too!
> are being API Hidden):
> > -Is it possible to add jars to the (boot)classpath so that a midlet can
> > use them (i.e. without recompiling the VM)? Or do the java classes need
> > to be romized?
>
> Yes (but see caveat above). You can add the path (or JAR file(s)) to
> -Xbootclasspath/a=... (as long as they are not java.* or javax.* APIs)
> (NOTE: make sure to use /a to append to the bootclasspath), and you can
> add the native path to the supporting native shared libs you need (like
> libX.so) to -Dsun.boot.library.path=... as long as you have a
> System.loadLibrary("X") call in your Java code.
I already tried out all these tricks before I went ahead with the function
pointert approach. The thing is, the AWT based bluecove tester for mobile
phones works just fine on top of Personal Profile.
http://bluecove.sourceforge.net/bluecove-tester/
I have another console application that uses the javax.bluetooth package and
the command line just works without messing with the bootclasspath etc.:
254#"\dual\bin\cvm.exe" -cp "\bluecove\bluecove-2.0.2.jar;\bluecove"
RemoteDeviceDiscovery
The javax.bluetooth and javax.obex packages are in bluecove-2.0.2.jar
So why does not this work for midlets ...
> Example:
>
> cvm -Xbootclasspath/a=./X.jar -Dsun.boot.library.path=./ ...
>
> Note: On WinMobile, just put your .dll in the same directory as where
> the cvmi.dll file is (no need to use -Dsun.boot.library.path...) , since
> our WinMobile build will look there for all .dll files. Also note that
> debug builds will look for a dll or shared lib calls libX_g.so or
> libX_g.dll (it automatically appends a "_g" to the end of the name you
> use in the System.loadLibrary("X") call.
Yep, I already figured that out when loading dlls for my function pointers
approach.
> > -Can I also add jars with native methods and JNI libraries or is there no
> > way to bypass the security permissions to load external libraries from
> > within a java file?
>
> Yes, you can do that on a command line that starts the cvm (this mimics
> that you are the system integrator deciding what libs/system classes are
> going into the platform, so you have the privilege to make mods as long
> as you have access to create a cvm command line)
>
> See:
> http://java.sun.com/j2se/1.4.2/docs/tooldocs/findingclasses.html
>
> > -If not, is there a better way than function pointers if you cannot
> > compile the original dll sources (for example, if you do not have them)
>
> Should be OK as long as you have the proper header files for those
> original dlls so that you can use the JNI tool (javah).
>
>
> Hinkmond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
Davy
--
Davy Preuveneers
K.U.Leuven - http://www.kuleuven.be
Department of Computer Science - http://www.cs.kuleuven.be
DistriNet - http://www.cs.kuleuven.be/~distrinet
Celestijnenlaan 200A, B-3001 Heverlee (Leuven), Belgium
Room: 02.152
Phone: (+32) (0)16 327853
E-Mail: Davy.Preuveneers@cs.kuleuven.be
Web: http://www.cs.kuleuven.be/~davy
[signature.asc]
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 7, 2008 3:53 PM
in response to: Davy Preuveneers
|
|
|
Davy Preuveneers wrote:
>
>> Yes (but see caveat above). You can add the path (or JAR file(s)) to
>> -Xbootclasspath/a=... (as long as they are not java.* or javax.* APIs)
>> (NOTE: make sure to use /a to append to the bootclasspath), and you can
>> add the native path to the supporting native shared libs you need (like
>> libX.so) to -Dsun.boot.library.path=... as long as you have a
>> System.loadLibrary("X") call in your Java code.
>>
>
> I already tried out all these tricks before I went ahead with the function
> pointert approach. The thing is, the AWT based bluecove tester for mobile
> phones works just fine on top of Personal Profile.
>
> http://bluecove.sourceforge.net/bluecove-tester/
>
> I have another console application that uses the javax.bluetooth package and
> the command line just works without messing with the bootclasspath etc.:
>
> 254#"\dual\bin\cvm.exe" -cp "\bluecove\bluecove-2.0.2.jar;\bluecove"
> RemoteDeviceDiscovery
>
> The javax.bluetooth and javax.obex packages are in bluecove-2.0.2.jar
> So why does not this work for midlets ...
>
Looks like you have confirmed it's a problem with API Hiding blocking
access to the javax.bluetooth.* and javax.obex.* packages.
I just talked to Jiangli. Normally, if you are adding a proper JSR to
the phoneME build, you would create a subsystem.gmk file and add your
extra classes to the *IMPL_CLASSES Makefile variable list to get them
ROMized and also get them added to the MIDP Permitted classes list to
allow them through the API Hiding mechanism (used for spec. compliance)
in phoneME Advanced MIDP on CDC.
For now (for you to use as a hack), you can manually override the normal
list of MIDP Permitted classes that are allowed through via API Hiding,
by editing the following file:
src/share/lib/dualstack/midp/MIDPPermittedClasses.txt
Add every class as a single line entry in the file above (NOTE:
wildcarding is NOT allowed) for your javax.bluetooth.* and javax.obex.*
packages and then rebuild. The build process will copy over that file
to your lib directory of your installation (or edit your lib directory
MIDPPermittedClasses.txt file itself on your device at your own risk of
it being clobbered by another build that you copy on top of it).
Then after that, by adding your JAR files to the -Xbootclasspath/a=...
(that's the right way to do this hack in this case) you should be able
to access the classes needed from MIDP.
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 7, 2008 5:04 PM
in response to: Hinkmond Wong
|
|
|
On Tuesday 08 July 2008, Hinkmond Wong wrote:
> Looks like you have confirmed it's a problem with API Hiding blocking
> access to the javax.bluetooth.* and javax.obex.* packages.
>
> I just talked to Jiangli. Normally, if you are adding a proper JSR to
> the phoneME build, you would create a subsystem.gmk file and add your
> extra classes to the *IMPL_CLASSES Makefile variable list to get them
> ROMized and also get them added to the MIDP Permitted classes list to
> allow them through the API Hiding mechanism (used for spec. compliance)
> in phoneME Advanced MIDP on CDC.
That is probably why it didn't work with just the bootclasspath flag and why
it did work when I created subsystem files similar to jsr172 and added the
bluecove java files to be romized. I don't use any *IMPL_CLASSES variable
directly (and neither does jsr172), but I think that what I did to get it
work pretty much comes down to what you described above.
After the compilation the javax.bluetooth and javax.obex packages are indeed
added to the MIDPPermittedClasses.txt file. In fact, I also see those
packages in JSRRestrictedClasses.txt. I'll see if it keeps on working when I
build without JSR82 and copy over the previous txt files. Right now, taking
care of the native bindings with the function pointers is not really pretty
because it adds unnecessary overhead, especially for bluetooth stack
libraries that I will not use on the WinCE platform.
If I find an easy way to get this to work, I will post it on the forum so
others can use it too.
Davy
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 8, 2008 3:46 PM
in response to: Davy Preuveneers
|
|
|
I did finally manage to get a MIDlet using bluecove2.0.2 to work with the existing PhoneME dual stack build at Davy's site (2008-06-30: Build pMEA b77). I was able to sucessfully run the bctest midlet available on the bluecove site.
These are the steps I followed based on the discussion :
a. Edited \phoneme\foundation\lib\MIDPPermittedClasses.txt and manually added (Be careful as for some reason I had issues if there are empty lines in this file)
javax.obex.SessionNotifier
javax.obex.ServerRequestHandler
javax.obex.ResponseCodes
javax.obex.PasswordAuthentication
javax.obex.Operation
javax.obex.HeaderSet
javax.obex.ClientSession
javax.obex.Authenticator
javax.bluetooth.UUID
javax.bluetooth.ServiceRegistrationException
javax.bluetooth.ServiceRecord
javax.bluetooth.RemoteDevice
javax.bluetooth.LocalDevice
javax.bluetooth.L2CAPConnectionNotifier
javax.bluetooth.L2CAPConnection
javax.bluetooth.DiscoveryListener
javax.bluetooth.DiscoveryAgent
javax.bluetooth.DeviceClass
javax.bluetooth.DataElement
javax.bluetooth.BluetoothStateException
javax.bluetooth.BluetoothConnectionException
2. Extracted the 4 dll files (although I think we only need the 2 *_ce.dll) from the bluecove-2.0.2.jar and dropped them into \phoneme\foundation\bin folder
3. Deleted the dll files from the bluecove-2.0.2.jar
4. Deleted the javax.microedition folder inside the bluecove-2.0.2.jar folder
5. Created 2 files :
bctestCDC.lnk
255#"\phoneme\foundation\bin\cvm.exe" -f "\Storage Card\midlets\bctester\bctest.txt"
bctest.txt
-Xmx2m -Dmicroedition.profiles=MIDP-2.1 -Dsun.midp.library.name=midp "-Xbootclasspath/a:\phoneme\bluecove\bluecove-2.0.2.jar" "-Dsun.midp.home.path=\phoneme\foundation\midp\midp_wince" -Dcom.sun.midp.mainClass.name=com.sun.midp.main.CdcMIDletSuiteLoader sun.misc.MIDPLauncher -midppath "\phoneme\foundation\midp\midp_wince\classes.zip" -suitepath "\Storage Card\midlets\bctester\bctest.jar" -1 net.sf.bluecove.BlueCoveTestMIDlet
Thanks to Hinkmond Wong & Davy for everything.
Sekar
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 8, 2008 4:15 PM
in response to: gsekar
|
|
|
Hi Sekar,
Glad to hear it works for you. I got it running too and was about to post what
I had done, but you beat me to it  . I didn't remove any files from the
bluecove jar though, but I had to change the java.policy file to grant
loadLibrary runtime permissions. Otherwise, the bluecove-2.0.2.jar wouldn't
load the required dlls. Just in case someone has similar issues, edit the
java.policy file and add the two following permission lines:
grant {
...
permission java.lang.RuntimePermission "loadLibrary.intelbth_ce";
permission java.lang.RuntimePermission "loadLibrary.bluecove_ce";
}
Regards,
Davy
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 8, 2008 4:46 PM
in response to: gsekar
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> I did finally manage to get a MIDlet using bluecove2.0.2 to work with the existing PhoneME dual stack build at Davy's site (2008-06-30: Build pMEA b77). I was able to sucessfully run the bctest midlet available on the bluecove site.
>
> These are the steps I followed based on the discussion :
>
> ...
>
> Thanks to Hinkmond Wong & Davy for everything.
>
Hi Sekar,
Great to hear you and Davy have CDC/MIDP working now with the BlueCove
BlueTooth (JSR 82) implementation! That is very awesome that you
integrated a 3rd party JSR implementation with our phoneME CDC/MIDP dual
stack.
(And, that was mainly Davy who gave you most of the help you needed)
 Thanks, Davy!
You guys now have more experience in integrating external code with Java
ME CDC/MIDP than many Sun engineers. Congrats!
Thanks,
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 8, 2008 11:51 PM
in response to: Hinkmond Wong
|
|
|
|
|
I blogged about you guys, too
http://weblogs.java.net/blog/terrencebarr/archive/2008/07/lots_of_activit.html
and the current rush of other phoneME activities.
-- Terrence
Hinkmond Wong wrote:
> phonemeadvanced@mobileandembedded.org wrote:
>> I did finally manage to get a MIDlet using bluecove2.0.2 to work with
>> the existing PhoneME dual stack build at Davy's site (2008-06-30:
>> Build pMEA b77). I was able to sucessfully run the bctest midlet
>> available on the bluecove site.
>>
>> These are the steps I followed based on the discussion :
>>
>> ...
>>
>
>> Thanks to Hinkmond Wong & Davy for everything.
>
> Hi Sekar,
>
> Great to hear you and Davy have CDC/MIDP working now with the BlueCove
> BlueTooth (JSR 82) implementation! That is very awesome that you
> integrated a 3rd party JSR implementation with our phoneME CDC/MIDP dual
> stack.
>
> (And, that was mainly Davy who gave you most of the help you needed)
> Thanks, Davy!
>
> You guys now have more experience in integrating external code with Java
> ME CDC/MIDP than many Sun engineers. Congrats!
>
>
> Thanks,
> Hinkmond
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>
--
Terrence Barr
Senior Technologist and Community Ambassador
Java Mobile & Embedded Community
Phone: +49 711 720 98185
Yahoo: terrencebarr, AIM: terrencebarr123
http://www.mobileandembedded.org
http://www.sun.com
Registered Office:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.
[terrence_barr.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 9, 2008 8:51 AM
in response to: Terrence Barr -...
|
|
|
Terrence Barr - Senior Technologist and Ambassador wrote:
> I blogged about you guys, too
>
>
> http://weblogs.java.net/blog/terrencebarr/archive/2008/07/lots_of_activit.html
>
>
> and the current rush of other phoneME activities.
Very cool! I like the News flash graphic. Good post.
Hinkmond
> -- Terrence
>
> Hinkmond Wong wrote:
>> phonemeadvanced@mobileandembedded.org wrote:
>>> I did finally manage to get a MIDlet using bluecove2.0.2 to work
>>> with the existing PhoneME dual stack build at Davy's site
>>> (2008-06-30: Build pMEA b77). I was able to sucessfully run the
>>> bctest midlet available on the bluecove site.
>>>
>>> These are the steps I followed based on the discussion :
>>>
>>> ...
>>>
>>
>>> Thanks to Hinkmond Wong & Davy for everything.
>>
>> Hi Sekar,
>>
>> Great to hear you and Davy have CDC/MIDP working now with the
>> BlueCove BlueTooth (JSR 82) implementation! That is very awesome
>> that you integrated a 3rd party JSR implementation with our phoneME
>> CDC/MIDP dual stack.
>>
>> (And, that was mainly Davy who gave you most of the help you needed)
>> Thanks, Davy!
>>
>> You guys now have more experience in integrating external code with
>> Java ME CDC/MIDP than many Sun engineers. Congrats!
>>
>>
>> Thanks,
>> Hinkmond
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
>> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 27, 2009 4:18 PM
in response to: Hinkmond Wong
|
|
|
I have installed the phoneME Advanced dual stack in a Symbol MC70 using the procedure explained http://www.cs.kuleuven.be/~davy/phoneme/?q=node/22
When a run the midlet I got the error Bluetoothstack not detected.
This happen as soon the app. try the instruction. Localdevice.getLocalDevice();
Any sugestion.??
|
|
|
|
|
|
|
|
|
Re: bluecove with pMEA dual stack
Posted:
Jul 29, 2009 7:40 AM
in response to: jgg2000
|
|
|
I don't have a Symbol MC70 so I cannot check, but do you know if your BT stack is supported
by BlueCove? If that is not the case, then there is nothing much we can do about it as all BT
related operations are delegated to BlueCove including detection of the BT stack (if present).
Davy
|
|
|
|
|
java.net RSS
