[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement
by ALRubinger
Sat in on Freenode #maven for a bit tonight to see if I could sort some of this out. Brian Fox of the Maven PMC was very helpful; I'll attach some relevant snippets below and a link to the full (edited for brevity) transcript at the end.
"dimitris(a)jboss.org" wrote : I'm surprised maven doesn't understand versioning (1.0.1 > 1.0.0)
"#maven" wrote : Brian: Will Maven know that 1.0.0 is less than 1.0.1? -> yes.
| Brian: the next thing: The fundamental problem is that maven has no idea that 1.0.1 is after 1.0.0 ... isn't true
---
"adrian(a)jboss.org" wrote : Now which version of common-core gets used?
| The answer is common-core:1.0.1 because jbossmc is first in the list
"#maven" wrote : Brian: "The answer is common-core:1.0.1 because jbossmc is first in the list" ... is also not true
| ALR: "Closest wins", you mean.
| Brian: it will use 1.0.1 because it's comparing at the same level
| Brian: right. closest wins applies first
---
Some additional insight that might help us:
"#maven" wrote : Brian: ok, so a few things that might not be known..
| ALR: All ears.
| Brian: dependencyManagement will apply to transitive dependencies since 2.0.6
| Brian: so your common-core thing... if you put that in depMgt, all that first discussion goes away. it will be what you set (provided it's not defined anywhere else)
This is the main suggestion; use "dependencyManagement" more frequently than simple "dependency".
"#maven" wrote : Brian: the other thing to know, specifying a version like "1.0" is just a suggestion
| Brian: technically the range is [,] with a recommendation on 1.0
| Brian: so that means that [1.0] is very different.
| Brian: so that's another way to influence the resolution. It's probably not the best way to do it though
| ALR: Meaning, "[1.0]" is concrete.
| ALR: And "1.0" is suggested?
| Brian: correct
| Brian: 1.0 means you want 1.0 but it lets maven have the flexibility to choose
| Brian: [1.0] means that's the only thing you can get. It _should_ either give you 1.0 or fail the build because there's a conflict
| ALR: And what if we specify [1.0] somewhere, and [1.1] is somewhere else transitively?
| Brian: it should fail
| ALR: :)
| Brian: i think this is a heavy handed approach that may make things worse
| ALR: Brian: But it gives us fail-fast.
| Brian: yes. You could also use the enforcer for that
So we can also look at locking down versions by placing them in brackets, forcing a version conflict failure if there's a problem. Brian alludes to some problems here; I'm not sure in which way these might manifest themselves.
Also worth a look is the Enforcer Plugin http://maven.apache.org/plugins/maven-enforcer-plugin/.
Edited transcript: http://www.alrubinger.com/jboss/pound-maven.txt
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137628#4137628
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137628
18 years
[Design of JBoss Portal] - Re: Portlet Container 1.2 changes
by julien＠jboss.com
I deprecated the class org.jboss.portal.common.util.MediaType as it is "broken" on several aspects (not thread safe, does not represent the right concepts).
I have introduced the class org.jboss.portal.common.net.media.MediaType which represent a media type value as defined by the proper RFC.
There is also a MediaTypeMap (which is not related to java.util.Map) which allow to store arbitrary values for MediaType or TypeDef (the definition of a type of a MediaType as defined by RFV blah blah...).
This map object has the concept of wildcard mapping which is used during resolution of a media type (in the portlet container from which I extracted the code), for instance when a portlet declares:
| <supports>
| <mime-type>text/*</mime-type>
| ...
| </supports>
|
or
| <supports>
| <mime-type>*/*</mime-type>
| ...
| </supports>
|
The class ContentInfo has been updated to use the new media type class and the portlet container has been updated also for that.
Note that in portlet 2.0 it is possible to declare the window states for a media type similar to how it is done for portlet mode support (which is the original motivation of the refactor defined here http://jira.jboss.com/jira/browse/JBPORTAL-1893).
Also the new MediaTypeMap impl is a bit smarter than the code that was originally in ContainerCapabilitiesInfo as it does not need to create object at runtime when it is queried (and it was creating temporary object previously, not a big deal I agree but if it can be saved just by a better impl) and also should be a few nanosecond faster (since it's direct map lookups).
So it is a new migration point that needs to be adressed when getting a snapshot of common + portlet.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137627#4137627
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137627
18 years
[Design of JBoss Web Services] - Re: Dependency on container configurations and JBWS-1992
by alessio.soldano＠jboss.com
I'm posting here to keep track of what happened.
I tried moving the WSEndpointRegistry to the container configuration (at first duplicating the container config in the stacks, then manually creating a new jbossws-jboss42=4.2.3.CR1 dependency). This however proved not to be a valid solution for some reasons, the most important being that even if I can manage to fix the 4.2 integration, JBoss 5.0.0 Beta4 is already out and its jbossws-deployer-beans.xml config cannot be easily modified. Therefore I would say that we can't easily have the correct dependency of WSEndpointRegistryDeploymentAspect on the WSEndpointRegistry bean, since we can't change the configuration that declares it.
On chat Thomas suggested checking for the existence of the mbeanServer before the unregister process. This would have been an idea for the first exception (ie. the one thrown by the EndpointRecordProcessorDeploymentAspect.). Speaking of the WSEndpointRegistry issue, instead, my thought is that if we can't assure the registry bean is available, then we could only handle the exception, supposing the server is shutting down, but of course this doesn't mean really solving the issue. Otherwise we can only put up with the shutdown KernelRegistryEntryNotFoundException.
Do anybody have better idea than me?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137625#4137625
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137625
18 years
[Design of Security on JBoss] - Re: Security aspects failing in AS trunk
by stale.pedersen＠jboss.org
hi (im following up kabirs tests a bit), i tested org.jboss.test.aop.test.SecurityUnitTestCase from head now and it fails with this stacktrace:
| 23:21:01,972 INFO [SecurityTester] TESTING XML Security
| 23:21:01,973 INFO [SecurityTester] testing unchecked constructor
| 23:21:02,441 INFO [SecurityTester] testing unchecked method
| 23:21:02,507 ERROR [SecurityTester] failed
| java.lang.SecurityException: Password Incorrect/Password Required
| at org.jboss.aspects.security.AuthenticationInterceptor.handleGeneralSecurityException(AuthenticationInterceptor.java:55)
| at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:70)
| at org.jboss.test.aop.bean.JoinPoint_unchecked_N_2712120300325346458_70$aop.invokeNext(JoinPoint_unchecked_N_2712120300325346458_70$aop.java)
| at org.jboss.test.aop.bean.JoinPoint_unchecked_N_2712120300325346458_70$aop.invokeJoinpoint(JoinPoint_unchecked_N_2712120300325346458_70$aop.java)
| at org.jboss.test.aop.bean.SecuredPOJO$SecuredPOJOAdvisor.unchecked_N_2712120300325346458(SecuredPOJO$SecuredPOJOAdvisor.java)
| at org.jboss.test.aop.bean.SecuredPOJO$SecuredPOJOInstanceAdvisor.unchecked_N_2712120300325346458(SecuredPOJO$SecuredPOJOInstanceAdvisor.java)
| at org.jboss.test.aop.bean.SecuredPOJO.unchecked(SecuredPOJO.java)
| at org.jboss.test.aop.bean.SecurityTester.org$jboss$test$aop$bean$SecurityTester$testXml$aop(SecurityTester.java:90)
| at org.jboss.test.aop.bean.SecurityTester$SecurityTesterAdvisor.testXml7807095709035618991(SecurityTester$SecurityTesterAdvisor.java)
| at org.jboss.test.aop.bean.SecurityTester.testXml(SecurityTester.java)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:270)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
| at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:815)
| at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:416)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
| at sun.rmi.transport.Transport$1.run(Transport.java:153)
| at java.security.AccessController.doPrivileged(Native Method)
| at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
| at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
| at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
| at java.lang.Thread.run(Thread.java:595)
the similar stacktrace happens for the annotated test.
what we first try to do here is to create an object (constructor is marked as unchecked) and then call a method and a field that both are marked as unchecked. it creates the object without any errors, but the method fails.
if there is anything we need to change in our test / setup please let me know :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137621#4137621
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137621
18 years