Archive for the ‘netbeans-day’ tag
Własny ApplicationType w VisualVM
Tworzenia prostych rozszerzeń do VisualVM ciąg dalszy, muszę przyznać, że platforma poza paroma dziwnymi zachowaniami jest całkiem przyjemna i klepanie takich prostych rzeczy jest niezłą rozrywką
. Dzisiaj (póki co) ostatni odcinek moich przygód związanych z przygotowywaniem prezentacji na NetBeans Day w Poznaniu. W kilku zwięzłych zdaniach opowiem Wam o dodawaniu własnego ApplicationType i łączeniu tego co stworzymy z kodem stworzonym w poprzednim wpisie.
Możecie pobrać całość w zipie (gotowe do zaimportowania projekty NetBeansowe) lub gotowe do użycia pliki nbm (w update site wpiszcie : http://grejpfrut.org/examples/vvm-modules/updates.xml).
Tak jak poprzednio zaczniemy od implementacji fabryki tworzącej instancję naszej implementacji ApplicationType.
public class GrejpfrutApplicationTypeProvider extends MainClassApplicationTypeFactory {
@Override
public ApplicationType createApplicationTypeFor(Application app, Jvm jvm, String mainClass) {
if (app.isLocalApplication()) {
return new GrejpfrutApplicationType(app.getPid(), mainClass);
}
return null;
}
}
Warto pamiętać, że w zależności od dostępnych informacji zmienna mainClass nie zawsze musi zawierać nazwę głównej klasy.
W tym konkretnym przykładzie aplikacje grejpfrutowe to takie, które zostały uruchomione lokalnie.
Kolejny krok to nieco więcej pisania, ale dalej nic trudnego.
public class GrejpfrutApplicationType extends ApplicationType {
protected final int appPID;
protected final String name;
public GrejpfrutApplicationType(int appPID, String name) {
this.appPID = appPID;
this.name = name;
}
@Override
public String getName() {
return "Grejpfrut "+name;
}
@Override
public String getVersion() {
return "blee.bleee";
}
@Override
public String getDescription() {
return "Application type for Grejpfrut";
}
@Override
public Image getIcon() {
//używamy tej saame ikonki co w poprzednim przykładzie (patrz poprzedni wpis)
return Utilities.loadImage(FirstExamplePluginView.IMAGE_PATH, true);
}
}
Teraz jeszcze zarejestrowanie nowego ApplicationType w klasie Installer (patrz poprzedni post).
public class Installer extends ModuleInstall {
private static GrejpfrutApplicationTypeProvider INSTANCE = new GrejpfrutApplicationTypeProvider();
@Override
public void restored() {
FirstExamplePluginViewProvider.initialize();
ApplicationTypeFactory.getDefault().registerProvider(INSTANCE);
}
@Override
public void uninstalled() {
FirstExamplePluginViewProvider.unregister();
ApplicationTypeFactory.getDefault().unregisterProvider(INSTANCE);
}
}
Wprowadźmy jeszcze jedną małą zmianę w FirstExamplePluginViewProvider, dodając jedną nową metodę.
@Override
protected boolean supportsViewFor(Application app) {
if (ApplicationTypeFactory.getApplicationTypeFor(app) instanceof GrejpfrutApplicationType) {
return true;
}
return false;
}
Stworzona w poprzednim odcinku zakładka będzie się wyświetlała tylko w przypadku gdy zostanie jej przypisany typ GrejpfrutApplicationType.
Czyścimy całość i odpalamy, co się teraz stanie? Jeżeli masz odpalone tylko NetBeans i VisualVM w którym została uruchomiona wtyczka to niczego nie zobaczysz. Dlaczego? Otóż na tyle na ile to rozumiem NetBeansApplicationType i VisualVMApplicationType zostały zarejestrowane przed GrejpfrutApplicationType. VVM przypisuje aplikacji pierwszy ApplicationType który uda mu się do niej dopasować więc nie dochodzi nawet do sprawdzania czy NetBeans i VVM są też grejpfrutami
. Uruchom jakiegoś Eclipse’a ;P wtedy na drzewku Applications pojawi się nowy grejpfrut.
To by było na tyle
jeżeli napotkacie jakieś ładne stactrace’y bawiąc się Shootoutem i moimi źródełkami dajcie znać.
Jeszcze jedna finalna uwaga – testowałem na platformie w wersji 6.01 więc już dość leciwej.
VisualVM Java IDE wars plugin
Pobierz :
- NetBeans IDE 6.1 ub 6.5
- Visual VM .
Potrzebny będzie również kod źródłowy gry Shootout autorstwa Dawida Weissa, orginalna wersja nie pozwalała na osadzenie gry w kontenerach Swingowych, musiałem więc wprowadzić kilka poprawek
. Kod źródłowy dostępny jest tutaj. Aby zbudować jar’a wystarczy rozpakować archiwum i w katalogu shootout wydać polecenie: ant jar-netbeans w shootout/build znajdziecie finalnego jar’a.
Po zainstalowaniu Visual VM (można też użyć tego który znajduje się w Waszym JDK) i uruchomieniu NetBeans IDE możemy przystąpić do pracy. W niektórych miejscach korzystałem z wizardów NetBeansowych więc samo spojrzenie w kod tych próbek może nie dać wam pełnego obrazu jak najszybciej dojść do finalnego efektu
Visual VM to aplikacja stworzona w oparciu o NetBeans Paltform, przeglądając zawartość folderu aplikacji możecie natknąć się na charakterystyczne dla aplikacji NBP nazwy plików i katalogów. Zanim zaczniemy właściwą pracę musimy zarejestrować instację platformy NB, która znajduje się w Visual VM. Oprócz standardowych elementów NB są tam również moduły specyficzne dla Visual VM jak np. VisualVM-Application czy VisualVM-Core.
Aby zarejestrować instancje platformy należy wybrać z menu Tools>NetBeans Plaform i dodać nową platformę (przycisk Add Platform) – wskazujemy na katalog w którym został zainstalowany VisualVM
Rejestracja platformy umożliwi nam nie tylko zapewnienie pełnej zgodności z platformą na której uruchamiany będzie plugin, ale pozwoli również na debugowanie i szybkie uruchamianie tworzonego przez nas rozszerzenia w docelowym środowisku.
Tworzymy nowy projekt wybierając File>New Project>NetBeans Modules i z listy o prawej stronie wybrać Module Suite klikamy Next.
W następnym kroku kreatora wpisujemy nazwę projektu i wybieramy platformę w oparciu o którą będziemy rozwijali nasz zestaw modułów. W poprzednich krokach zarejestrowaliśmy instancję należącą do Visual VM i to właśnie ją wybieramy z listy rozwijanej.
Module Suite jest kontenerem dla modułów które są z jakichś względów są ze sobą powiązane, w wyniku naszych działań powstaną dwa moduły: właściwa wtyczka do VisualVM i drugi będący owijką na shootout.jar. Dlaczego tak? Scenariusz jest bardzo prosty wyobraźcie sobie, że została wydana nowa wersja Shooout i chcielibyśmy mieć ją w naszej wtyczce. Po dokonaniu niezbędnych zmian przez nas, użytkownicy wtyczki musieliby ściągać nie tylko nową wersję gry, ale i samą wtyczkę, którą już przecież mają. Aby więc w pełni wykorzystać zalety modułowości każda biblioteka wykorzystywana przez naszą wtyczkę powinna zostać opakowana w pewne dodatkowe informacje, które pozwolą instancji NetBeans Platform na aktualizację tylko tej konkretnej biblioteki.
Czas więc stworzyć Library Wrapper Module dla Shootout.jar. Klikamy File>New Project>NetBeans Module>Library Wrapper Module w pierwszym kroku kreatora trzeba podać ścieżkę do pliku jar, który opakowujemy i do pliku z licencją na której biblioteka jest/ma być udostępniania. W ostatnim kroku kreatora pojawia się pytanie o codebase, wpisujemy com.dawidweiss.shootout.
O czym jeszcze warto wspomnieć, pierwotnie Shootout.jar miał w manifeście ustawiony parameter Main-Class, który wskazywał na klasę posiadającą metodę main w której uruchamiana była gra. Powodowało to, że wtyczka po umieszczeniu w VisualVM nie działała. Wywalenie tego atrybutu z manifestu załatwiło sprawę. Niestety nie znam się na wnętrznościach NetBeans Platform więc nie jestem w stanie tego sobie wytłumaczyć bardziej racjonalnie.
Zależności w formie LWM mogą być deklarowane przez wszystkie moduły wchodzące w skład nadrzędnego Module Suite.
Mamy już jeden moduł, teraz czas przejść do najważniejszej części tego artykułu – tworzenia właściwej wtyczki do VisualVM.
Tworzymy nowy projekt File>New Project>NetBeans Module>Module, moduł powinien zostać dodany do stworzonego wcześniej Module Suite. W kolejnym kroku wpisujemy codebase : org.grejpfrut.vvm, w NetBeans 6.5 wpisanie poprawnego codebase uzupełnia również pozostałe pola formularza.
Kolejny krok to dodanie zależności, w oknie Projects klikamy prawym na węzeł reprezentujący moduł i wybieramy Properties. Następnie zakładka Libraries musimy mieć zadeklarowane następujące zależności: Module System API, shootout, Utilities API, VisualVM-Application i VisualVM-Core.
W oknie Projects klikamy prawym przyciskiem myszy na węzeł reprezentujący stworzony przed chwilą moduł i wybieramy New>Module Installer. Stworzona klasa Installer i jej dwie metody restored i uninstalled umożliwiają nam wpięcie się w cykl życia tworzonej właśnie wtyczki. Kod z metody restored jest wykonywany w chwili załadowania modułu, jest to najwłaściwsze miejsce aby zarejestrować klasy implementujące rozszerzenia. Natomiast metoda uninstalled jest wywoływana w momentcie gdy moduł jest usuwany ze środowiska lub gdy jest ono wyłączane.
public class Installer extends ModuleInstall {
@Override
public void restored() {
FirstExamplePluginViewProvider.initialize();
}
@Override
public void uninstalled() {
FirstExamplePluginViewProvider.unregister();
}
}
W mojej prezentacji z NetBeans Day możecie znaleźć krótkie omówienie tego co można rozszerzyć w VisualVM, więcej o tym piszę Geertjan w
dokumentacji VisualVM i na swoim blogu. FirstExamplePlugin będzie tworzył dodatkową zakładką, którą użytkownicy będą mogli zobaczyć po połączeniu się do jakiegoś JVMa. W zakładce tej będą się działy rzeczy różne
.
Należy teraz stworzyć klasę FirstExamplePluginViewProvider, jak sugeruje nazwa, klasa ta będzie odpowiedzialna za “produkcję” instancji klasy FirstExamplePluginView.
class FirstExamplePluginViewProvider extends DataSourceViewProvider {
//prosty singleton
private static DataSourceViewProvider instance = new FirstExamplePluginViewProvider();
static void initialize() {
//rejestrujemy instancję FirstExamplePluginViewProvider w zarządcy widoków
DataSourceViewsManager.sharedInstance().addViewProvider(instance, Application.class);
}
static void unregister() {
//wyrejestrowujemy instancję FirstExamplePluginViewProvider w zarządcy widoków
//metoda jest wywoływana podczas odinstalowywania modułu i wyłączania środowiska
DataSourceViewsManager.sharedInstance().removeViewProvider(instance);
}
@Override
protected DataSourceView createView(Application app) {
//tworzy instancję widoku
return new FirstExamplePluginView(app);
}
}
Klasa ta to prosty singleton, który w czasie inicjalizacji modułu (initialize) dodaje do DataSourceViewManager’a swoją instancję. Najważniejszą metodą w tej klasie jest createView, która to tworzy naszą zakładkę.
Kopiując poniższy kod należy pamiętać o wskazaniu poprawnej ścieżki do ikonki wyświetlanej w etykiecie zakładki:
org/grejpfrut/vvmnbd/example/grejpfrut.png – szczegóły będą widoczne w źródłach.
public class FirstExamplePluginView extends DataSourceView {
private DataViewComponent dvc;
//sciezka do ikony, ktora bedzie wyswietlana w zakładce zakładki
public final static String IMAGE_PATH = "org/grejpfrut/vvmnbd/example/grejpfrut.png";
public FirstExamplePluginView(Application app) {
//tytuł zakładki i ikona
super(app, "Java IDE wars plugin", new ImageIcon(Utilities.loadImage(IMAGE_PATH)).getImage(), 3, true);
}
@Override
protected DataViewComponent createComponent() {
//tworzenie elementów widoku
JEditorPane generalDataArea = new JEditorPane();
generalDataArea.setBorder(BorderFactory.createEmptyBorder(4, 8, 4, 8));
JPanel details1Panel = new JPanel(new BorderLayout());
ShootoutBoard board = new ShootoutBoard(new ShootoutUtilities().getEnemyFactory(), details1Panel);
details1Panel.add(board, BorderLayout.CENTER);
details1Panel.setBackground(Color.GRAY);
details1Panel.setCursor(Cursor.getPredefinedCursor(Cursor.CROSSHAIR_CURSOR));
//osadzanie stworzonych kontrolek w kontenerze VisualVM
DataViewComponent.MasterView masterView = new DataViewComponent.MasterView("Java IDE wars plugin", null, generalDataArea);
//konfiguracja widoku
DataViewComponent.MasterViewConfiguration masterViewConfiguration = new DataViewComponent.MasterViewConfiguration(false);
//tworzymy właściwy komponent, który bedzie wyswietlany w VVM
dvc = new DataViewComponent(masterView, masterViewConfiguration);
//tworzymy panel z planszą gry
DataViewComponent.DetailsView details = new DataViewComponent.DetailsView("", "Detale tego okienka", 10, details1Panel, null);
//umieszczamy go w odpowiednim miejscu
dvc.addDetailsView(details, DataViewComponent.TOP_LEFT);
//gra ma być domyślnie ukryta
dvc.hideDetailsArea(DataViewComponent.TOP_LEFT);
return dvc;
}
}
Po uzupełnieniu importów, możemy uruchomić nasz plugin aby tego dokonać należy w oknie Projects kliknąć prawym na węzeł reprezentujący nasz Module Suite i wybrać “Run” lub “Debug”. NetBeans uruchomi teraz nasz plugin w platformie która wybraliśmy dla naszych modułów. Teraz klikamy w dowolny proces JVM, który jest wyświetlany na drzewku Applications i powinna się naszym oczom ukazać zakładka z grejpfrutem, po kliknięciu “Details” powinna już rozpocząć się strzelanina
.

Kompletne źródła już wkrótce, po tym jak skończe drugą cześć “Własny ApplicationType”.
Wszystko oparte na serii artykułów Getting Started Extending VisualVM autorstwa Geertjana Wielengi.
Poznań NetBeans Day : Podsumowanie
Kurz opadł już jakiś czas temu
teraz zbieramy jeszcze materiały od prelegentów, robimy finalne rozliczenia, a ja (osobiście) sprzątam kod mojego pluginu do VisualVM, który mam nadzieje w tym tygodniu opublikować.
Kilka słów podsumowania, z informacji które udało mi się zebrać wynika, że obie edycje odwiedziło w sumie około 140 osób (80 Gdańsk, około 60 w Poznaniu). Kurcze, wydaje się, że nie codzień jest okazja posłuchać tak świetnych specjalistów, ale wychodzi na to, że dobry poziom merytoryczny to nie wszystko…
Niestety nie byłem w stanie obejrzeć wszystkich poznańskich prezentacji, ominął mnie występ Geertjana Wielengi który omawiał podstawy NetBeans Platform. Nie mogę też za wiele powiedzieć o prezentacji Adam Kędziory bo ze względu na różne organizacyjne bzdury musiałem siedzieć przed salą. Bardzo podobała mi się prezentacja Toni’ego Epple, który pokazywał przykłady produkcyjnych wdrożeń NBPlatform. Jestem ciekaw czy ktoś próbował portować aplikację Eclipse RCP na NBPlatform, mechanizmy w środku działają na podobnej zasadzie, ale w przypadku zaawansowanych kontrolek może nie być różowo. Ogromne wrażenie zrobił na mnie Adam Bien (rzeczywiście trzech Adamów na jednej konferencji to całkiem sporo
) generalnie jestem umiarkowanym fanem live-coding, ale poczucie humoru i dynamizm z jakim AB przeprowadził słuchaczy przez arkana NetBeans 6.5 jest godne podziwu.
Tyle merytorycznie… chciałem podziękować chłopakom ze Szczecin JUG, którzy przejechali całkiem spory kawałek żeby się w Poznaniu pojawić, mam nadzieje, że piwo w Stajence wypaliło
. Były też osoby z Rzeszowa, Aten
no i oczywiście z Poznania (najwięcej z UAM). Oddzielne podziękowania muszą powędrować do koła naukowego studentów informatyki UAM, bez was chłopaki byłaby totalna klapa.
O NetBeans Day napisało już kilka osób:
- Geerthan Wielenga – “Poznan & Gdansk: NetBeans Day, Poland”
- Toni Epple – “NetBeans Days in Gdansk and Poznan” (Tony zrobił również kilka świetnych zdjęć, link dostępny w jego wpisie)
- Adam Bien – opisał swoje wrażenia tutaj i tutaj
- Jacek Laskowski – “Wrażenia po NetBeans Day 2008 w Gdańsku”
- Łukasz Stachowiak – “Po NetBeans day Poznań”
- Leszek Gruchała – “Wrażenia z NetBeans Day w Poznaniu” – (dzięki za słowa krytyki, postaram się coś zrobić z moją “żywością”
) - Miroslav Kopecky – “Poland – NetBeans Day Success”
Miłe jest też to, że nasza inicjatywa została zauważona w portalu java.net
.
Dzięki staraniom Macieja Biłasa, Toniego Epple i Bartka Łopatki Poznań NetBeans Day zostało całkiem nieźle udokumentowane, dzięki.

Geertjan Wielenga opowiada o podstawach NetBeans Platform

Adam Kędziora mówił o swoich doświadczeniach w tworzeniu aplikacji w NetBeans Platform, oraz o uczestnictwie w NetBeans Innovators Grant.

Krótka przerwa na poczęstunek, soczek z grejpfruta, paluszki i ciastka.

Autor tego skromnego bloga, w tle logo Poznań JUG.

Karol Harezlak przygotowuje się do swojej prezentacji.

Geertjan z pamiątkowym kubkiem Poznań JUG.

Toni w mówił o przenoszeniu istniejących aplikacji na NetBeans Platform.

Pan Epple również otrzymał pamiątkowy kubek prelegenta
.

Adam Bien według większości uczestników najbardziej interesująca prezentacja konferencji.

Od lewej: Karol Harezlak, Geertjan Wielenga, Łukasz Stachowiak, Toni Epple.

