February 2009 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by emuckenhuber

"scott.stark(a)jboss.org" wrote : That's fine, I'll checkout the spi project and take a look until its in trunk. Okay i've updated trunk with the my current changes. "scott.stark(a)jboss.org" wrote : | I'm begining to think that there is no point to a Profile without a DeploymentRepository though.The reason is that at its most explicit a profile has a list of URLs/URIs that define the deployments in some VFS. | Hmm, there are some use cases where you don't need any repository. For example the transient application profile managed by the DeploymentManager. This will be just a hashMap containing the isCopyContent == false deployments, so that they are also visible in the ManagementView. But it's still a independent profile, which can be activated / deactivated by the DeploymentManager. Furthermore i think a VFS/uri does not make up a profile, as you still can could have a different (maybe static) profile, where you create non-vfs based deployments - this is now also possible with the abstraction of ProfileDeployment (although not fully implemented) Also if you look at FilteredDeploymentRepositoryFactory - this would not really be needed, as all the profile has to do is once to get it deployments. That's basically the reason why i think that a DeploymentRepository is optional. Even having an OBR based Profile, would not change much - as the profile implementation would map the deployments with the help of a OBR repository service. There could also be a requirement/capability resolving, but this should be similar to the RequirementDependencyItem from jboss-classloading, where you just get a dependency on a different profile instead of resources. [OT: that's why i was mentioning that i want to review getSubProfiles(), as this would might be better to have a ProfileVisitor where you can create your specific DependencyItems for your Profile.] Although i also think that there is something missing - but more in the sense of a ResourceDiscovery or ProfileSource. Something where you can share the same source and don't need to maintain the profile root uris in each profile. Maybe this also matches somehow to the work you want to do with a DeploymentRepository? Can you provide some more information and/or use cases why you think this is not enough? I mean maybe i'm just missing something :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206116#4206116 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206116

14 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Configure a queue to be ordering aware

by gaohoward

So far we have implemented the strict ordering through message producer. The messaging client can control the message ordering through creating ordering groups via the producer. This is one way to do it however. Another way is by configuring a specific Queue to be an ordering group Queue. Once thus configured, the queue destination becomes a ordering aware destination -- meaning that any messages that are targeted at this queue will naturally become ordered. This way will allow the users to get message ordering without coding. To accomplish this end, we can add a new property to QueueService. For example we name this property EnableOrderingGroup, if the value of this property is true, the Queue is ordering message group queue, as in | <mbean code="org.jboss.jms.server.destination.QueueService" | name="jboss.messaging.destination:service=Queue,name=strictOrderingQueue" | xmbean-dd="xmdesc/Queue-xmbean.xml"> | <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> | <depends>jboss.messaging:service=PostOffice</depends> | <attribute name="EnableOrderingGroup">true"</attribute> | </mbean> | or in clustered case | <mbean code="org.jboss.jms.server.destination.QueueService" | name="jboss.messaging.destination:service=Queue,name=strictOrderingDistributedQueue" | xmbean-dd="xmdesc/Queue-xmbean.xml"> | <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> | <depends>jboss.messaging:service=PostOffice</depends> | <attribute name="Clustered">true</attribute> | <attribute name="EnableOrderingGroup">true"</attribute> | </mbean> | The order of each message is determined by the time of arrival at the target queue, with the earliest arrived message being the foremost of the delivering list. https://jira.jboss.org/jira/browse/JBMESSAGING-1416 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206114#4206114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206114

14 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Missing VirtualFile::isFile?

by alesj

"scott.stark(a)jboss.org" wrote : The reasoning was that it was too much of a file system notion that did not have a useful meaning in general while isLeaf does. | Sure. But I'm saying that only isLeaf is not enough. See the usage in next paragraph. "scott.stark(a)jboss.org" wrote : Why would hotdeployment not check a jar when it would check the corresponding unpacked form of the jar as a directory? | I'm not saying you wouldn't check it. There is just no need to go and check the META-INF/*.xml changes, since the change would already reflect on the root's lastModifiedTime. But in order to know not to go 'in', is the isFile/isArchive directive. "scott.stark(a)jboss.org" wrote : | The thing we did consider was an isArchive notion for a compressed directory. JarHandler/ZipContextHandler::isArchive==true, everybody else == false? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206091#4206091 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206091

14 years, 7 months

1
0
0 / 0

[Design of Embedded JBoss] - Re: Need vfs work for the embedded startup

by alesj

"scott.stark(a)jboss.org" wrote : but the 2.0.1.GA shows a big improvement. The complete server mc bootstrap is completing in 3 secs with the cache options set. Now if only those temps would work as well ... :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206089#4206089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206089

14 years, 7 months

1
0
0 / 0

[Design of Embedded JBoss] - Re: Need vfs work for the embedded startup

by scott.stark＠jboss.org

vfs 2.0.0.GA did not help, but the 2.0.1.GA shows a big improvement. The complete server mc bootstrap is completing in 3 secs with the cache options set. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206087#4206087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206087

14 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Towards 1.4.3.GA

by gaohoward

That's great! +1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206084#4206084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206084

14 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by scott.stark＠jboss.org

That's fine, I'll checkout the spi project and take a look until its in trunk. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206082#4206082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206082

14 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by emuckenhuber

"scott.stark(a)jboss.org" wrote : | Your moving away from the Profile exposing deployments as VFSDeployment right? I don't see the ProfileDeployment in trunk, is it somewhere yet? | I've committed the update to the spi, i'll see if i can commit the updates to trunk tomorrow - just want to run some tests first. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206080#4206080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206080

14 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by scott.stark＠jboss.org

"emuckenhuber" wrote : | "scott.stark(a)jboss.org" wrote : | | If we completely abstract out the deployment and admin content into a deployment repository, then I can see a differentiation between a dynamic profile that is one define by root urls against the deployment repository vs a profile that allows modifications to both deployment collection make up and content changes. | | | | One thing i don't like about the current implementation is that a profile is more defined over | it's DeploymentRepository than it is defined by itself (the actual profile). | | Well i mean the implementation is not a big deal, just want to say that when talking about the definition of a Profile, | a DeploymentRepository should be optional. | | On the other hand this is actually the main point of this thread. Basically how the DeploymentManager gets access | to the low level source of a mutable profile. | I'm not planning to change this yet - just an idea to think about :) | I'm begining to think that there is no point to a Profile without a DeploymentRepository though. The reason is that at its most explicit a profile has a list of URLs/URIs that define the deployments in some VFS. However, even include the VFS protocol is an implicit repository notion that would more generally handled by the DeploymentRepository and the profile would be relative paths against the repository. More generally I'm working toward much more abstract profiles that have to be resolved against a repository. The repository still is an implementation detail as there is no need for it to be exposed from the profile, but the profile is also not useful without the repository. Your moving away from the Profile exposing deployments as VFSDeployment right? I don't see the ProfileDeployment in trunk, is it somewhere yet? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206076#4206076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206076

14 years, 7 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009