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

[Design of EJB 3.0] - Re: Filtering non-EJB3 deployments in the EJB3 deployer

by jaikiran

"alex.loubyansky(a)jboss.com" wrote : | So, I am going to change the "if" above to | if(metaData != null && !metaData.isEJB3x()) | | { | | log.debug("Ignoring legacy EJB deployment " + unit); | | return; | | } Sounds good. Infact, we use this approach in one of our other deployers http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/endpoint-deplo... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241111#4241111 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241111

16 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Re: JAXB annotations for OSGi Blueprint

by richard.opalka＠jboss.com

"thomas.diesler(a)jboss.com" wrote : | | At the end of the day you might find that it saves you a lot of time using jbossxb instead of writing your own unmarshalling layer. This is time you can spend on your main project instead ;-) Yes, I know what you mean. X2JB is one of my little free time projects. If I'd count man days spent on it in last two and half years, it wouldn't reach 20 MD at all ;) Thus X2JB isn't my main project. "thomas.diesler(a)jboss.com" wrote : | Alexey, is indeed very responsive when it comes to resolving technical issues. jbossas uses jbossxb for all its configuration tasks (which are non-trivial in places). Please also remember that we used jbossxb for the jax-rpc part in jbossws. We could never have delivered on time if we had to do our own XML marshalling layer. | Agreed. "thomas.diesler(a)jboss.com" wrote : | Anyway, good luck with your (main) project. | Thanks ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241106#4241106 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241106

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Good article on consistent hashing

by timfox

Thanks Andy. A few initial questions: When you talk about queues on each node I guess you really mean *consumers*. E.g. "If there are remote queues and we haven't yet bound to any queue...", should be "If there are remote consumers and we haven't yet bound to any consumer..." Since we won't send messages to any node which just has a queue but no consumers. (Grouping works on the consumer level not the queue level) Secondly, your algorithm looks kind of similar to one of the Paxos variants. What's the reasoning why none of the Paxos variants are sufficient for our use case? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241105#4241105 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241105

16 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Re: JBossXB does not assign schema defined attribute default

by thomas.diesler＠jboss.com

I think I provide this information here http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/blueprin... | static class BlueprintSchemaResolver extends DefaultSchemaResolver | { | private LogService log; | | public BlueprintSchemaResolver(BlueprintContext context) | { | this.log = context.getLog(); | | try | { | addSchemaLocation(XMLNS_BLUEPRINT, "blueprint.xsd"); | addClassBinding(BlueprintContext.XMLNS_BLUEPRINT, TBlueprint.class); | } | catch (RuntimeException rte) | { | throw rte; | } | catch (Exception ex) | { | log.log(LogService.LOG_ERROR, "Cannot create schema resolver", ex); | } | } | } | The DefaultSchemaResolver sais | /** | * Uses the JBossEntityResolver.resolveEntity by: | * | * 1. Using the nsUri as the systemID | * 2. Using the schemaLocation as the systemID | * 3. If that fails, the baseURI is not null, the xsd is located using URL(baseURL, schemaLocation) | * 4. If the baseURI is null, the xsd is located using URL(schemaLocation) | */ | public SchemaBinding resolve(String nsURI, String baseURI, String schemaLocation) | but (in my case) it actually generates the schema from a binding class | schema = JBossXBBuilder.build(bindingClass); | AFAICS, it generates the schema rather than use the one that I provide. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241103#4241103 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241103

16 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Re: JAXB annotations for OSGi Blueprint

by richard.opalka＠jboss.com

"alex.loubyansky(a)jboss.com" wrote : | You can have all of that. I don't think anybody would mind. | | There are lots of custom binding features in XB. You are welcome to add more. | There have never been a complaint about project lifecycle for the reason that there is no roadmap. It's demand-driven. If someone needs a release we can do it often the same day or whenever it's needed. | You want to do architectural changes - really no problem. Given that the existing users are not affected of course. I guess that's the real thing you don't want to deal with. Thanks Alex, I highly appreciate it ;) I'm not saying JBossXB is bad. I started X2JB project before I joined JBoss and before I learned JBossXB. The above arguments were mainly about explaining what is/isn't NIH ;) RIchard View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241101#4241101 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241101

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Filtering non-EJB3 deployments in the EJB3 deployer

by alex.loubyansky＠jboss.com

Currently it's done like this public void deploy(VFSDeploymentUnit unit, JBossMetaData metaData) throws DeploymentException | { | try | { | // Pickup any deployment which doesn't have metaData or metaData with ejbVersion unknown or 3 | if(metaData != null && (metaData.isEJB2x() || metaData.isEJB1x())) | { | log.debug("Ignoring legacy EJB deployment " + unit); | return; | } | ... The problem with this is that if an ejb-jar.xml does not include any namespace (i.e. based on DTD) isEJB2x(), isEJB1x(), isEJB3x() will all return false. Actually, the absence of ejbVersion should mean EJB2/EJB1 deployment because only these are allowed to use DTD. ejb-jar_2_1.xsd and ejb-jar_3_0.xsd both define *required* and *fixed* attribute version with values 2.1 and 3.0 respectively. So, any EJB3 deployment will have a non-null ejbVersion and isEJB3x() will return true. So, I am going to change the "if" above to if(metaData != null && !metaData.isEJB3x()) | { | log.debug("Ignoring legacy EJB deployment " + unit); | return; | } View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241097#4241097 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241097

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - GetOutcomes returns additional transition

by shekharv

Is there a particular reason for why GetOutComes does this? | Set<String> outcomes = new HashSet<String>(); | outcomes.add(Task.STATE_COMPLETED); | .. logic to add other transitions specified in the activity. | When the TaskService.getOutComes(long taskDbId) is called with a task id it returns completed as an entry in the list of Transitions that will eventually be shown to the user. But this particular transition is not even being modeled in the process_definition. There are other places in the code, where in if a transition/outcome name is not specified then the transition is assumed to the 'completed' and special handling is done, | if (Task.STATE_COMPLETED.equals(signalName)) { | if (outgoingTransitions.size()==1) { | transition = outgoingTransitions.get(0); | } else { | transition = activity.getDefaultOutgoingTransition(); | } | } | The above snippet is from TaskActivity. What is the reasoning behind adding this to the transitions that can be taken out of a Task? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241085#4241085 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241085

16 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Re: JBossXB does not assign schema defined attribute default

by alex.loubyansky＠jboss.com

The problem comes from the XML parser. Since binding is based on Java annotations, we don't parse the XSD and don't know anything about it, even whether it exists. So, in this case, XML parser (e.g. xerces in our case) should include default attribute values and make them available through SAX API. For that, XSD schema must be resolvable by the XML parser. Which means EntityResolver should know the schema location. And also validation should be enabled. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241081#4241081 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241081

16 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Re: JAXB annotations for OSGi Blueprint

by thomas.diesler＠jboss.com

@Richard At the end of the day you might find that it saves you a lot of time using jbossxb instead of writing your own unmarshalling layer. This is time you can spend on your main project instead ;-) Alexey, is indeed very responsive when it comes to resolving technical issues. jbossas uses jbossxb for all its configuration tasks (which are non-trivial in places). Please also remember that we used jbossxb for the jax-rpc part in jbossws. We could never have delivered on time if we had to do our own XML marshalling layer. I agree that the entry to jbossxb is high because of it sucks in documentation. Which is probably the root of your jbossxb adoption problem. You can monitor https://jira.jboss.org/jira/browse/JBXB-208 for this issue. Anyway, good luck with your (main) project. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241079#4241079 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241079

16 years, 3 months

1
0
0 / 0

[Design of JBossXB] - JBossXB does not assign schema defined attribute defaults

by thomas.diesler＠jboss.com

| [tdiesler@tdvaio blueprint]$ mvn -Dtest=BasicRootParserTestCase install | | ------------------------------------------------------------------------------- | Test set: org.jboss.test.osgi.blueprint.parser.BasicRootParserTestCase | ------------------------------------------------------------------------------- | Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.001 sec <<< FAILURE! | testBlueprintDefaultAttributes(org.jboss.test.osgi.blueprint.parser.BasicRootParserTestCase) Time elapsed: 0.935 sec <<< FAILURE! | java.lang.AssertionError: default-lazy-init: FALSE expected:<false> but was:<null> | at org.junit.Assert.fail(Assert.java:92) | at org.junit.Assert.failNotEquals(Assert.java:689) | at org.junit.Assert.assertEquals(Assert.java:127) | at org.jboss.test.osgi.blueprint.parser.BasicRootParserTestCase.testBlueprintDefaultAttributes(BasicRootParserTestCase.java:56) | on TBlueprint I have an attribute declaration like this | @XmlAttribute(name = "default-lazy-init") | public Boolean isDefaultLazyInit() | { | return defaultLazyInit; | } | which should probably not even be necessary. This works with the SchemaBindingParser, which gets the binding annotation from the schema. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241077#4241077 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241077

16 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2009