Je suis en train d'exécuter Mac OS X Snow Leopard et je ne pourrais pas accéder à l'écran de l'activateur dans un ensemble OSGI.
ci-dessous est la méthode de démarrage de mon activateur: p>
Invalid memory access of location 00000020 eip=9012337c
4 Réponses :
Ce code a l'air très étrange ... Est-ce censé être un plug-in Eclipse? Qu'essayez-vous de faire? Je suppose que vous essayez de créer un plugin RCP avec une interface utilisateur. Si oui, voici la réponse: ne faites pas cela. Votre activateur OSGI n'est pas responsable de la création de la boucle d'événement SWT d'affichage.
Créer une extension d'application dans votre plugin.xml pour créer de manière préventive le SWT Bootstrap. Il ressemblera à quelque chose comme ceci: p> puis créez la classe d'application (appelez-le tout ce que vous voulez) regarder quelque chose comme ceci: p> public class Application implements IApplication {
/* (non-Javadoc)
* @see org.eclipse.equinox.app.IApplication#start(org.eclipse.equinox.app.IApplicationContext)
*/
public Object start(IApplicationContext context) {
Display display = PlatformUI.createDisplay();
try {
int returnCode = PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
if (returnCode == PlatformUI.RETURN_RESTART) {
return IApplication.EXIT_RESTART;
}
return IApplication.EXIT_OK;
} finally {
display.dispose();
}
}
/* (non-Javadoc)
* @see org.eclipse.equinox.app.IApplication#stop()
*/
public void stop() {
final IWorkbench workbench = PlatformUI.getWorkbench();
if (workbench == null)
return;
final Display display = workbench.getDisplay();
display.syncExec(new Runnable() {
public void run() {
if (!display.isDisposed())
workbench.close();
}
});
}
}
Non, je n'essaie pas de créer un plugin Eclipse. J'essaie d'utiliser SWT dans un environnement OSGI sans Eclipse RCP. Je sais que le Workbench de RCP est responsable de la création de l'écran et qu'il est effectué dans le fil principal avant que tous les plugins ne soient activés. Afaik il devrait être possible de créer l'affichage dans n'importe quel fil, tant qu'il est utilisé comme thread de l'interface utilisateur après cela. Du doc: "En SWT, le fil qui crée une instance d'affichage est distingué comme thread d'interface utilisateur pour cet affichage."
Cependant, j'ai appris que Mac OS X exige que le thread soit enfil de filetage 0. Cela pourrait expliquer pourquoi cela fonctionne sous Windows mais non sur Mac. Je ne sais pas comment résoudre ça ...
Vous voulez SWT sans RCP mais vous voulez Osgi - semble étrange. RCP est essentiellement SWT et OSGI avec quelques autres plug-ins que vous n'avez pas à utiliser si vous ne le souhaitez pas.
RCP est beaucoup plus que Osgi + SWT.
Je dirais plus, pas beaucoup plus. Je me développe sur cette plate-forme pendant 5 ans, donc je suis très familier.
Je peux confirmer que nous exécutons avec succès SWT carbone fort> sur Mac OS X dans sa propre boucle d'événement botté par une activation de paquet, il est donc certainement possible! Ceci utilise -xstartonfirstthread lors du lancement de la machine virtuelle. mais fort>, avec cacao SWT (64 bits), je vois la même erreur: ( p> Il semble que, bien que La façon dont nous avons couru du carbone SWT a fonctionné, ce n'était probablement pas casher: nous conduisions la boucle d'événement à travers un autre fil, pas le principal que vous êtes censé. Sous Cocoa SWT, cela ne fonctionne plus, et c'était Probablement la pratique dadgy quand même. p> Je peux réparer les erreurs de piscine de threads avec le piratage suivant avant de créer l'affichage (adapté à partir du constructeur de périphériques SWT COCOA): P> NSAutoreleasePool pool = (NSAutoreleasePool) new NSAutoreleasePool().alloc().init();
NSThread nsthread = NSThread.currentThread();
NSMutableDictionary dictionary = nsthread.threadDictionary();
NSString key = NSString.stringWith("SWT_NSAutoreleasePool");
id obj = dictionary.objectForKey(key);
if (obj == null) {
NSNumber nsnumber = NSNumber.numberWithInteger(pool.id);
dictionary.setObject(nsnumber, key);
} else {
pool.release();
}
Est-il possible de saisir un code simple pour que cela soit opérationnel? Et une configuration de démarrage de travail?
Vous avez bien compris ma question correctement. Le dernier commentaire que vous dites que vous souhaitez ajouter un crochet pour exécuter la boucle Event SWT. Je pense que c'est soutenu par la classe d'affichage, une fois que vous avez créé la première instance dans le fil principal, les méthodes statiques fonctionneront comme prévu. Au moins si vous croyez que les docs. De ma compréhension, vous pourrez ensuite appeler Display.Asyncexec (..) Pour exécuter du code dans le fil de l'événement SWT ... C'est comme ça que vous le faites dans Eclipse au moins.
La création de l'instance d'affichage dans le fil principal est la partie délicate! Nous utilisons une classe "bootstrap" générique qui lance le cadre OSGI et nous n'avons aucune idée de SWT ou même d'accès aux classes car ils sont effectivement chargés plus tard par le paquet SWT. Mon idée est d'ajouter une sorte de crochet générique au code bootstrap, que le paquet SWT utilisera pour obtenir sa boucle exécutée par le fil principal. L'astuce est de le faire proprement ...
C'était aussi mon idée initiale. Ensuite, je me demandais si cela n'était pas déjà fourni par Osgi d'une manière ou d'une autre ...
Ce serait bien, mais je soupçonne fortement que Osgi ne sera pas utile. Afaik Osgi crache un tas de threads pour lancer les paquets et ne se souciait pas particulièrement du fil principal. Mais je pourrais me tromper: regarder la spécification pourrait être une bonne idée à ce stade. Si je reçois quelque chose qui pourrait être généralisé, je posterai ici ici.
Juste pour développer: J'ai maintenant obtenu avec succès un paquet SWT Osgi à courir en lui permettant d'injecter sa boucle d'événement dans le fil principal (celui qui commence Osgi) en combinaison avec le -xstartonfirstthread.
J'ai eu le problème que dès que "affichage.sleep ()" a été appelé la fenêtre geler l'application. Si quelqu'un d'autre aime le même problème, la solution qui a fonctionné pour moi devait ajouter: -Xstartonfirstthread au VM au moment de l'exécution.
J'essayais de faire du logiciel de sauvegarde Areca sur mon Mac et de connaître son travail :)
Mon système est: Leopard de neige MacOSX 10.6.2
bye, Daniel w.
J'ai eu le même problème et je l'ai résolu en ajoutant les deux -D32 et -xstartonfirstthread
Cela fonctionne dans Windows? Ah bon? Je vais devoir essayer ça ...