[Design of POJO Server] - Explicit listing of Boot Classpath
by ALRubinger
Came across some this while addressing: https://jira.jboss.org/jira/browse/JBAS-6698
I was under the impression that anything in $JBOSS_HOME/lib should be on the boot CP. As such the ServerLoader in jboss-bootstrap constructs the CP by iterating through the contents of "lib" and adding each JAR.
ServerLoader in AS/main instead has an explicit default boot library list:
/**
| * The default list of boot libraries. Does not include
| * the JAXP or JMX impl, users of this class should add the
| * proper libraries.
| * TODO: use vfs to list the root directory
| */
| public static final String[] DEFAULT_BOOT_LIBRARY_LIST = {
| // Logging
| "log4j-boot.jar",
| "jboss-logging-spi.jar",
| "jboss-logging-log4j.jar",
| "jboss-logging-jdk.jar",
| "jboss-logmanager.jar",
| "jboss-logbridge.jar",
| // Common jars
| "jboss-common-core.jar",
| "jboss-xml-binding.jar",
| "jaxb-api.jar",
| // Bootstrap
| "jboss-bootstrap.jar",
| // Microcontainer
| "javassist.jar",
| "jboss-reflect.jar",
| "jboss-mdr.jar",
| "jboss-dependency.jar",
| "jboss-kernel.jar",
| "jboss-metatype.jar",
| "jboss-managed.jar",
| // Fixme ClassLoading
| "jboss-vfs.jar",
| "jboss-classloading-spi.jar",
| "jboss-classloader.jar",
| "jboss-classloading.jar",
| "jboss-classloading-vfs.jar",
| // Fixme aop
| "jboss-aop.jar",
| "jboss-aop-mc-int.jar",
| "trove.jar",
| };
Using the jboss-bootstrap approach leads to:
Failed to boot JBoss:
| java.lang.RuntimeException: Error creating annotation for @org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.system:service=ServiceBindingManager", exposedInterface=org.jboss.services.binding.ServiceBindingManagerMBean.class, registerDirectly=true)
| at org.jboss.beans.metadata.plugins.AbstractAnnotationMetaData.getAnnotationInstance(AbstractAnnotationMetaData.java:128)
| at org.jboss.beans.metadata.plugins.AbstractAnnotationMetaData.getAnnotationInstance(AbstractAnnotationMetaData.java:100)
| at org.jboss.deployers.plugins.managed.BeanMetaDataICF.getManagedObjectClass(BeanMetaDataICF.java:119)
| at org.jboss.deployers.plugins.managed.BeanMetaDataICF.getManagedObjectClass(BeanMetaDataICF.java:50)
| at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:342)
| at org.jboss.managed.api.factory.ManagedObjectFactory.initManagedObject(ManagedObjectFactory.java:77)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.initBootstrapMDs(ProfileServiceBootstrap.java:439)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:242)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
| at org.jboss.Main.boot(Main.java:216)
| at org.jboss.Main$1.run(Main.java:546)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.services.binding.ServiceBindingManagerMBean
| at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:241)
| at org.jboss.annotation.factory.ast.ASTIdentifier.jjtAccept(ASTIdentifier.java:37)
| at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:116)
| at org.jboss.annotation.factory.ast.ASTMemberValuePair.jjtAccept(ASTMemberValuePair.java:37)
| at org.jboss.annotation.factory.AnnotationCreator.createAnnotation(AnnotationCreator.java:403)
| at org.jboss.annotation.factory.AnnotationCreator.createAnnotation(AnnotationCreator.java:449)
| at org.jboss.beans.metadata.plugins.AbstractAnnotationMetaData.getAnnotationInstance(AbstractAnnotationMetaData.java:119)
| ... 11 more
| Caused by: java.lang.ClassNotFoundException: org.jboss.services.binding.ServiceBindingManagerMBean
| at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
| at java.security.AccessController.doPrivileged(Native Method)
| at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
| at java.lang.Class.forName0(Native Method)
| at java.lang.Class.forName(Class.java:242)
| at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:175)
| ... 17 more
Probably the real issue is not a CNFE a this point, but the loading of some extra JAR is triggering some scanning/deployment prematurely.
What's the correct approach - to stick with this explicit list, or put only stuff in $JBOSS_HOME/lib which can be used at boot?
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221825#4221825
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221825
16 years, 9 months
[Design of JBoss Remoting, Unified Invokers] - Message Selectors on QueueBrowser and MessageConsumer
by shuffler16
Hi all,
We are using JBoss AS 4.0.5 and JBossMQ. Currently we are using spring to consume and browse a JMS Queue.
The problem is when we are using selectors on QueueBrowser, messages are returned properly while when using MessageConsumer, none is returned.
Here is the snippet for QueueBrowser and MessageConsumer, jmsTemplate is used on both.
// selector type
final String selector = "documentType = 'text'";
// QueueBrowser
jmsTemplate.execute(new SessionCallback() {
@SuppressWarnings("unchecked")
public Object doInJms(Session queueSession) throws JMSException {
QueueBrowser browser = queueSession.createBrowser(queue, selector);
try {
Enumeration enumeration = browser.getEnumeration();
while(enumeration.hasMoreElements()) {
TextMessage textMessage = (TextMessage)enumeration.nextElement();
System.out.println(textMessage.getStringProperty("documentType") + "-" + textMessage.getText());
}
} catch(Exception ex) {
System.out.println(ex.getMessage());
ex.printStackTrace();
} finally {
browser.close();
}
return null;
}
});
// MessageConsumer
jmsTemplate.execute(new SessionCallback() {
@SuppressWarnings("unchecked")
public Object doInJms(Session queueSession) throws JMSException {
MessageConsumer consumer = queueSession.createConsumer(queue, selector);
try {
Message message = null;
while((message = consumer.receive(1000)) != null) {
System.out.println(((TextMessage)message).getText());
}
} finally {
consumer.close();
}
});
Thanks..
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221798#4221798
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221798
16 years, 9 months
[Design of Management Features on JBoss] - JBAS-6697, exposing deploy directories
by emuckenhuber
"Ian Springer" wrote :
| That sounds close to what we need, but not exactly. In the Jopr jboss-as-4 plugin, when a user creates a new WAR or EAR via Jopr, they are prompted to enter the deploy directory, which is a path relative to the AS configSet dir. They would usually enter "deploy" or "farm", but we had a couple users who deployed to "my.custom.deploy" or something (e.g. when they wanted to keep their deploy dir on a different filesystem). We were hoping to provide this same option at app create time in the jboss-as-5 plugin. Prompting for a deployment profile name seems like it might be too low-level for an end-user; it might be more intuitive to them to just specify the directory they want to deploy to. What do you think? Charles, any thoughts
|
Yes i know what you mean. But that's what this part of ProfileService is all about. A profile does not necessarily have a directory, therefore it would not make sense to expose them. So from a ProfileService standpoint a URL to a directory is far too low level and a implementation detail. In future we want to go further away from this file based notion, so exposing the directories would be a step back.
Although we could make it easier to create e.g. 'my.custom.deploy.profile'.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221783#4221783
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221783
16 years, 9 months
[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by emuckenhuber
Yeah the uses cases are fine. Although i still think doing managedProperty.setValue(null); should not replace it with a default value.
I guess a default value is also nice for the template generation.
Additionally we should leverage managedProperty.isModified() to skip not modified properties.
So that we dispatch and update only changed values.
Scott, we might want to remove the managedProperty.isRemoved(), managedProperty.setRemoved()?
i think i requested that once, but now thinking about that again it does not make much sense.
So we could provide setModified(boolean) - and setValue() could compare the original value with the new value and also update this flag.
And if needed a flag to indicate to reset the value to the default one. Although i'm not really sure if this is needed, as the template should have populated the default values anyway?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221743#4221743
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221743
16 years, 9 months