October 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Need more metadata for the JARStructure deployer

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : I just checked in an update to the deployer that adds a DeclaredStructure deployer which is driven off a META-INF/jboss-structure.xml descriptor. | It was an abstract deployer structure notion like this that I was going to use to write the EARDeployer, but Bill got there first, I haven't looked at what he has done. This is also something I wanted to work out to give what I called the "structure view" rather than exposing the whole deployment context. I don't like using String[] for this kind of stuff. 1) The array is immutable (you can't change its length) 2) You can't create the metadata "lazily" (without copying an entire list to an array when it requested) 3) String is inextensible so it becomes impossible to annotate (add attributes) to this piece of metadata. I haven't looked at what you checked in. But this also needs to work in the case where this metadata is passed in at deployment time rather than read from the xml. We also need to rewrite the way the StructureDeployers are invoked (partly to give the scanner a chance to determine whether a file is a deployment so we can replace the archive notion in the VFS). Currently, it builds up a list of candidates for each deployment then this *potentially big* list is check to see whether they are actually real. So there really needs to be a factored out StrutureDeployers object that can be reused outside the MainDeployer 1) By the scanner 2) By each structure deployer to resurse into to avoid creating the big list View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978138#3978138 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978138

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Need more metadata for the JARStructure deployer

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Right now the JARStructure deployer is stumbling around in the dark trying to identify whatever gets passed to it. The two problems I am current seeing are: | | 1. Its traversing directories it should not, for example, a directory entry in a jar archive. | That sounds like a bug, if they are are not just candidates getting rejected later on. anonymous wrote : | 2. Its not traversing directories it should, for example, a child directory in top level deployment (jbossweb-tomcat6.deployer/jsf-libs). | Why should it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978134#3978134 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978134

19 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Interacting with class properties rather than instances?

by adrian＠jboss.org

"Do we have a notion of being able to configure class properties rather than instance properties?" No, because I don't want the JBossMC metadata turning into scripting language. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978133#3978133 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978133

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Problem with repeated but not repeatable particles.

by adrian＠jboss.org

In the ejb-jar xsd there is a repeated particle that is not a repeatable particle, this causes problems for JBossXB which wants to treat it as a repeatable. I added a test for this, see RepeatedElementsUnitTestCase. I have a patch that fixes the problem, but this is obviously a hack, besides the fact that it doesn't cater for the more compliated case: | <xsd:sequence> | <xsd:element ref="child"/> | <xsd:element ref="another" minoccurs="0"/> | <xsd:element ref="child"/> | </xsd:sequence> | The patch only marks the repeated element if they are consecutive. | Index: SequenceBinding.java | =================================================================== | --- SequenceBinding.java (revision 2115) | +++ SequenceBinding.java (working copy) | @@ -54,6 +54,25 @@ | | public void addParticle(ParticleBinding particle) | { | + // TODO Revisit this is a hack and incomplete | + // see RepeatedElementUnitTestCase | + if (sequence.isEmpty() == false) | + { | + TermBinding term = particle.getTerm(); | + if (term instanceof ElementBinding) | + { | + QName name = ((ElementBinding) term).getQName(); | + ParticleBinding previous = (ParticleBinding) sequence.get(sequence.size()-1); | + term = previous.getTerm(); | + if (term instanceof ElementBinding) | + { | + QName previousName = ((ElementBinding) term).getQName(); | + if (previousName.equals(name)) | + previous.setRepeated(true); | + } | + } | + } | + | switch(sequence.size()) | { | case 0: | @@ -61,10 +80,7 @@ | if(particle.isRepeatable() && particle.getTerm() instanceof ElementBinding) | { | ElementBinding element = (ElementBinding)particle.getTerm(); | - if(particle.isRepeatable()) | - { | arrayItem = element; | - } | } | break; | case 1: | Index: ParticleBinding.java | =================================================================== | --- ParticleBinding.java (revision 2115) | +++ ParticleBinding.java (working copy) | @@ -31,6 +31,7 @@ | private int minOccurs = 1; | private int maxOccurs = -1; | private boolean maxOccursUnbounded; | + private boolean repeated; | | public ParticleBinding(TermBinding term, int minOccurs, int maxOccurs, boolean maxOccursUnbounded) | { | @@ -100,6 +101,16 @@ | return minOccurs > occurs && (!term.isModelGroup() || ((ModelGroupBinding)term).hasRequiredParticle()); | } | | + public boolean isRepeated() | + { | + return repeated; | + } | + | + public void setRepeated(boolean repeated) | + { | + this.repeated = repeated; | + } | + | public String toString() | { | return term.toString(); | Index: CharactersHandler.java | =================================================================== | --- CharactersHandler.java (revision 2115) | +++ CharactersHandler.java (working copy) | @@ -27,6 +27,7 @@ | import javax.xml.namespace.NamespaceContext; | | import org.jboss.xb.binding.Constants; | +import org.jboss.xb.binding.JBossXBException; | import org.jboss.xb.binding.SimpleTypeBindings; | import org.jboss.xb.binding.JBossXBRuntimeException; | import org.jboss.xb.binding.metadata.ValueMetaData; | @@ -108,7 +109,14 @@ | } | else if(typeQName != null && Constants.NS_XML_SCHEMA.equals(typeQName.getNamespaceURI())) | { | - o = SimpleTypeBindings.unmarshal(typeQName.getLocalPart(), value, nsCtx); | + try | + { | + o = SimpleTypeBindings.unmarshal(typeQName.getLocalPart(), value, nsCtx); | + } | + catch (IllegalStateException e) | + { | + throw new JBossXBRuntimeException("Characters are not allowed here", e); | + } | } | else | { | Index: SundayContentHandler.java | =================================================================== | --- SundayContentHandler.java (revision 2115) | +++ SundayContentHandler.java (working copy) | @@ -29,6 +29,7 @@ | import org.apache.xerces.xs.XSTypeDefinition; | import org.jboss.logging.Logger; | import org.jboss.util.StringPropertyReplacer; | +import org.jboss.util.Strings; | import org.jboss.xb.binding.Constants; | import org.jboss.xb.binding.GenericValueContainer; | import org.jboss.xb.binding.JBossXBRuntimeException; | @@ -206,9 +207,9 @@ | ElementBinding element = (ElementBinding)term; | if(item.ended) | { | - if(element.getQName().equals(startName)) | + particle = item.particle; | + if(element.getQName().equals(startName) && particle.isRepeated() == false) | { | - particle = item.particle; | repeated = true; | item.reset(); | | @@ -1056,7 +1057,7 @@ | { | binding = particle.getTerm(); | } | - log.trace("pushed " + qName + "=" + o + ", binding=" + binding); | + log.trace("pushed " + qName + "=" + o + ", binding=" + Strings.defaultToString(binding)); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978132#3978132 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978132

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()

by bill.burke＠jboss.com

I also found a problem with URL creation for jars. deploy/foo.jar creates a URL jar:file:/.../deploy/foo.jar!/ With a URL like this, you cannot do url.openStream() although, for some strange reason, you can do url.openConnection() Do we want to change the URL for jars so that they don't have the foo.jar? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978131#3978131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978131

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: Marshalling Into java.util.properties

by adrian＠jboss.org

The code to do this is really trivial org.jboss.system.metadata.ServiceJBXBValueMetaData | // Get the attribute element content in a parsable form | StringBuffer buffer = ServiceConfigurator.getElementContent(getElement()); | | Thread current = Thread.currentThread(); | ClassLoader oldTcl = current.getContextClassLoader(); | ClassLoader cl = valueContext.getClassloader(); | if (cl != null) | current.setContextClassLoader(cl); | try | { | // Parse the attribute element content | SchemaBindingResolver resolver = SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver(); | Unmarshaller unmarshaller = UnmarshallerFactory.newInstance().newUnmarshaller(); | StringReader reader = new StringReader(buffer.toString()); | Object bean = unmarshaller.unmarshal(reader, resolver); | return bean; | } | finally | { | if (cl != null) | current.setContextClassLoader(oldTcl); | } | In fact, it is really redundant since this code is executed automatically if you have the namespace registered properly with the schema binding resolver and you are using the schema unmarshaller (which is not currently the case for the -service.xml) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978130#3978130 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978130

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Need more metadata for the JARStructure deployer

by scott.stark＠jboss.org

I just checked in an update to the deployer that adds a DeclaredStructure deployer which is driven off a META-INF/jboss-structure.xml descriptor. From the org.jboss.test.deployers.structure.explicit.test.DeclaredStructureUnitTestCase, there is a complex.deployer deployment similar to the tomcat war deployer: | complex.deployer/ | complex.deployer/cp-mf.jar/ | complex.deployer/cp-mf.jar/info | complex.deployer/x.war/ | complex.deployer/x.war/WEB-INF/ | complex.deployer/x.war/WEB-INF/classes/ | complex.deployer/x.war/WEB-INF/lib/ | complex.deployer/x.war/WEB-INF/lib/w0.jar/ | complex.deployer/sub.jar/ | complex.deployer/sub.jar/empty | complex.deployer/sub.jar/META-INF/ | complex.deployer/sub.jar/META-INF/MANIFEST.MF | complex.deployer/lib-dir/ | complex.deployer/lib-dir/jar2.jar/ | complex.deployer/lib-dir/jar2.jar/META-INF/ | complex.deployer/lib-dir/jar2.jar/META-INF/MANIFEST.MF | complex.deployer/lib-dir/jar0.jar/ | complex.deployer/jar1.jar/ | complex.deployer/META-INF/ | complex.deployer/META-INF/jboss-structure.xml | whose complex.deployer/META-INF/jboss-structure.xml is: | <structure> | <context> | <path name="complex.deployer" /> | <metaDataPath name="META-INF" /> | <classpath> | <path name="jar1.jar" /> | <path name="lib-dir" suffixes=".jar" /> | </classpath> | </context> | <context> | <path name="complex.deployer/sub.jar" /> | <metaDataPath name="META-INF" /> | </context> | <context> | <path name="complex.deployer/x.war" /> | <metaDataPath name="WEB-INF" /> | <classpath> | <path name="WEB-INF/classes" /> | <path name="WEB-INF/lib" suffixes=".jar" /> | </classpath> | </context> | </structure> | Any declared context with a META-INF/MANIFEST.MF declaring a Class-Path is also used to augment the context classpath, as is the Class-Path of any entry added via the descriptor classpath. I'll intgrate this into the jboss5 trunk tomorrow when I check in the tomcat.deployer work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978087#3978087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978087

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - The Address bar shows full path

by rashmi_setty

Hi, We are Jboss Portal 2.4 and MYFaces 1.1.3 Frame work for developing portlets The problem is when action occurs, the complete URL is showing in address bar as shown below https://localhost:8080/portal/portal/default/Test/ForgotPassword?action=2... I don't want the complete path to be shown to the user. Should i change setting in some xml... Pls help thx View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978085#3978085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978085

19 years, 6 months

1
0
0 / 0

[Design of Security on JBoss] - how the deleted user (from database) is still maintained in

by iliaz

Hi all, Presently we are using JAAS(JBoss) for security. The problems is.... as follows... steps: i logged in as a "admin" user and created a user (tempUser) and then i logged out. Now logged in as "tempUser" and logged out. After that i logged in as "admin" user and deleted "tempUser" and logged out.Here the "tempUser" is getting deleted from database. Now If i try to log in as "tempUser", it is giving the Error... instead of moving to "invalid login details" page. thing is... if i restart the JBoss server, then it is moving to "invalid login details" page. I think i am supposed to take care of few things after deleting a user. plz reply View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978080#3978080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978080

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status of web console enhancements

by tom.baeyens＠jboss.com

kukeltje, my idea with BAM vs BI is the following: after an execution tx that inserted records in the BAM db, those BAM records are immediately convered to the BI database. it should be possible to do this: 1) in the runtime transaction itself 2) asynchronously through messaging. the transformation to the BI db will assemble all the different logs into relevant info. then, the runtime log db will always remain small as the BAM records are max temprorary. the runtime will have the BAM db available for e.g. undo and other features that require the BI db. it should be very well documented/managed which features depend on the BI db, as it will also be configurable, which logs are being produced. we're talking next generation here and i think this covers best of both worlds. also, i'm thinking to generate a large part of the logs by leveraging hibernate's capabilities for dirty flushing. by using a hibernate interceptor, we can let hibernate calculate the diffs in one tx. that can be stored as a log record. basically each version of an object will be stored. apart from these, other logs will be generated as well. does that make sense to you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978072#3978072 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978072

19 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 October 2006