September 2008 - jboss-dev-forums

[Design of POJO Server] - Re: Towards a canonical server

by david.lloyd＠jboss.com

"scott.stark(a)jboss.org" wrote : | The first hurdle is updating the build to produce a repository of jars/deployments, and then properly describing: | - the class dependency requirements for deployments | Are we going to be doing this generally by package or by module? I started doing some of my stuff by package but it seems to me that for (non-JEE) projects which have e.g. an API jar and implementation jar it might be better to have e.g. JBossRemotingAPI as a module, and have the implementation (as well as any user applications) simply depend on that. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177209#4177209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177209

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-classload*.xsd appears to be broken

by david.lloyd＠jboss.com

Oh well. Well I just committed the simple fix - if nothing is using these for validation then at least nothing will break. But we probably ought to employ (or create) a schema verification tool that compares the annotation-based rules to the xsd and warns about any glaring incompatibilities... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177208#4177208 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177208

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-classload*.xsd appears to be broken

by scott.stark＠jboss.org

These are definitely broken, but have not been updated for months. I would guess its because we are now using jaxb annotations to describe the schema, so these files would need to be synced with the current jaxb usage. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177204#4177204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177204

17 years, 6 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: Datasource deployer does not substitute system propertie

by alex.loubyansky＠jboss.com

Yes, that's regression. I am looking into it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177190#4177190 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177190

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-classload*.xsd appears to be broken

by david.lloyd＠jboss.com

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-classload*.xsd appears to be broken

by david.lloyd＠jboss.com

Also I found that "capabilities" was misspelled in a few places in the .xsd... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177159#4177159 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177159

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - jboss-classload*.xsd appears to be broken

by david.lloyd＠jboss.com

Many of the attributes in these xsd files are written like so: | <xsd:attribute name="name" type="xsd:string" optional="true"> | I'm pretty sure this should be like: | <xsd:attribute name="name" type="xsd:string" use="optional"> | Also IDEA seems fairly certain that you can't use the "base" attribute here, though I'm not sharp enough on my xsd to say for sure: | <xsd:simpleType name="version" base="xsd:string"> | Are these really bugs or am I missing something? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177158#4177158 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177158

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messages are lost on Queue?

by clebert.suconic＠jboss.com

The problem is, a CTRL-C on the client, is closing the socket. When the socket is closed, RemotingServiceImpl::connectionDestroyed is called and the connection is removed. At that point, RemotingConnectionImpl::destroy is called (Tim added this call yesterday), and nothing is cleared on Server-side. As a result you will have a dead consumer listed on QueueImpl, and nothing will ever clear that. (The connection doesn't exist on RemotingServiceImpl any more, so the pinger will forget about that connection). To fix this, we need to to cleanup server-side objects after RemotingServiceImpl::destroy or make sure Ping would catch this. But I'm a bit confused on how this should work (seems a bit dodgy now (as British people would say... http://www.merriam-webster.com/dictionary/Dodgy )) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177143#4177143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177143

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Notifications over JBM core connections

by jmesnil

As part of the management task, I'm implementing receiving management notifications over JBM core connections. The idea is that a Core client can subscribe to notifications by asking the server to send a message to a given destination every time a notification is triggered on the server (e.g. a queue is full, a queue is added to the server) - the client creates a "management message", a Core message with well-known properties: * the ObjectName it wants to observe * the destination where the notification messages must be sent (specified by the client, can be any kind of destination, more likely either a topic or a temp queue) - it sends the message to the server - the server handles the message * the PostOffice detects it is a management message and pass it to the management service * the management service creates a NotificationListener for the given ObjectName - Later on, when a notification is received by the listener (e.g. a queue is full) * the listener creates a Core message and fills it with the notifications information (who, when, what, etc.) * this core message is then routed by the PostOffice according to the destination set by the client - the client will receive the Core message and process the notification information So, the big idea is that a Core message is created on the /server-side/ as the result of a notification (internal to the server) and not as the result of receiving a message from a client. I'm not sure about the best way to create a Core message on the server. The ManagementService code looks like: | // when handling a "management message" | final SimpleString replyTo = (SimpleString)message.getProperty(ManagementMessageImpl.HDR_JMX_REPLYTO); | boolean subscribe = (Boolean)message.getProperty(ManagementMessageImpl.HDR_JMX_SUBSCRIBE_TO_NOTIFICATIONS); | if (subscribe) | { | broadcaster.addNotificationListener(new NotificationListener() { | public void handleNotification(Notification notification, Object handback) | { | ServerMessage notificationMessage = new ServerMessageImpl(0); | notificationMessage.setDestination(replyTo); | // FIXME no hard-coded value | notificationMessage.setBody(new ByteBufferWrapper(ByteBuffer.allocate(1024))); | notificationMessage.putBooleanProperty(ManagementMessageImpl.HDR_JMX_NOTIFICATION, true); | notificationMessage.putStringProperty(new SimpleString("notif"), new SimpleString(notification.getMessage())); | try | { | postOffice.route(notificationMessage); | } | catch (Exception e) | { | log.warn("problem while routing a notification message", e); | // TODO unregister the listener for the broadcaster | } | } | }, null, null); | } | ... | The code to create the notificationMessage is not correct. I need to use a proper message ID but, on the server-side, it is the storage manager which owns the ID sequence. I could inject the storageManager into the managementService to get access to its generateID() but it smells like a bad idea. I could create a new POJO, a ID generator, injected in both the storageManager and the managementService. What do you think? Does this make sense? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177142#4177142 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177142

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Eclipse code formatter and code cleanup profiles

by clebert.suconic＠jboss.com

I was wondering how to apply these settings until Jeff gave me a quick help: "Jeff@freenode#jbossmessaging" wrote : | jmesnil: clebert: in the project folder, right-click on "Properties" | jmesnil: clebert: Java Code Style > Clean Up > import... | jmesnil: clebert: Java Code Style > Formatter > import... | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177135#4177135 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177135

17 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2008