request for release of maven-jboss-retro-plugin
by Edelson, Justin
We've been plagued by JBBUILD-472 for many months now and I finally had a chance to create a patch for it.
While I can see from JIRA that there are two other issues waiting to be resolved before 1.0 is cut, is it possible to get a 1.0-beta-2 release cut in the interim? If there's anything I can do to help this happen, just let me know.
Thanks,
Justin Edelson
VP, Applications & Platforms
MTV Networks Digital
15 years, 11 months
AS trunk & hot deployment
by Alessio Soldano
It seems to me the hot deployment is not currently working on AS trunk.
Is that correct and perhaps related to the work on profile service?
Thanks
Alessio
--
Alessio Soldano
Web Service Lead
JBoss, a division of Red Hat
15 years, 11 months
Why no commons-codec in AS5?
by Stan Silvert
Was this just an oversight or was there some specific reason it was not
included? commons-httpclient.jar is in commons/lib and it depends on
commons-codec.
The problem I'm having is that the RichFaces demo has:
<jboss-web>
<class-loading>
<loader-repository>
org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
It includes commons-httpclient and commons-codec in WEB-INF/lib. Since
parent delegation is true it will use commons-httpclient from
commons/lib and then fail because it can't find commons-codec.
So there are two ways to fix it. Either remove commons-httpclient from
commons/lib or add commons-codec.
Who is depending on commons-httpclient and how would I know this so I
would know who to ask?
Stan
15 years, 11 months
Shared component-matrix
by Andrew Lee Rubinger
Back in March, I introduced the idea of a "Shared Component Matrix" to
be the authority over which versions AS would use.
JIRA -
https://jira.jboss.org/jira/browse/JBAS-5324
Forum -
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131748
The intention was for this to be a component scoped outside of the
Application Server such that it could be relied upon by outside
projects. In other words, both AS and jbossas/projects/* could rely
upon the same 3rdparty components.
The Threads stop and don't explain why it was decided that
component-matrix should live inside AS, therefore ineligible to be
consumed outside due to cyclic dependencies. I believe the reason was
"it makes it easier to tag AS altogether".
I was opposed to this at the time, and it's still unacceptable. :)
Concrete example of why:
The last update to jboss-ejb3-proxy defined a dependency upon
jboss-metadata:1.0.0.CR8. At the time, this was in sync between AS and
ejb3-proxy.
Over the past few months, AS has updated jboss-metadata, now at
1.0.0.CR14. The dependency declared in ejb3-proxy is orphaned, and has
stayed constant.
We've therefore been unit testing ejb3-proxy against stale jboss-metadata.
Tonight I go to update in preparation for a GA *RELEASE*, and guess
what? Regression was introduced sometime in the past 4 months, I'm just
seeing it now, and this blocks the whole release process until I can
find and fix this bug.
Please, let's re-open the discussion about a shared dependency policy.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
15 years, 11 months
remove deploy/ejb3-timer-service.xml
by Dimitris Andreadis
https://jira.jboss.org/jira/browse/JBAS-6304
Can we remove deploy/ejb3-timer-service.xml ?
I understand this service
a) creates 10 idle quartz threads
b) have trouble configuring different DBs
c) is not actually used in the existing configs
d) it's going to be dropped anyway
BTW, where EJB3 gets its timer service configured? I can't find a trace in the deployment
descriptors of the ejb3.deployer so my guess is that is falling back to ejb2 timer impl.
Cheers
/D
15 years, 11 months
ejb3 versioning
by Dimitris Andreadis
Modified:
branches/Branch_5_x/component-matrix/pom.xml
- <version.org.jboss.ejb3>1.0.0-CR2</version.org.jboss.ejb3>
+ <version.org.jboss.ejb3>1.0.0</version.org.jboss.ejb3>
Rather than dropping GA as a suffix, why not discussing the issue first?
Either we follow the rules or we provide arguments why they have to change:
http://www.jboss.org/community/docs/DOC-10725
15 years, 11 months
AS trunk testsuite build
by Alexey Loubyansky
After today's checkout I get the exception below. Is anybody else seeing
this?
Thanks,
Alexey
C:\Users\avoka\svn.jboss.org\jbossas\trunk\testsuite>build.bat
Calling ..\tools\bin\ant.bat
Buildfile: build.xml
BUILD FAILED
java.lang.NoClassDefFoundError: org/jboss/logging/Logger
at org.jboss.jbossas.servermanager.Server.<clinit>(Server.java:65)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.tools.ant.IntrospectionHelper$AddNestedCreator.create(IntrospectionHelper.java:1278)
at
org.apache.tools.ant.IntrospectionHelper$Creator.create(IntrospectionHelper.java:1169)
at
org.apache.tools.ant.UnknownElement.handleChild(UnknownElement.java:550)
at
org.apache.tools.ant.UnknownElement.handleChildren(UnknownElement.java:346)
at
org.apache.tools.ant.UnknownElement.configure(UnknownElement.java:198)
at
org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:160)
at org.apache.tools.ant.Task.perform(Task.java:347)
at org.apache.tools.ant.Target.execute(Target.java:357)
at
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:131)
at
org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:146)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:142)
at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
at org.apache.tools.ant.Main.runBuild(Main.java:743)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Total time: 1 second
15 years, 11 months
Re: [jboss-dev] Re: XML Schema for JGroups - annotations galore
by Jason T. Greene
noNamespaceSchemaLocation is only useful for a schema that doesnt define
a targetNamespace.
Without elementFormDefault="qualified" you would have had to do:
<config xmlns="urn:org:jboss"/>
<TCP xmlns=""/> <!-- Element is unqualified!!!!! -->
</config>
If adding that property didn't fix your problem, I would need to see the
xml that is supposed to be invlaid.
Vladimir Blagojevic wrote:
> Thanks Jason!
>
> One thing that I noticed is that configuration file gets verified by the
> editor if I use
>
> xsi:noNamespaceSchemaLocation="file:/Users/vladimir/workspace/JGroups-HEAD/JGroups-2.8.xsd"
>
>
> however if I use
>
> xsi:schemaLocation="file:/Users/vladimir/workspace/JGroups-HEAD/JGroups-2.8.xsd"
>
>
> editor claims that configuration file is valid even if it is not.
>
> I though that as soon as we declare targetNamespace in a schema we have
> to use schemaLocation and not noNamespaceSchemaLocation? I am not very
> familiar with these intricacies so I apologize if the answer to this
> question is so obvious!
>
> Regards,
> Vladimir
>
>
>
> <config xmlns="urn:org:jgroups"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> xsi:schemaLocation="file:/Users/vladimir/workspace/JGroups-HEAD/JGroups-2.7.xsd">
>
>
> On 1/22/09 3:15 PM, Jason T. Greene wrote:
>> Sorry I missed your email Vladimir. Set the elementFormDefault of your
>> schema to "qualified", otherwise everything you declare will end up in
>> the "" namespace.
>>
>> Brian Stansberry wrote:
>>> Ask on jboss-development(a)lists.jboss.org. It's a totally appropriate
>>> question for the list and you're more likely to get an answer since a
>>> number of more technical people kinda ignore thecore.
>>>
>>> Vladimir Blagojevic wrote:
>>>> Brian,
>>>>
>>>> Do you think it is inappropriate to ask for help on the core
>>>> regarding this issue? I am ripping my hair out by now trying to
>>>> figure this one out!
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 1/21/09 4:52 PM, Vladimir Blagojevic wrote:
>>>>> On 1/20/09 1:55 PM, Jason T. Greene wrote:
>>>>>> You should specify a namespace using targetNamespace, so that
>>>>>> components like JBC can inline the jgroups config into the JBC
>>>>>> config. Current practice is to use a URN style URL for the
>>>>>> namespace instead of http. I would also recommend bundling the
>>>>>> schema in the jgroups jar in META-INF/schemas so that you can
>>>>>> optionally enable schema validation without requiring the schema
>>>>>> file in the install.
>>>>> Do you mean having a schema declaration start like this:
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>>>> targetNamespace="urn:org:jgroups">
>>>>>
>>>>> If I have a jgroups conf file:
>>>>>
>>>>> <config xmlns="urn:org:jgroups"
>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>
>>>>> xsi:schemaLocation="file:/Users/vladimir/workspace/JGroups-HEAD/JGroups-2.7.xsd">
>>>>>
>>>>> <UDP
>>>>> mcast_addr="${jgroups.udp.mcast_addr:232.10.10.10}"
>>>>> mcast_port="${jgroups.udp.mcast_port:45588}"
>>>>> ....
>>>>>
>>>>>
>>>>> then for some reason my editor (Oxygen) always reports that conf
>>>>> file is well formed - even if it clearly is not.
>>>>>
>>>>> What am I doing wrong?
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>
>>>
>>>
>>
>>
>
--
Jason T. Greene
JBoss, a division of Red Hat
15 years, 11 months
Re: XML Schema for JGroups - annotations galore
by Brian Stansberry
Ask on jboss-development(a)lists.jboss.org. It's a totally appropriate
question for the list and you're more likely to get an answer since a
number of more technical people kinda ignore thecore.
Vladimir Blagojevic wrote:
> Brian,
>
> Do you think it is inappropriate to ask for help on the core regarding
> this issue? I am ripping my hair out by now trying to figure this one out!
>
> Thanks,
> Vladimir
>
> On 1/21/09 4:52 PM, Vladimir Blagojevic wrote:
>> On 1/20/09 1:55 PM, Jason T. Greene wrote:
>>> You should specify a namespace using targetNamespace, so that
>>> components like JBC can inline the jgroups config into the JBC
>>> config. Current practice is to use a URN style URL for the namespace
>>> instead of http. I would also recommend bundling the schema in the
>>> jgroups jar in META-INF/schemas so that you can optionally enable
>>> schema validation without requiring the schema file in the install.
>> Do you mean having a schema declaration start like this:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> targetNamespace="urn:org:jgroups">
>>
>> If I have a jgroups conf file:
>>
>> <config xmlns="urn:org:jgroups"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>
>> xsi:schemaLocation="file:/Users/vladimir/workspace/JGroups-HEAD/JGroups-2.7.xsd">
>>
>> <UDP
>> mcast_addr="${jgroups.udp.mcast_addr:232.10.10.10}"
>> mcast_port="${jgroups.udp.mcast_port:45588}"
>> ....
>>
>>
>> then for some reason my editor (Oxygen) always reports that conf file
>> is well formed - even if it clearly is not.
>>
>> What am I doing wrong?
>>
>> Regards,
>> Vladimir
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
15 years, 11 months
