anonymous wrote :
| Are there any plans to support business indicators (KPIs)?
If they get too domain specific, no. At least not in the beginning. A good dashboard is always customized to the users needs. I am talking about is information the can be derived from default BPM terms, because we are not offering a lot of customization in the beginning. Don't underestimate it though. People have the capabilities to read "between the lines". What you described with order example, can be derived from non domain specific figures as well. IMO "outstanding orders" can be as well expressed as a particular derivation or exception in the process execution without being to much tight to that particular domain.
The goal should be that people with specific knowledge are able to "recognize" patterns that put them in alert state or at least raise their interest.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185240#4185240
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185240
"timfox" wrote :
| What does "packetSize" represent?
Represents the memory necessary to be allocated before sending the packet.
This is particulary important on the InVM transport where we can't expand the buffer. RemotingConnectionImpl is using that on my branch in order to allocate the buffer:
private void doWrite(final Packet packet)
| final MessagingBuffer buffer = transportConnection.createBuffer(packet.getPacketSize());
"tim.fox" wrote : Confusing name. The journal is a large message?
| anonymous wrote :
| | I will find a better name, but the idea is Journal has a LargeMessage. When we have a DatabaseStorageManager we could have an implementation for the DB.
| | "Tim Fox" wrote :
| | | "Clebert" wrote :
| | | | III - I have separated the reference counting of references and durable references on Messages (that fix on paging discussed on this thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144128)
| | | |
| | | | As soon as we remove the reference from the queue (ACKs) I decrement the refCount. I use that ref to delete large messages stored on files.
| | | |
| | |
| | | How is this different to how it was before?
| | |
| | Before we only had the reference counting on Durables. Later I added another counter for paging where I used to determine when the message was ready to GC, now the same counter used for paging is also used to delete the message.
| | For Paging I was returning the counter on the same place the durable was being done (which is the weird code you noticed here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144128).
| | The refCount is only done now when the Message is removed from the Queue after ACK.
| | This was a simple fix!
| | anonymous wrote :
| | | For everyone's benefit could you explain what chunkSize represents, and how it differs (or not) from minLargeMessageSize?
| | |
| | I used to have two attributes (chunkSize and minLargeMessageSize), but I only have minLargeMessageSize now.. so.. just scratch that name.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185180#4185180
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185180
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | Neither of them work. See my comment about needing the className -> class HACK
| I see.
| What to do then?
| Adding another hack to existing hack? :-)
I think the closet you can get is:
1) Add the CLASS scope as we described above, but...
2) If bean.getClassLoader() == null add the real class to the CLASS scope level
using the deployment classloader to load the class
3) otherwise just use the class name.
Basically this means that if the bean is not using the deployment classloader
then unit.getMetaData() can't see the class annotations
(ClassMetaDataRetrievalFactory will return null for that metadata loader).
That seems like a fair restriction for this edge case and doesn't require
the HACK in the deployer's handling of scopes.
One change though is that it will be trying to load the bean class when it creates
the components. So it will be reporting an error in that earlier. You need to make
sure this error is understandable.
If you don't like this change, then you would have to introduce the HACK
to make it lazily load the class and update the scope key when getMetaData() is
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185165#4185165
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185165
"alesj" wrote : "alesj" wrote : "adrian(a)jboss.org" wrote :
| | | The simplest fix would be in the component visitor
| | |
| | But you're right, yours looks easier. :-)
| But yours doesn't work, where mine does. :-)
| Testing on AnnotatedBeansUnitTestCase.
| Need to check why is that ... since both look legit.
Neither of them work. See my comment about needing the className -> class HACK
If somebody in a deployer does:
is going to be very confused when it gets a class name instead of a class. :-)
| public MetaDataRetrieval getMetaDataRetrieval(Scope scope)
| if (scope == null)
| throw new IllegalArgumentException("Null scope");
| if (CommonLevels.CLASS.equals(scope.getScopeLevel()) == false)
| throw new IllegalArgumentException("Not a class scope: " + scope);
| // Not a class
| Object qualifier = scope.getQualifier();
| if (qualifier instanceof Class == false)
| return null; // OOPS!!!!!!!!!!
| Class<?> clazz = Class.class.cast(qualifier);
| return new AnnotatedElementMetaDataLoader(clazz);
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185161#4185161
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185161