Spring DM

[Gast2]

Hallo,

ich hab mal ein bischen versucht mich in Spring DM einzulesen ...
1. Mir ist augefallen, dass in der dokumentation immer die Versions nummer hinten fehlen?
Also anstatt http://www.springframework.org/schema/osgi/spring-osgi-1.2.xsd steht nur
http://www.springframework.org/schema/osgi/spring-osgi.xsd
[XML]
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans
xmlns="http://www.springframework.org/schema/osgi"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/osgi
http://www.springframework.org/schema/osgi/spring-osgi.xsd
Index of /schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">

<service id="simpleServiceOsgi" ref="simpleService"
interface="org.xyz.MyService" />

</beans:beans>
[/XML]

hat das einen bestimmten Vorteil?
2. Habe ich mir hier mal angeschaut
Eclipse Magazin 16 - Die Stärke der Drei
wie ich einen Service in die Registry mache!
Also ich habe in meinem Implementation package folgende xml
[XML]
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlnssgi="http://www.springframework.org/schema/osgi"
xsi:schemaLocation=
"http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
Index of /schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-1.2.xsd">

<bean id="myServiceImpl" class="impl.service.MyServiceImpl" />

<osgi:service ref="myServiceImpl" interface="inter.MyService"/>
</beans>
[/XML]
Und in meinem Client welcher den Service benutzen soll
[XML]
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlnssgi="http://www.springframework.org/schema/osgi"
xsi:schemaLocation=
"http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
Index of /schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-1.2.xsd">

<bean id="myListener" class="client.MyListener"/>

<osgi:reference id="myService" interface="inter.MyService">
<osgi:listener bind-method="onBind" unbind-method="onUnbind" ref="myListener"/>
</osgi:reference>
</beans>
[/XML]
wie lese ich jetzt den Service aus der registry damit ich ihn in meiner UI benutzen kann?
Und wie implementiere ich den Listener, der soll überwachen wann der Service aktiviert oder deaktiviert wird?Oder?

Danke schon mal=)

 

[Noctarius]

Dein Service steckt jetzt in einem Bean namens "myService" also ganz normal wie jedes andere Bean auch. Per Type (mit Interface) oder per Qualifier oder per Name. Geht alles fest im XML verdrahtet als auch über die Autowired Annotation.

 

[Gast2]

Dein Service steckt jetzt in einem Bean namens "myService" also ganz normal wie jedes andere Bean auch. Per Type (mit Interface) oder per Qualifier oder per Name. Geht alles fest im XML verdrahtet als auch über die Autowired Annotation.

Ja mach ich das mit @Autowired direkt in die UI rein ???
Unf ür was brauch ich den Listener?

 

[maki]

Sag mal, willst du das komplett aus dem Forum hier lernen?

Das Ding ist sehr gut dokumentiert, Spring halt

 

[Gast2]

Sag mal, willst du das komplett aus dem Forum hier lernen?

Das Ding ist sehr gut dokumentiert, Spring halt

Naja so ganz komplett ja nicht soviele Fragen waren es dazu jetzt auch nicht^^...
Mir fehlt eigentlich hauptsächlich wo ich den Service jetzt rein hämmere?Direkt in die UI? In eine Zwischenschicht?Controller?Model? ka...???:L

 

[Noctarius]

Naja das kann man sich doch überlegen.

Ins Modell bestimmt nicht, immerhin ist das Modell das Datenmodell an sich, da passt so richtig rein.
In die UI? Naja im MVC Ansatz versucht man die GUI doch immer möglichst abhängigkeitsfrei zu bekommen, passt also auch nicht so richtig.
Bleibt übrig? Genau der Controller bzw die Schicht mit den Businessabläufen.

 

[Gast2]

Naja das kann man sich doch überlegen.

Ins Modell bestimmt nicht, immerhin ist das Modell das Datenmodell an sich, da passt so richtig rein.
In die UI? Naja im MVC Ansatz versucht man die GUI doch immer möglichst abhängigkeitsfrei zu bekommen, passt also auch nicht so richtig.
Bleibt übrig? Genau der Controller bzw die Schicht mit den Businessabläufen.

Was heißt die UI abhängigkeitsfrei zu bekommen?? Die UI hat doch immer abhängigkeiten entweder zum Controller oder zum Model? Das Model ist doch eher abhängigkeitsfrei !!!
Ja für mich war der Service die Businessschicht darum bin ich etwas verwirrt.

 

[Noctarius]

Ich meinte damit frei von Abhängigkeiten zur Businesslogik. Ein View ist eben ein View und hat keine großen Daten aufzubereiten.

 

[Gast2]

Ich meinte damit frei von Abhängigkeiten zur Businesslogik. Ein View ist eben ein View und hat keine großen Daten aufzubereiten.

Wie gesagt der Unterschied ist mit gerade noch nicht klar...
Wenn ich einen Button drücke und es soll etwas ausgeführt werden.
Ob ich in der View
jetzt

serviceA.machWas();

oder

controller.machWas();

public class Controller{

public void machWas(){
serviceA.machWas();
}

macht doch keinen Unterschied? Oder übersehe ich was?

 

[maki]

Oder übersehe ich was?

MVC/MVP vielleicht?

Wenn du "Service" sagst, muss doch klar sein dass es in die Application-/Business Tier gehört.

Ein Listener ist soz. der Activator.

IMHO solltest du dir gleich die 2.x Version aneignen, kommt bald als Release.

 

[Noctarius]

Klar macht es keinen Unterschied, aber ein View macht genau das was der Name sagt, Anzeigen. Nicht verarbeiten.

Das MVC Pattern ist ja auch kein Zwang, weil es anders nicht geht, es ist einfach eine Art der Programmierung um Aspekte eines Programms von einander zu trennen. Businesslogik ist ein Aspekt, wie das Ganze später aussehen (angezeigt werden) soll ein anderer.
Der Vorteil, Austausch des Ausgabemoduls ohne Verlust oder Codeduplizierung von Funktionen.

 

[Gast2]

MVC/MVP vielleicht?

Wenn du "Service" sagst, muss doch klar sein dass es in die Application-/Business Tier gehört.

Ein Listener ist soz. der Activator.

IMHO solltest du dir gleich die 2.x Version aneignen, kommt bald als Release.

Ja ich wollte mir das Spring3 Buch kaufen, mal schauen ob die OSGi Sachen auch drin sind.
Auf jeden Fall les ich die Doku nochmal durch. Ja klar ist der Service im Business Tier auf dem Server,
aber wie das genau über remote funktioniert muss ich mir nochmal genau durchlesen... Aber mir gehts darum, dass ich noch nicht ganz verstanden habe ob die UI eine Abhänigkeit zum Controller oder zum Service hat... Hab noch nicht ganz den Unterschied gesehen!!! Klar wenn der Controller die Daten noch manipuliert versteh ich es, dachte das macht nur der Service... Wenn der Controller die Daten aufbereitet für die UI versteh ich es auch. Aber wenn der Controller nur die Service Methode ausführt, fehlt mir der Zusammenhang was der Vorteil ist... Ich hoffe ihr versteht mich ein wenig ^^!!! Schwer die Sache zu beschreiben!


Okay die Theorie ist ja ganz schön ^^... Aber mal ein praktischeres Beispiel wäre eventuell net ganz schlecht, dass ich die Sache endlich mal komplett versteh.
z.B. Ein Service holt alle Kunden einer Anwendung und eine View(Button druck) soll sie anzeigen..
Wie würde dann die Sache aussehen:
Service

public class KundenServiceImpl implements KundenService{
		
		public List<Kunde> getKunden(){
			new ArrayList<Kunde>();
		}
	}

Controller:

	public class KundenController{
		KundenService service;
		
		public List<Kunde> getKunden(){
			service.getKunden(); 
		}
	}

So jetzt fehlt mir der Zusammenhang:
Befüllt der Controller jetzt das Model und dieser benachrichtigt die registrierten Views??:
BeispielModel

	public class KundenModel{
		List<Kunde> kunden;
		
		public void addKunde(Kunde k){
			kunden.add(k);
			fireEvent();
		}

                public void validateModel(){

                }

                //usw.
	}

Oder die view holt sich selber die Daten
Z.b man drückt auf einen Button

	public class View{
		KundenController controller;
		
		public void pressButton(){
			List<Kunde> list = controller.getKunden;
		}
	}

oder eher sowas

	public class View implments KundenListener{
		KundenController controller;
		
		public void pressButton(){
			controller.getKunden;
		}
                
               //Beispiel Event 
               public void changeKunde(KundenEvent ...){
               //....... 
               refreshGUI();
                }
	}

 

[Noctarius]

class Service {
  public String simpleService() { ... }
}

class Model {
  private String value;
  public String getValue() { return value; }
  public void setValue(String value) { this.value = value; }
}

class Controller {
  public View execute(SomeKindOfRequestContext context) {
    Service service = Utils.getServiceReferenceFromSomewhere();
    Model model = new Model();
    model.setValue(service.simpleService());

    context.addAttribute("model", model);

    return viewController.getView("xyz");
  }
}

class View {
  public void execute(SomeKindOfRequestContext context) {
    Model model = (Model) context.getAttribute("model");
    Window window = Utils.createWindow();
    Label label = Utils.createLabe();
    label.setValue(model.getValue());
    window.add(label);
    window.show();
  }
}

Ganz hässlicher Pseudocode wie ein Service im MVC genutzt werden würde. Der View hat keine Abhängigkeiten zum Controller oder Service, wohl aber zum Model.

 

[Gast2]

class Service {
  public String simpleService() { ... }
}

class Model {
  private String value;
  public String getValue() { return value; }
  public void setValue(String value) { this.value = value; }
}

class Controller {
  public View execute(SomeKindOfRequestContext context) {
    Service service = Utils.getServiceReferenceFromSomewhere();
    Model model = new Model();
    model.setValue(service.simpleService());

    context.addAttribute("model", model);

    return viewController.getView("xyz");
  }
}

class View {
  public void execute(SomeKindOfRequestContext context) {
    Model model = (Model) context.getAttribute("model");
    Window window = Utils.createWindow();
    Label label = Utils.createLabe();
    label.setValue(model.getValue());
    window.add(label);
    window.show();
  }
}

Ganz hässlicher Pseudocode wie ein Service im MVC genutzt werden würde. Der View hat keine Abhängigkeiten zum Controller oder Service, wohl aber zum Model.

Mhm auf jeden Fall danke schon mal... Sieht aber eher nach Web Client aus! Oder?!
Oder was ist für dich SomeKindOfRequestContext??
Und wann würde die execute augerufen werden von view und controller?

 

[Noctarius]

Das ist einfach ein Pseudo MVC System. SomeKindOfRequestContext ist sowas wie HttpServletRequest welches die Daten zwischen dem Controller und dem View verbindet.

Die beiden execute Methoden werden vom unterliegenden "Framework" aufgerufen.

Sagen wir du klickst auf den Button "Daten abrufen" dann weiß das Framework hier den Controller muss ich fragen. Es erstellt einen RequestContext und ruft die Methode des entsprechenden Controllers auf. Dieser tut seine Arbeit, schiebt die Daten in den RequestContext und sucht am Ende noch irgendwie raus welchen View er gerne hätte und gibt diesen zurück.

Das Framework hat nun die Daten im RequestContext und den View zum Controller. Also ruft es die execute Methode des View auf und schiebt den selben RequestContext rein wie beim Controller.

---------------------

Dies ist ein Beispiel für das Prinzip von MVC und nicht wie es in Eclipse RCP genau aussieht. Es geht darum dir zu zeigen wie Daten verarbeitet und wie angezeigt werden und, dass der View keine Abhängigkeit zum Controller haben muss.

Alternativ könnte auch nur Controller.execute aufgerufen werden und dieser ruft wieder rum seinerseits den View direkt auf. Der Effekt wäre der selbe, die lose Kopplung der Module aber nicht mehr so sauber.

 

[Gast2]

Das ist einfach ein Pseudo MVC System. SomeKindOfRequestContext ist sowas wie HttpServletRequest welches die Daten zwischen dem Controller und dem View verbindet.

Die beiden execute Methoden werden vom unterliegenden "Framework" aufgerufen.

Sagen wir du klickst auf den Button "Daten abrufen" dann weiß das Framework hier den Controller muss ich fragen. Es erstellt einen RequestContext und ruft die Methode des entsprechenden Controllers auf. Dieser tut seine Arbeit, schiebt die Daten in den RequestContext und sucht am Ende noch irgendwie raus welchen View er gerne hätte und gibt diesen zurück.

Das Framework hat nun die Daten im RequestContext und den View zum Controller. Also ruft es die execute Methode des View auf und schiebt den selben RequestContext rein wie beim Controller.

---------------------

Dies ist ein Beispiel für das Prinzip von MVC und nicht wie es in Eclipse RCP genau aussieht. Es geht darum dir zu zeigen wie Daten verarbeitet und wie angezeigt werden und, dass der View keine Abhängigkeit zum Controller haben muss.

Alternativ könnte auch nur Controller.execute aufgerufen werden und dieser ruft wieder rum seinerseits den View direkt auf. Der Effekt wäre der selbe, die lose Kopplung der Module aber nicht mehr so sauber.

Ich hab halt Beispiele gesehen wo die View den Controller kennt und welche wo sie ihn nicht kennt! Darum wollt ich mal nachfragen ^^
Ja im Prinzip ist mir die Sache klar aber ab und zu hakts noch, daher war ich mir nicht sicher wo genau den service reinhängen aber thx hat mich schon mal weiter gebracht ...
Wenn ich mal eine richtige Vorstellung hab kann ich ja mal einen Beispiel Ablauf posten und dann kannst mal dein Senf D) dazu abgeben obs passt

Joa mit so einem Kontext hab ich es noch nicht gesehen kenns eher so
rich client 2.0 Using the MVC Pattern in Eclipse Applications
Darum war die Frage mit den Listenern ^^usw..

 

[Noctarius]

Uff ok Eclipse scheint eine ganz eigene Vorstellung von MVC zu besitzen Oo

Frag da am besten mal unseren Eclipse Experten, der kann dir da bestimmt helfen. Sowas geht am besten wenn man im Topic klar Eclipse RCP hinterlässt ^^ Mit Spring DM hat der nämlich nichts am Hut

 

[Gast2]

Uff ok Eclipse scheint eine ganz eigene Vorstellung von MVC zu besitzen Oo

Frag da am besten mal unseren Eclipse Experten, der kann dir da bestimmt helfen. Sowas geht am besten wenn man im Topic klar Eclipse RCP hinterlässt ^^ Mit Spring DM hat der nämlich nichts am Hut

ja sind ein bischen vom Weg abgekommen ... Ursprünglich waren es ja andere Fragen, hab mir jetzt mal das Heft bestellt damit ich den ganen Quellcode habe vielleicht wird es dann klarer wo der Service genau hinmuss, weil in dem Heft schreibt er den Service direkt in den Activator rein, aber leider fehlen dann ein paar Code Stücke^^... z.B. vom Spring Listener und wo und wie er ihn ausliest, ich hoffe das dies meine Fragen beantwortet ^^ aber danke nochmal...

Vielleicht noch zu der Frage
1.Was der Unterschied ist wenn man die Version hinschreibt und ohne? http://www.springframework.org/schem...g-osgi-1.2.xsd
vs
http://www.springframework.org/schem...pring-osgi.xsd
?

 

[Noctarius]

In Spring definiert man den referenzierten Service im XML und lässt ihn sich als Bean injizieren. Fertig. In Spring DM macht man eh keinen eigenen Activator sondern lässt den ganzen Kram von Spring erledigen.
Das einzige was man machen kann sind Beans die bestimmte Interfaces implementieren, welche zu gewissen Zeiten (z.B. beim Context-Startup) aufgerufen werden (InitializingBean z.B.)

 

[Gast2]

In Spring definiert man den referenzierten Service im XML und lässt ihn sich als Bean injizieren. Fertig. In Spring DM macht man eh keinen eigenen Activator sondern lässt den ganzen Kram von Spring erledigen.
Das einzige was man machen kann sind Beans die bestimmte Interfaces implementieren, welche zu gewissen Zeiten (z.B. beim Context-Startup) aufgerufen werden (InitializingBean z.B.)

ja klar lass ich mir das Zeug von Spring injizieren in plugins hat man ja einen Activator, un in dem Bsp. wird er da halt reingemacht. Naja ich wart mal bis das Heft kommt, dann bekomm ich eine genauerer Vorstellung bis dahin kann ich auch mal so versuchen ob das spring OSGi funktioniert.

 

[Gast2]

Mhm also,

ich hab hier meinen service
[XML]
<bean id="myService"
class="service.MyServiceImpl"
init-method="start"
destroy-method="stop"/>

<osgi:service ref="myService" interface="service.MyService"/>[/XML]

und hier eine reference
[XML]
<osgi:reference id="myService" interface="service.MyService"/>
[/XML]

Aber der Service ist immer null die start und stop methode wird auch nicht aufgerufen...

Hier ist die Ausgabe von Spring

Jan 25, 2010 7:31:40 PM org.springframework.osgi.extender.internal.activator.ContextLoaderListener start
INFO: Starting [org.springframework.osgi.extender] bundle v.[1.1.2.B]
Jan 25, 2010 7:31:40 PM org.springframework.osgi.extender.internal.support.ExtenderConfiguration <init>
INFO: No custom extender configuration detected; using defaults...
Jan 25, 2010 7:31:40 PM org.springframework.scheduling.timer.TimerTaskExecutor afterPropertiesSet
INFO: Initializing Timer
Jan 25, 2010 7:31:40 PM org.springframework.osgi.extender.support.DefaultOsgiApplicationContextCreator createApplicationContext
INFO: Discovered configurations {osgibundle:/META-INF/spring/*.xml} in bundle [Client (client; singleton:=true)]
Jan 25, 2010 7:31:40 PM org.springframework.context.support.AbstractApplicationContext prepareRefresh
INFO: Refreshing org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext@45e228: display name [OsgiBundleXmlApplicationContext(bundle=client, config=osgibundle:/META-INF/spring/*.xml)]; startup date [Mon Jan 25 19:31:40 CET 2010]; root of context hierarchy
Jan 25, 2010 7:31:41 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from URL [bundleentry://106.fwk10039797/META-INF/spring/client-context.xml]
Jan 25, 2010 7:31:42 PM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory
INFO: Bean factory for application context [org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext@45e228]: org.springframework.beans.factory.support.DefaultListableBeanFactory@704cf5
Jan 25, 2010 7:31:42 PM org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager findServiceDependencies
INFO: Adding OSGi service dependency for importer [&myService] matching OSGi filter [(objectClass=service.MyService)]
Jan 25, 2010 7:31:42 PM org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager findServiceDependencies
INFO: OsgiBundleXmlApplicationContext(bundle=client, config=osgibundle:/META-INF/spring/*.xml) is waiting for unsatisfied dependencies [[&myService]]
Jan 25, 2010 7:31:51 PM org.springframework.osgi.extender.internal.activator.ContextLoaderListener shutdown
INFO: Stopping [org.springframework.osgi.extender] bundle v.[1.1.2.B]
Jan 25, 2010 7:31:51 PM org.springframework.scheduling.timer.TimerTaskExecutor destroy
INFO: Cancelling Timer

Also die Aussage macht mich ein bischen stutzig

INFO: OsgiBundleXmlApplicationContext(bundle=client, config=osgibundle:/META-INF/spring/*.xml) is waiting for unsatisfied dependencies [[&myService]]

 

[Noctarius]

Ja heißt die Service-Referenz kann nicht aufgelöst werden. Klingt irgendwie nach einer zyklischen Abhängigkeit unterhalb der Bundles.

 

[Gast2]

Ja heißt die Service-Referenz kann nicht aufgelöst werden. Klingt irgendwie nach einer zyklischen Abhängigkeit unterhalb der Bundles.

Ah nee er startet mein Bundle nicht das mit der Referenz auflösen war ein guter Tipp...
Wenn ich mein Bundle nämlich programmatisch starte klappts...

EDIT: Witzig einmal das Bundle gestartet klappts immer komisch...

 

[Noctarius]

Ich hab schon viel erlebt mit dem Spring DM Von daher, ich hab am Anfang auch etwas gekämpft aber irgendwann kennt man die Fehler(-meldungen)

 

[maki]

Würde immer das depends-on attribut nutzen, sonst kann es schon mal sein dass es zufällig mal geht und dann wieder nciht.
Bei solchen Fehlern immer die Abhängigkeiten unter den bundles genauer ansehen

 

[Noctarius]

Japp das auch. Wenn man einen Service nicht sofort benötigt kann man der Reference auch sagen, dass dieser zur Zeit der AppContext Load noch nicht bestehen muss.

 

[Gast2]

Würde immer das depends-on attribut nutzen, sonst kann es schon mal sein dass es zufällig mal geht und dann wieder nciht.
Bei solchen Fehlern immer die Abhängigkeiten unter den bundles genauer ansehen

Meinst du beim <osgi:service> oder <osgi:reference>?? Denk mal 2teres, aber weiß grad nicht wirklich was eintragen...

 

[maki]

Meinst du beim <osgi:service> oder <osgi:reference>?? Denk mal 2teres, aber weiß grad nicht wirklich was eintragen...

u.U. bei beidem, je nachdem

Musst schon wissen wie die Abhängigkeiten in deinem Projekt sind, das ist sehr wichtig bei OSGi, mit oder ohne SpringDM, mit SpringDM wird es imho leichter.

 

[Gast2]

u.U. bei beidem, je nachdem

Musst schon wissen wie die Abhängigkeiten in deinem Projekt sind, das ist sehr wichtig bei OSGi, mit oder ohne SpringDM, mit SpringDM wird es imho leichter.

Aber da ich ja gerade nur ein Service hab kann es ja auch keine Abhängigkeiten zu anderen Servicen geben^^...
Oder könnte ich bei osgi:reference das notwendige bundle eintragen?

 

[maki]

Oder könnte ich bei osgi:reference das notwendige bundle eintragen?

Naja... bis auf das OSGi-Extender (weil keine Packages exportiert werden) sollte kein Bundle was von anderen Bundles wissen, packages reichen & sind viel flexibler.

 

[Gast2]

Naja... bis auf das OSGi-Extender (weil keine Packages exportiert werden) sollte kein Bundle was von anderen Bundles wissen, packages reichen & sind viel flexibler.

Okay gut zu wissen.
Hab mich schon immer gewundert wenn ich ein spring bundle in die dependendy aufgenommen wurde, der ganez Code rot wurde und Fehler angezeigt wurden. Muss ich mal mit imported Package versuchen.
Aber warum soll das flexibler sein?
Also bei eclipse plugins wird das meisten über plugins abhänigkeiten geregelt, gibt auch nette Funktionieren die dir dann zyklische Abhängikeiten oder unbenutzte Plugins aufzeigen.

 

[maki]

Aber warum soll das flexibler sein?

Packages sind viel fein granularer als Bundles

Könntest ja mehrere Bundles haben die verschiedene Versionen der Packages exportieren.
Ausserdem kannst du mit Packages auch Fragmente nutzen, Bundles sind eben sehr grob... und wenn ein Bundle ein anderes beim Namen + Version kennt, ist das nciht sehr flexibel

 

[Noctarius]

Die Extention Points von Eclipse sind ein erweitertes Konzept von der OSGi Services. Intern musst du aber um z.B. das Interface des Services zu nutzen aus einem Bundle das Package, in welchem sich das Interface befindet, exportieren und im Bundle, welches das Interface nutzen soll, dieses Package wieder importieren.

edit:
Außerdem kannst du mit den Package Im- und Exports auch nur Teile des Bundles freigeben und so Leute davon abhalten interne Klassen zu nutzen.
Wäre z.B. im SUN JRE gut für die ganzen com.sun.* Klassen

 

[Gast2]

Die Extention Points von Eclipse sind ein erweitertes Konzept von der OSGi Services. Intern musst du aber um z.B. das Interface des Services zu nutzen aus einem Bundle das Package, in welchem sich das Interface befindet, exportieren und im Bundle, welches das Interface nutzen soll, dieses Package wieder importieren.

edit:
Außerdem kannst du mit den Package Im- und Exports auch nur Teile des Bundles freigeben und so Leute davon abhalten interne Klassen zu nutzen.
Wäre z.B. im SUN JRE gut für die ganzen com.sun.* Klassen

Ich meinte nicht die Extention Points... z.B. das swt jar du importierst ja nicht alle package des swt.jar sondern nimmst das Bundle mit in die dependency auf was eclipse teilweise schon automatisch beim Anlegen eines UI Bundle macht. Da werden keine extension point oder import packages gemacht. Und klar wenn du ein Bundle aufnimmst kannst muss dieses die Klassen exportieren. Aber du musst nichts explizt impoertieren. Du kannst in deinem anderen Bundle einfach die exportieren package verwenden.

 

[Noctarius]

Dann kompilier das Plugin mal und schau in das JAR in das File /META-INF/MANIFEST.MF und schau mal nach was da alles importiert wird an Packages. Vermutlich macht Eclipse das nur großteils automatisch (normalerweise) aber eben nicht, wenn die Abhängigkeiten nur im Late-Bind (z.B. AppContext) definiert sind.

 

[Gast2]

Dann kompilier das Plugin mal und schau in das JAR in das File /META-INF/MANIFEST.MF und schau mal nach was da alles importiert wird an Packages. Vermutlich macht Eclipse das nur großteils automatisch (normalerweise) aber eben nicht, wenn die Abhängigkeiten nur im Late-Bind (z.B. AppContext) definiert sind.

Versteh grad nicht auf was du hinaus willst?
Also wenn ich ein eclipse RCP mit View erstelle dann hab ich automatisch ein required bundle org.eclipse.ui. Und wenn ich dann in das hineinschaue

Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.2.0,4.0.0)
 ",org.eclipse.swt;bundle-version="[3.5.0,4.0.0)";visibility:=reexport
 ,org.eclipse.jface;bundle-version="[3.5.0,4.0.0)";visibility:=reexpor
 t,org.eclipse.ui.workbench;bundle-version="[3.5.0,4.0.0)";visibility:
 =reexport,org.eclipse.core.expressions;bundle-version="[3.4.0,4.0.0)"

Export-Package: org.eclipse.ui.internal;x-internal:=true

Aber hab keine importierten package. Aber ich kann in meinem oben erzeugten Bundle alle package Klassen von SWT/Jface verwenden^^...

 

[Noctarius]

Ja ok weil Required-Bundle automatisch alle exportierten Packages des Bundles importiert.

 

[Gast2]

Ja ok weil Required-Bundle automatisch alle exportierten Packages des Bundles importiert.

Ja das meinte ich dich vorher, dass eclipse nicht einzelne package importiert so wie maki vorgeschlagen, sondern dass die (meistens) das ganze Bundle nehmen.

 

[maki]

Ja das meinte ich dich vorher, dass eclipse nicht einzelne package importiert so wie maki vorgeschlagen, sondern dass die (meistens) das ganze Bundle nehmen.

Eclipse kann beides, musst imh halt sagen wie du es möchtest.

Hier noch was Wildcard dazu zu sagen hat: http://www.java-forum.org/plattformprogrammierung/93316-fragmente-fuer-bibliotheken.html

 

[Gast2]

Eclipse kann beides, musst imh halt sagen wie du es möchtest.

Hier noch was Wildcard dazu zu sagen hat: http://www.java-forum.org/plattformprogrammierung/93316-fragmente-fuer-bibliotheken.html

Ja ok interessant...
Muss nochmal gescheit nachlesen was genau Fragemente sind und machen...

 

[Gast2]

Also ich importiere das package org.springframework.osgi.config;version="1.1.2.B", damit ich den
org.springframework.osgi.config.OsgiServiceLifecycleListenerAdapter verwenden kann danach ist mein ganzes projekt rot und bei sämtlichen import steht cannot be resolved. So etwas shcon mal gehabt?

EDIT:sieht nach einem internen package aus, find ich konmisch dass ich es dann trz angezeigt bekomm
OsgiServiceLifecycleListenerAdapter - Spring Community Forums

 

[Gast2]

Hallo zusammen,

ich hätte nochmal eine Konzept Frage.
Es gibt ein Bundle wo die DB Klassen Impl drin sind und deren Interface. Die konkrete Implmentierung nimmt dann z.B. das Mapping für hibernate sonstiges vor.
Jetzt zu meiner Frage mit Beispiel:
Sagen wir haben ein interface Artikel und eine ArtikelImpl. Mit jede Menge Membervariablen.
Wie legt man dafür jetzt am besten ein neues Objekt an?
1.Bietet das Bundle einen Service an mit einer Methode wo die ganzen Membervariablen füllt.

Artikel createArtikel(String artikelnr, String name ........)

?
2.Bietet das Bundle einen Service an, welches nur das Objekt zurückliefert und jedes Bundle selber die Daten füllt.

Artikel createArtikel()

3. Oder ertsell ich eine Spring Bean scope="protype", und einen Service damit die anderen Bundle einfach auf das Bean zugreifen?

Danke

 

[Noctarius]

Factory Pattern

PS: Ich würde 2 Bundles machen, eines für Interfaces und eines für die Implementierung. So kann man das Impl-Bundle updaten ohne die Abhängigkeiten von anderen Bundles zu den Interfaces zu entreißen.

 

[Gast2]

Factory Pattern

Also variante 2 ?
Bin mir jetzt nicht ganz sicher
Die xml
[XML]
<bean id="artikel" class="impl.ArtikelImpl" scope="prototype"/>
<bean id="artikelFactory" class="impl.ArtikelImpl"/>
<osgi:service id="artikelServiceFactory" ref="artikelFactory"/>
[/XML]

public class ArtikelFactory {

	public Artikel createArtikel(){
		return context.getBean("artikel", Artikel.class);
	}
}

PS: Ich würde 2 Bundles machen, eines für Interfaces und eines für die Implementierung. So kann man das Impl-Bundle updaten ohne die Abhängigkeiten von anderen Bundles zu den Interfaces zu entreißen.

klingt einleuchtend

 

[Noctarius]

Joar so in der Art wie Nr. 2

Ich würde aber kein Bean erstellen (bzw aus Spring holen).

public class ArtikelFactory {
 
    public Artikel createArtikel(){
        return new InternalArtikelImpl();
    }
}

Die Implementierungen sollten immer in internen Bundle-Packages sitzen und von außen (außer eventuell von Wrapper-Bundles) nicht erreichbar, geschweige denn instanzierbar sein.

 

[Gast2]

Joar so in der Art wie Nr. 2

Ich würde aber kein Bean erstellen (bzw aus Spring holen).

public class ArtikelFactory {
 
    public Artikel createArtikel(){
        return new InternalArtikelImpl();
    }
}

Die Implementierungen sollten immer in internen Bundle-Packages sitzen und von außen (außer eventuell von Wrapper-Bundles) nicht erreichbar, geschweige denn instanzierbar sein.

Ja ich wusste net was besser ist, war auch erst mein 1ter Gedanke... Ja Klar nur die interface exportieren, die anderen in internen Bundle Package. Da muss ich ja nichts bestimmtes machen einfach nicht exportieren?
Und die Factory muss ich als Service verfügbar machen das passt so?

EDIT: Weil bei einem Service brauch ich ja ein Interface was ich ja eigentlich bei der Factory nicht habe

EDIT EDIT: Also die Sache mit impl und interface Bundle hat ganz gut geklappt...In der den Impl Bundles hab ich auch die xml konfigurationen... Aber was mir jetzt aufgefallen ist, dass ich meine Bundles immer selber starten muss sonst werden sie nicht erkannt?

 

[Gast2]

Hallo nochmal,

hätte nochmal eine Frage zu Spring DM... Kann bei Spring DM auch mit @Autowired arbeiten oder geht das nut mit setter injection. Also mit setter injection funktioniert alles einwandfrei
[XML]
<bean id="addKunde" class="controller.AddKunde" >
<property name="kundenModel" ref="kundenModel"/>
</bean>
[/XML]

doch sobald ich das hier versuche, ist meine Instanz immer null
ich habe noch org.springframework.beans.factory.annotation in meinem Bundle importiert.

	@Autowired
	private KundenModel kundeModel;

[XML]
<bean id="addKunde" class="controller.AddKunde" >
</bean>
[/XML]

 

[Noctarius]

Nö geht auch mit @Autowired, musst aber trotzdem ein Bean vom Typ definieren im XML.

[xml]<bean class="some.other.package.KundenModel" />[/xml]

 

[Gast2]

Nö geht auch mit @Autowired, musst aber trotzdem ein Bean vom Typ definieren im XML.

[xml]<bean class="some.other.package.KundenModel" />[/xml]

Ja das ist klar muss ich ja in beiden Fällen...
Muss ich was bestimmtes beachten oder was könnte der Grund sein , dass es nicht gehr?

 

[Noctarius]

Die Instanz mit dem @Autowired muss auch durch Spring instanziert werden, sonst ist eigentlich nichts zu beachten.