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

[Design of POJO Server] - Re: ProfileService Server.getMetadata() - immutable OK?

by scott.stark＠jboss.org

It would be purely a one-way mechanism of passing in bootstrap environment properties, so an immutable map is fine. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247120#4247120 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247120

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - 'default' field on transition in pvm

by kukeltje

Would be very interesting to have this: https://jira.jboss.org/jira/browse/JBPM-2465 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247099#4247099 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247099

15 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService Server.getMetadata() - immutable OK?

by ALRubinger

JIRA pending approval: https://jira.jboss.org/jira/browse/JBBOOT-104 S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247084#4247084 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247084

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: .classpath and .project to .svnignore

by kukeltje

- They are eclipse specific - If something changes in the pom.xml you have to regenerate them anyhow - They can contain absolute paths (OS specific things) - My sync with repository always shows them. *outgoing* Personally, I do not need them from svn. I'll regenerate with M2/mvn if needed. The pom is leading anyway. But if others think they are handy, I'll live with them View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247057#4247057 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247057

15 years, 5 months

1
0
0 / 0

[Design of POJO Server] - ProfileService Server.getMetadata() - immutable OK?

by ALRubinger

Probably this one's for Scott/Emanuel: http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/spi-as/sr...: /** | * Get the optional server configuration metadata | * | * @return A possibly empty map of configuration metadata | */ | Map<String, Object> getMetaData(); Can I wrap this in Collection.unmodifiableMap() when returning so we don't leak out the mutable state of the server? Or is something in the ProfileService depending upon altering the contents? S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247055#4247055 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247055

15 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Abstract Beans JBKERNEL-10

by david.lloyd＠jboss.com

Yeah, that was my thinking as well. There is a lesson to take away from this however: defining your API object model around JAXB makes for ugliness and bad things unless you're extraordinarily careful and clever. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247042#4247042 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247042

15 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Abstract Beans JBKERNEL-10

by marius.bogoevici

Since parsing is done using JAXB, I think we still need to use a Collection (Set is alright, although it does not take advantage of any uniqueness feature of PropertyMetaData). Maps would be mapping somehow differently in JAXB, and AFAICT you can't actually use a HashMap per se as the mapped property, much less so a LinkedHashMap. I would rather think of using a set for JAXB and a map internally, something like this: | ... | @XmlTransient | private Map<Object, PropertyMetaData> propertyMetaData = ; | | | public void setPropertyMetaData(Set<PropertyMetaData> parsedProperties) { | this.propertyMetaData = new LinkedHashMap(); | <add all the elements of parsedProperties into the Map> | } | | | @XmlElement("property") | public Set<PropertyMetaData> getPropertyMetaData() { | return new HashSet<PropertyMetaData>(this.propertyMetaData.values(); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247038#4247038 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247038

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: .classpath and .project to .svnignore

by camunda

Tortoise can set them to ignore easily. But do we ant to delete them? The other modules have them checked in as well... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247036#4247036 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247036

15 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Does ScopeKey need to maintain a sorted (in ScopeLevel.level

by smarlow＠redhat.com

In my quest to understand the MC internals and help make improvements. I'm looking at ScopeKey and wondering what would happen if an unordered collection was used internally (with adjustments made to isParent() of course). I would like to add some contractually comments to ScopeKey that explain the "ordered" expectation, if there is one. Is the ScopeKey ordering so that we will look at metadata in the following order (from CommonLevels)? { domain, cluster, machine, node, jvm, server, subsystem, application, ... } View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247027#4247027 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247027

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: .classpath and .project to .svnignore

by kukeltje

Deleting them is one. But in addition to that, adding them to cvs ignore (assuming you all work with M2? /mvn eclipse:eclipse to regenerate .project and .classpath files If you can do that also, recursively... be my guest. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247021#4247021 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247021

15 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2009