Ik schijf mijn deployment descriptors nooit zelf, ik laat dit geheel over aan XDoclet. Scheelt je een hoop tiep werk, en een hoop fouten.
Spring kan dit ook allemaal
Maar EJB is imho veel te opdringerig in je ontwerp. EJB is in principe een leuk idee, maar in de praktijk is het om een ware nachtmerrie uitgelopen. Vandaar dat ze met EJB 3.0 het ook over een hele andere boeg gaan gooien.
Hiet zit hem ook het verschil, als Spring deze mogelijkheden bied dan heeft het ook geen zin om EJB's te gebruiken. Anders doe je de meeste dingen alleen maar dubbelop.
EJB zijn totaal niet opdringerig in je ontwerp, het ligt er maar geheel aan wat je ervan gebruikt. Ik maak totaal geen gebruik van Entity Beans omdat dit veel te omslagtig en bewerkelijk is.
Als je alleen maar bijvoorbeeld Stateless Session Beans gebruikt dan heb je gewoon een mooie manier om gebruik te maken van de build in security en transactionmanager.
Wat ik uit de verhalen opmaak is dat mensen alleen ejb session beans gebruiken omwille van declaratieve toevoeging van transacties, remoting en security. Daar zijn intussen ook alternatieve oplossingen voor. De enigste reden dat ik op dit moment weet waarom voor EJB gekozen moet worden is clustering.
Zie mijn opmerking hiervoor. Wij gebruiken geen Spring dus voor ons is het de beste manier van werken.
EJB CMP = dikke naad, veel te complex. Hibernate/JDO zijn de oplossingen van de toekomst, check EJB 3.0 specs.
[/quote]
CMP is inderdaad dikke naad. Het is een teveel opleggende techniek. En het is niks anders als een platte vertaling van de tabellen op oracle waarbij je een hoop moeite moet doen om je data OO georienteerd te krijgen. Ditzelfde kan je zelf ook bereiken met Stateless Session Beans en directe JDBC (maar wel gebruik makend van de connection pool en transcation manager van JBoss.
Daarnaast zijn Entity Beans traag zodra de hoeveelheid gezochte data te groot wordt of als je teveel bulk mutaties moet uitvoeren. En dan moet je toch weer terug vallen op Stateless/Statefull Session beans.
Om toch de vraag te bantwoorden:
Via de JMX bean org.jboss.system.server.ServerImpl de method shutdown te initialiseren.
Hiermee stop de JBoss server.
Kijk maar naar http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Atype%3DServer
Deze kan je gewoon vanuit je code aanroepen door gebruik te maken van bijvoorbeeld:
(code is waarschijnlijk niet volledig, dat krijg je als je copy/paste vanuit bestaande code doet)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| import javax.management.*;
import org.jboss.mx.util.*;
public class test {
private MBeanServer server;
public test method() {
server = MBeanServerLocator.locate();
try {
// The MBean we want to invoke.
final ObjectName objectName = new ObjectName("jboss.system:type=Server");
return server.getAttribute(objectName, Version);
} catch (MalformedObjectNameException e) {
throw new Exception(e);
} catch (AttributeNotFoundException e) {
throw new Exception(e);
} catch (InstanceNotFoundException e) {
throw new Exception(e);
} catch (MBeanException e) {
throw new Exception(e);
} catch (ReflectionException e) {
throw new Exception(e);
}
}
} |
3015 Wp-z 5360 Wp-nno op 2 x SMA-SB3600 TL-21, Warmtepomp: ERSC-VM2CR2 / PUHZ-SHW140 YHA, WTW Q350, EV Kia Ev6 GT-Line
:strip_exif()/u/31626/eend.gif?f=community)
:strip_icc():strip_exif()/u/23374/monkey2.jpg?f=community)
:strip_exif()/u/28986/javaone6666.gif?f=community)
]
Sorry